Field Schemes Are Here: What It Means for Your Automation Rules

[#1]

If you manage Jira for more than a handful of projects, you've probably already heard about the Field Schemes change. Atlassian started rolling it out in April 2026 and while the auto-migration means nothing breaks overnight, there's a quiet category of damage that shows up a week later when someone notices an automation rule stopped firing.

That's what this article is about.

What actually changed

Until now, Field Configuration Schemes worked as a central control panel. One place to say: this field is required here, optional there, doesn't exist in that project. A lot of admins used them as a catch-all for enforcing consistency across teams.

That layer is gone. Atlassian has split the responsibility across three separate components:

• Field Schemes: control which work types a field can appear on.
• Field Contexts: define default values and available options per field.
• Screens and Work Item Layouts: control what users actually see when creating or editing an issue.

Your existing configuration gets auto-migrated. Atlassian doesn't delete your fields or break your projects. But the mental model that governed how you set things up no longer applies and automation rules were built against that old mental model.

Where automation rules break

Three rule types are most at risk.

Field Value Changed triggers. These rules fire when a specific field changes value. If the migration alters which work types a field is now associated with, because Field Schemes define that association differently than Field Configurations did, the trigger may stop seeing the change event it's listening for. The rule looks fine in the editor. It just doesn't run.

Field-based conditions using JQL. Rules that include conditions like cf[12345] is not EMPTY or check for specific field values mid-rule depend on the field being present and populated. If a field's visibility has shifted across project types post-migration, the condition evaluates differently than it did before.

Smart values reading field change data. If you're using {{fieldChange.fromString}} or {{fieldChange.toString}} in rule actions for logging who changed what, or reverting unauthorized edits, these depend on field change events being correctly registered. A field that's now scoped differently may not generate the same event structure.

None of this is guaranteed to happen on every instance. But if you have rules built around specific custom fields, you want to know before the migration runs on your site.

What to check right now

Go to Project Settings - Automation and pull up your audit log. Filter for rules that use Field Value Changed as a trigger, or any rule with a field-based condition in the middle of the chain. Make a list. These are your at-risk rules.

Then, for each one, ask: does this rule depend on a field that was previously controlled by a Field Configuration Scheme? If yes, check the new Field Scheme settings to confirm that field is still associated with the same work types in the same projects.

It takes less time than you'd expect. Most instances have five to ten rules in this category. Reviewing them takes an afternoon. Finding out they broke takes a support ticket and a frustrated team three weeks from now.

When you need more than native automation can do

The Field Schemes migration is a good moment to audit something broader: whether your automation coverage actually matches how your team works today.

Most instances have rules that were built around the old field configuration model. Some can be simplified now that the model has changed. Others reveal gaps that were always there but nobody addressed, tasks that stayed manual because native automation couldn't reach them.

The most common ones we see: user onboarding and offboarding still running on a checklist, access requests being processed manually ticket by ticket, new projects getting spun up by an admin instead of triggered automatically.

None of these are field problems. They're action gaps - things native Jira automation doesn't expose as actions at all.

Automation Actions Bundle for Jira, built by our team at Grandia Solutions, covers exactly these. It adds actions for user and group management, project role assignments, project creation, sprint operations, and component setup, the admin tasks that previously required either manual work or API scripts. If your audit surfaces rules that need extending rather than just fixing, that's where it fits.

Start with the audit log, fix the field-related rules first. Then look at what's still manual.