Which parts of Jira can JAMEs change?

Written by Ben Friedman, Atlassian expert & builder of JAMEs, the AI Jira administrator · Published 15 August 2026

Ten objects are available to JAMEs today. It can both read and change them: users, permissions, custom fields, the contexts and configurations behind them, screens, workflows including their validators and conditions, projects, issue types, and JSM request types.

Two sit outside that. Automation rules are read only, so JAMEs can inspect them but not edit them. Board management is coming soon.

One limit runs across every row. JAMEs creates and updates; it never removes. There are no delete tools in it at all, so nothing here ends in something disappearing from your site.

Below we cover what changing an object actually involves, the status of every object type, what read only still gets you, and where to tell us a gap matters.

What does JAMEs do in Jira?

JAMEs can query the project’s configuration, understand its configuration context in Jira, and analyze your request against it, to advise on the best way to achieve new business goals in the configuration. Upon your review and approval, it can update the configurations based on the agreed plan. A new custom field or a new request type is something JAMEs can produce, not only something it can adjust after the fact.

Removal is the exception, and it holds everywhere. There are no delete tools in JAMEs for any object, so a plan can never finish with a field or a project gone from your site. Removal and clean up remain under complete human inspection. Every update reaches your site the same way, through Atlassian’s own API calls, coming from the plan. JAMEs watches the execution as it runs, and loops back into planning itself if it meets something it did not foresee. To learn more, how JAMEs works safely walks through it end to end.

Which objects does JAMEs create and update?

The table below gives the current status of each object. Supported means JAMEs can query it and update it, read only means it can query it and nothing more, and coming soon means neither yet.

Read down the status column and the shape of the tool shows up. The parts of Jira that an administrator configures are open, and the two exceptions sit at the edge of that work: rules that run on their own, and boards. Between them the ten supported rows carry most of what fills an administration backlog in an ordinary week, like a field that needs a new context, or a project that has to be set up the way the last one was.

What can JAMEs tell you about your automation rules, and what can it not?

JAMEs contains an AI agent that answers your questions about automations. Which rules are available? Which ones were updated since a given date? Which rules write to a field, or carry a condition based on one? It reads them and reports back, and that is where it stops. On a site where the rules were built over several years by people who have since moved on, that answer alone is often what an admin was actually after.

A second support function is version control for automation rules. JAMEs keeps a log of changes to a rule, so you can see the difference between the latest version and the one before it. If you do not like the last update, and especially if it turns out to be wrong, JAMEs exports any earlier version of that rule for you to import back into your Jira site.

JAMEs has no way to edit or update an automation on your site. The import is a step you take yourself. If the rules themselves are the problem rather than the questions about them, that is design work, and it is what Jira and JSM automation is for.

Does JAMEs allow me to understand and track what it does?

Yes. For example, adding a custom field so it appears only on two projects and nowhere else means touching four things: the field itself, the context that decides where it applies, the screens it has to show up on, and the field configuration.

Four objects is four chances to miss a step, which is the ordinary way a new field ends up invisible to the people who asked for it. The plan covers all of them and walks through them again during execution. One request spanning several rows is the normal case, and it is how JAMEs tracks its own work: you get the exact steps, to trace now and to learn from later.

When would JAMEs not match what you need?

Board management, and anything that needs deleting. Boards are on the way rather than ruled out, so configuring one is still a manual job today. Deleting is a firmer restriction and is not expected to be enabled any time soon.

If most of your work is within the tickets themselves, that is another kind of mismatch. JAMEs is built to help administrators analyze their work and manage large-scale operations across configuration and automation, not to work through an issue queue.

For any other gap, tell us which one you hit: hello@viter.io. Knowing which object types people run into is how we decide what to build next.

Frequently asked questions

Name the change you keep putting off, send it to hello@viter.io, and we will tell you whether JAMEs handles it today, including when the answer is not yet. Joining the beta runs through JAMEs.