Formtide documentation
Formtide adds field rules to Jira Cloud and Jira Service Management: when something on a screen matches, show or hide a field, make it required or optional, read-only or editable, set or clear its value, show only some of its options, or change its label or help text. Rules are built from menus on one admin page; no scripting.
Get started
- Open Jira settings > Apps > Formtide (Jira admins only).
- Pick a recipe under Start from a recipe, for example "Ask for a root cause on the most urgent work", or press New rule.
- Fill in what the recipe asks for (the field to show, the priority to watch), then press Test this rule and run the test with the values a person would enter.
- Press Save and apply. The rule is registered with Jira right away; open Create in that project to see it.
Rules
A rule has three parts.
Where it runs. Screens (Create, Transition, Work item view, the three Service agent screens, Customer portal request), projects (or All projects), work types (or All work types) and, for service projects, request types. The customer portal screen always needs at least one request type. New projects are picked up automatically by rules for all projects and all work types.
When. Any number of conditions, combined with "all" or "any". A rule with no conditions applies whenever the screen opens. You can check:
| Subject | Comparisons |
|---|---|
| Select lists, checkboxes, radio buttons, cascading selects, priority, work type, resolution, components, versions, project picker | is any of, is none of, is empty, is not empty |
| Users (assignee, reporter, user pickers, people) | is any of, is none of, is empty, is not empty |
| Labels | is any of, is none of, is empty, is not empty |
| Summary, description, short text, paragraph, URL | contains text, does not contain text, is empty, is not empty |
| Numbers, original estimate, dates (due date, date pickers, date time pickers, target start and end) | greater / later than, at least, less / earlier than, at most, is empty, is not empty |
| Status (current) | is any of, is none of (transition and work item view screens) |
| Current user's groups | is any of, is none of |
| Request type | is any of, is none of |
Options are matched by id and by name, so a renamed or re-created option still matches by its
old name until you update the rule. "Is none of" is true for an empty field. Dates accept
2026-12-31, today, +7d, -2w or +1m (30 days).
Then. One or more actions on fields:
| Action | Notes |
|---|---|
| Show / Hide | Hiding changes what the screen shows; it is not a permission. |
| Make required / Make optional | Create, Transition, the portal and the agent screens. Jira does not support required rules on the work item view. Summary is always required. |
| Make read-only / Make editable | On the work item view, Jira hides read-only fields that are empty. |
| Set value / Clear value | Create, Transition, the portal and the agent create and transition screens. Never on the work item view (Jira would save it to the work item for everyone). Options, people (or "the current user"), labels, text, numbers, durations (2h, 1d 4h), dates (today, +14d) and date times (+1d 14:30). By default only into an empty field; untick "Only when the field is empty" to overwrite. |
| Show only these options / Hide these options | Select lists, multi-select, checkboxes, radio buttons and Priority (and versions, work type, resolution and parent on transitions). Not Components. |
| Set help text / Rename label | Help text appears under the field. |
Order and conflicts
Rules run top to bottom (use Up and Down on the Rules tab). For every field and every property (visible, required, read-only, value, options, label, help text), the first matching rule that sets it wins; the tester shows the rules it overrode. Anything no matching rule sets goes back to how the screen first opened, so a field shown while Priority is Highest hides again when Priority changes.
Two guards:
- A field that would end up hidden and required while empty would block the form with an error nobody can see. Formtide turns "required" off while it is hidden. If Jira's own configuration requires the field, it stays visible while it is empty.
- Values are set when a rule starts to match (when the screen opens, or when a change makes the rule match), not on every change, so a rule never overwrites what someone is typing.
Test
The Test tab opens a pretend screen. Pick the screen, project, work type and (for service projects) request type, the current status and the person's groups if your rules use them, then type the values a person would enter. Run test shows which rules apply and match, and for every field what changes, the rule that decided it, and the rules it overrode, plus notes for anything Jira will not do on that screen. Test this rule in the editor tests your unsaved changes together with the saved rules.
Audit
The Audit tab lists every rule with its state in Jira (Applied, Not applied, Out of date, Off), how many project / work type / screen combinations Jira has for it, and how many Jira marks unavailable (a deleted project, work type or request type). Below it, every project and the rules that run there. Re-apply all rules fixes anything that is not as saved and removes registrations left by deleted rules.
Import and export
Export rules copies every rule with the names of its fields, projects and work types. Import on another site maps fields by name (and project by key, work type by name), reports anything it cannot find, and adds the rules switched off so you can test them first. Request types differ between sites; pick them again after an import.
Change log
Every rule change (created, edited, switched on or off, moved, duplicated, deleted, imported, re-applied) with the person and the time. The last 300 changes are kept.
Limits (set by Jira, the same for every app of this kind)
- Screens. Create: Jira Software and Jira Work Management projects. Transition: company-managed projects, Jira's new transition screen, on transitions that have a screen. Work item view: Jira Software projects. Service projects: the agent create, transition and work item screens, and the customer portal request form.
- Screens only. Rules run when a person uses a screen. Work created or changed through the API, CSV import, bulk edit or automation skips them, so pair a "required" rule with a workflow validator on the transition.
- Not a security control. A hidden field's value is still in search, exports and the API.
- Field types. Jira offers apps the common system fields and these custom field types: select, multi-select, checkboxes, radio buttons, cascading select, user picker (single and multiple), people, short text, paragraph, URL, number, date, date time, project picker, target start and target end. Not Assets fields, not other apps' fields. Due date: Create and the portal only. Components and labels have no option list to trim.
- Loading. Jira applies rules a moment after the screen opens, so a field can show briefly before it hides; a small spinner shows next to fields a rule changes.
- Other apps. Jira runs up to five UI modification apps per screen. When two change the same thing on the same field, the one that finishes last wins and Jira shows a notice.
- Size. Up to 100 rules on the same project, work type and screen, and up to 3,000 Jira registrations per site (a rule uses one per 1,000 project / work type / screen combinations).
Billing
Formtide is billed by Atlassian per user, with a 30-day free trial. Without an active subscription rules stop running on screens and the admin page shows them read-only.
Privacy and security
Formtide runs entirely on Atlassian's Forge platform (Runs on Atlassian). Rules live in Forge storage and in Jira's own UI modification records; field values stay in Jira and are never stored by Formtide. See the privacy policy at https://greatwork.company/apps/formtide/privacy.
Support
hello@greatwork.company, Monday to Friday (US Central time), first reply within one business day.