Auto Behaviour: Designing Rules That Stay Maintainable

[#1]

Auto Behaviour does not become hard to use because the product lacks actions. It becomes hard to use when the rule model becomes difficult to understand.

Everything ends up inside one large Auto Behaviour rule. Create and view logic are mixed together. Visibility, requiredness, value-setting, and actor checks all live in the same branch tree. One broad assignment covers several projects because it feels simpler at the beginning.

Later, nobody wants to touch it.

That is not mainly a tooling problem. It is a design problem.

A large rule is often a warning sign

One of the easiest ways to model a business scenario is to put all of its logic into one rule. That feels tidy at first. In practice, it usually makes two things harder:

• explaining which rule is responsible for the final state of a field
• changing one part of the logic without disturbing something else

The more maintainable split is usually by behavioral intent, not by how the form looks visually.

`onInit` and `onChange` should not be treated as substitutes

If a field state needs to be correct when the form first appears, that is an initialization concern.

If a field state needs to react after user input, that is a change-handling concern.

Many real field behaviors need both.

This is especially important when trigger values may already exist before the user interacts with the form. A rule that only reacts to changes can still be logically correct and yet present the wrong first screen state.

## Assignment scope is also an isolation strategy

Many teams think of assignments only as rollout scope: which projects, which issue types, which views.

In practice, assignment scope is also one of the best tools for isolating behavior so that different business contexts do not interfere with each other.

I find it useful to ask three questions before widening an assignment:

1. Is this behavior really valid for all target issue types?
2. Does it mean the same thing in create, view, and transition contexts?
3. Do the participating projects actually share the same process and field assumptions?

If not, broad assignments usually create hidden complexity rather than simplicity.

A simple layering model helps

For more complex form behavior, I like a four-layer split:

• baseline rules for the initial screen state
• reactive rules for change-driven synchronization
• derived-value rules for lookup tables, expressions, and dynamic writes
• actor or status rules for editability discipline

This does not remove complexity, but it makes the complexity visible and reviewable.

Fallback branches should be explicit

Many unstable behaviors do not fail because the matching branch is wrong. They fail because the non-matching path is incomplete.

For example, a matching branch may make a field visible and required, while the fallback branch only hides it again. Requiredness is left behind from a previous state, and the final behavior becomes confusing.

The safest rule-authoring habit is straightforward:

- whatever a rule changes in its matching branch, it should deliberately restore in its fallback branch

That matters even more once several rules affect nearby fields.

Naming is part of maintainability

Good names reduce maintenance cost.

I prefer names that expose both scope and intent, such as:

• Create - Incident severity baseline
• Change - Production option filtering
• View - Assignee can edit execution fields
• Derived - Queue from region and request type

The value of this is not cosmetic. It makes debugging and review far more efficient.

A useful review heuristic

If a single rule does all of the following, it probably wants to be split:

- reacts to three or more drivers
- mixes several different action categories
- spans more than one materially different view semantic

That is not a hard law, but it is a very practical review threshold.

Auto Behaviour is one way to implement these patterns visually, but the underlying design principle is broader than any one tool: field behavior stays maintainable when rule intent is clear, lifecycle handling is explicit, and assignments are treated as isolation boundaries rather than just coverage settings.

If you want to compare these rule design patterns against one visual implementation model, Auto Behaviour is available on the Atlassian Marketplace: https://marketplace.atlassian.com/apps/3743622377