Form Behaviours for Jira Cloud

Last updated 2026-10-31

Form Behaviours shows, hides, requires and locks fields on Jira's own forms while people fill them in, by rules a Jira administrator builds on one admin page. No code is written to make a rule. It is a paid app on the Atlassian Marketplace, built on Atlassian Forge.

Set up

1. Install the app from the Atlassian Marketplace. The consent screen lists nine scopes; the Security policy says how the app handles data.
2. Open the builder: Jira settings (the gear), Apps, then Form behaviours in the left menu. Only users with the Administer Jira global permission can open it and change rules.
3. Service portal (optional): portal customers load the form part of the app so portal rules can run. They never see the builder.

There is nothing else to configure. The app has no settings page, no outside account and no outside server.

Build a rule

Choose New rule. A rule has three parts.

Where

• Views: Create, Issue view, Transition, or Portal request. Issue view, Transition and Portal request are marked "Atlassian preview": Atlassian still calls these views of its UI modifications feature a preview.
• Projects and issue types: pick one or more projects. Leave issue types empty for every issue type in those projects.
• Every project: tick "Every project, for the issue types named below" and name at least one issue type. Jira cannot take "every project and every issue type" in one rule.
• Portal request: pick a portal and its request types instead. A portal rule is for the portal only; make a second rule for Jira views.

When

• Fire when: all conditions hold, or any condition holds. No conditions means the rule always fires where it runs.
• A field value: is any of, is none of, is empty, is not empty. Values are typed, comma separated, as option names or option ids. Ids keep working when an option is renamed; names do not.
• The transition goes to: one or more statuses. Only on a rule whose only view is Transition.
• The user is in a group, or has a project role (or is not, has not). Not on portal rules: portal customers have no Jira groups or roles.

On a user field (Assignee, Reporter, a user picker), a value is the person's Atlassian account id. See "Personal data" below.

Then

One or more actions, each on a field: Hide, Show, Require, Make optional, Lock (read-only), and the reverse of Lock, which makes a field editable again.

If Jira cannot do an action on one of the chosen views, the builder says so under the action and the app skips it there. The biggest gap: no field can be made required on the issue view.

Choose Save. The rule is stored and published to Jira at once, and the list shows "Published" with counts. Each rule in the list reads as one plain sentence.

How rules combine

• Between rules, the restrictive behavior wins: hidden over shown, required over optional, locked over editable.
• A field that ends up hidden is never required, because nobody could fill it in.
• A field Jira itself requires is never made optional.
• When a rule stops firing (say the priority changes back), its fields return to how the form had them when it opened.
• Text fields are checked again when the cursor leaves the field; lists are checked again as soon as a value is picked.

Manage rules

• Turn off or Turn on a rule without deleting it.
• Edit a rule; saving publishes it again.
• Delete a rule; it is removed from Jira in the same step.
• Publish again if the status line says "Partly published" or "Not published". The reasons are listed under it. Until publishing succeeds, Jira keeps running the rules it had.

Things to know

• A lock is not a permission. A locked field is locked on these forms only. REST, bulk edit, automation and imports can still change it, and can leave a required field empty. Use Jira's field configuration or issue security where a field must be protected.
• Hidden is not secret. A hidden field's value is still submitted, and a field can show for a moment before a rule hides it.
• Everyone who opens a form receives its rules, as with any UI modification. Put nothing secret in a rule name or value.
• Other apps on the same form: Jira lets up to five apps change one form. If two change the same field, the last one wins.
• Limits Jira sets: 3,000 rules per site, 100 rules on one project, issue type and view, and 1,000 project, issue type and view combinations per rule. The builder refuses a save that would break one.

Personal data

The only personal data the app can hold is an Atlassian account id you type into a condition on a user field. Once a week the app reports those ids to Atlassian, as Atlassian requires. If Atlassian answers that an account is closed, the app removes that id from every rule, turns those rules off, and the list says so. Check such a rule and turn it on again.

When the license is not active

If the site's license for Form Behaviours is not active (a lapsed subscription, or a trial that ended):

• Your rules are kept. The admin page lists them, read only, with a message saying the license is not active.
• No rule runs on forms. Fields behave as Jira's own configuration says.
• You can still turn rules off and delete them. New rules, edits, turning rules on and publishing wait until the license is active again.

When the license is active again, the rules run on forms again at once. Nothing needs to be published again.

Troubleshooting

Data and security

• Runs on Atlassian: the app runs on Atlassian's infrastructure and stores its rules in Forge storage, with a copy of each rule that is on kept in your Jira site as a UI modification.
• No data leaves Atlassian. We run no servers that receive your Jira data.
• The app stores no issue content and none of the values people type into forms.
• Atlassian deletes the app's stored data after the app is uninstalled.

Legal

• Privacy policy
• End User Terms
• Data Processing Addendum
• Security policy

Support

Email alexander@inventerprises.se. The Support page says what to include in a report.