Permissions, data and limits
What the app can access, what it stores, its limits, and how to diagnose a rule that misbehaves.
Limits worth knowing
| Limit | Value |
|---|---|
| Post function agent loop | 20 iterations per run |
| Change history sent to the AI | 50 most recent changelog entries |
| Comments sent to the AI | 20 most recent |
| Attachment contents | Never read — metadata only |
| Search Issues (JQL) tool | 10 results by default, 50 maximum |
| Saved configuration, per rule | 32 KB — Jira's limit, warned about before you save |
| Audit retention | 90 days. No per-day cap: one row per event. |
| Audit events shown at once | 2,000, with a warning when there are more |
| AI retries | Two, on a transient failure. A content-moderation refusal is not retried. |
Permissions the app requests
| Scope | Why it is needed |
|---|---|
read:jira-work | Read issue fields, comments, change history, links, sub-tasks and available transitions, and analyse or evaluate Jira expressions. |
write:jira-work | Perform the post function tools you enable: comments, field edits, sub-tasks, issues, links, worklogs, transitions. |
read:jira-user | Return display names for the assignee, reporter, comment authors and changelog authors inside the issue data the app reads. |
manage:jira-configuration | Required by Jira for an app that plugs into the workflow editor and evaluates Jira expressions. |
send:notification:jira | The Send Notification tool. |
storage:app | The app's own storage. The audit trail itself lives in Forge SQL, one row per event. |
report:personal-data | Atlassian's Personal Data Reporting cycle, which the app now genuinely runs: once a day it walks its own storage for account IDs and reports what it finds, then erases anything belonging to an account Atlassian reports as closed. Today it finds none — see below. |
The app declares no external network access at all. AI calls go to Forge LLM inside the Atlassian platform. Jira is read with the app's own access, not the acting user's.
Where your rules are stored — and it is not here
This surprises people, so it is worth stating plainly.
| Data | Stored by | Notes |
|---|---|---|
| Your rule configuration: description, rule text, generated expression, selected fields, context sources, enabled tools | Jira | It lives in the workflow definition, exactly like the configuration of any built-in condition. It travels with the workflow, and it is covered by Atlassian's own data handling. |
| Audit events | The app, in Forge SQL | One row per event: what ran, when, on which issue key, the transition, the validator's reason or the generated expression, and the token usage of each AI call. Deleted after 90 days. |
Full detail in the privacy policy.
The audit log, at Jira → Apps → Workflow Toolkit
The app ships one admin page, and it is read-only: a record of what the condition, validator and post function did. It is the place that answers “why was this transition blocked?” and “what did the post function change?” — and, since licensing was enforced, “why did my rule stop taking effect?”.
| Column | What it holds |
|---|---|
| Date/Time | When the event happened. The table is sorted newest first. |
| Event | Condition Generated, Validator Executed, Validator Failed, Post Function Executed, Post Function Failed, LLM Request. |
| Issue | The issue key, linked. Blank for events that are not about one issue. |
| Transition | The transition name, or from → to when the event did not carry a name. |
| Reason / Expression | For a validator, the AI's reason for allowing or blocking — this is the field that answers why. For a condition, the expression that was generated. |
| Tokens | What the AI call cost, split into prompt and completion in the CSV. |
Filter by date range, by event type and by issue key, then Export CSV for the range you are looking at. The export carries the same columns the table shows and nothing more — it deliberately has no raw details column, because an export is the copy that gets mailed around.
Uninstalling
Uninstalling erases what the app holds. A preUninstall handler empties the audit table and deletes every key the app wrote, working to a 45-second budget and attempting each store even if the other fails.
Your rules travel with the workflow, because Jira stores them — so the modules stop working, but there is no rule configuration in our storage to delete. Anything a post function already wrote into Jira stays there. Export the audit CSV first if you need it. See Where your data goes.
Troubleshooting
- The rule has no effect
- Check in this order. The workflow draft was not published. The module was added to a different transition than the one being used. The saved rule is empty — a condition with no expression falls back to
true, and a validator with no rule allows. And, since licensing is enforced, there is no active licence: the validator then allows every transition and the post function does nothing, both recorded in the audit log. See What happens without an active licence. - A rule stopped taking effect and nothing changed in the workflow
- Open Jira → Apps → Workflow Toolkit and look for skipped-unlicensed events on the transition. That is the app telling you the licence lapsed. The condition keeps working regardless, so a transition governed by both a condition and a validator will look half-broken rather than switched off.
- A transition disappeared for everyone
- An AI Condition is evaluating to false for every issue. Open its configuration, use Validate Syntax and then Test with Issue on a known-good issue, and read the generated expression. A field that is never populated is the usual cause.
- Generate Expression produced something wrong
- Add the custom fields to Custom Fields Involved, use Jira's exact field names, and split compound rules. Then edit the expression by hand — it is editable for exactly this reason, and the edited text is what runs.
- The validator blocks and the message is not helpful
- The user sees your Error message field, so rewrite that — it is the text a person reads at the moment they are stuck. To find out why one particular transition was refused, open the audit log: the AI's reason for that verdict is in the Reason / Expression column.
- The validator lets everything through
- It fails open in three cases: no rule saved, the AI call failed, or no active licence. The last two are both in the audit log, as Validator Failed and as a skipped-unlicensed event. If none of the three applies, use Test Rule on an issue you expect to be blocked and read the reason it gives.
- The post function did nothing
- Look at the issue for the internal failure comment, then at the audit log. If there is neither, the run itself did not happen: the licence, or an instruction whose condition was not met. If the run is recorded as executed but nothing changed, the tool the instruction needs is probably not enabled.
- A message about content moderation
- Forge LLM refused the prompt. Rephrase the rule or the instruction. The app retries transient AI failures twice before giving up, but a moderation refusal is not retried.
- An automation rule started failing
- A validator is refusing the transition your automation performs. Make the automation supply the required data, or scope the validator to human transitions.
Include the workflow name, the transition and an issue key when you open a ticket.