FAQ

How the AI is used

Is the AI called every time somebody clicks a transition?

It depends which module. Conditions: no — the AI generates a Jira expression once at setup and the expression is what runs. Validators: yes — the model judges the live issue on every attempt. Post functions: yes, because the action depends on the issue. Only the condition is free at transition time, which is a good reason to prefer it where it can do the job.

Can I see and edit what the AI produced?

For a condition, yes: the generated Jira expression is shown in an editable field with the AI's explanation underneath, and the edited text is the version that runs. Hand-editing it is expected. A validator produces no artefact to edit — it is your sentence, evaluated live — so what you tune there is the rule text, and the Test Rule box is how you check it.

Which AI provider? Do I need an API key?

Atlassian's Forge LLM, with Atlassian-hosted Claude models. No API key and no third-party provider. Expression generation uses a larger model than the validator and the post function, because generating a rule once deserves more care than running one.

Does it read our attachments?

Only the metadata — file name, type, size, uploader and upload date — and only if you enable that context source, on either the validator or the post function. File contents are never read.

What exactly is sent to the AI on a post function run?

A base context that cannot be switched off, plus whatever you toggle on. The full list is on the AI Post Function page and in the privacy policy. If your issue descriptions contain sensitive text, read that list before enabling post functions.

Does anything leave Atlassian?

No. This app declares no external network access at all.

Behaviour and limits

What does the user see when a validator blocks them?

The Error message you wrote on that validator — the same text every time, so write it as an instruction rather than as a rule name. The AI's reason for that specific verdict is not shown to the user; it goes to the audit log.

Can I see a log of what the app did?

Yes, at Jira → Apps → Workflow Toolkit. It records every validator verdict with the reason behind it, every post function run and failure, every expression generated, and the token usage of each AI call. Filter it by date, event type and issue key, and export the range to CSV. Events are kept for 90 days.

Can I use it alongside Jira's built-in conditions?

Yes. Add it next to them on the same transition. They are evaluated independently.

Does it replace Jira Automation?

No, and it should not. Use Automation for deterministic “when X then Y” rules. Use a post function when the action depends on reading the issue.

Can it fire on an issue transitioned via the API?

Yes. Conditions and validators apply to every transition, including API-driven ones. That is often what you want, and occasionally a surprise for an integration.

Operating it

How do I roll this out safely?

Build it on a test project, transition a few issues, and inspect what changed on them. Then publish it on one real workflow, not five.

What if the AI generates a rule I disagree with?

Edit the expression, or write it yourself. The generator is a starting point, not an authority.

Can a non-administrator create these rules?

No. Editing workflows requires Jira administrator rights, which is a Jira restriction rather than ours.

What happens when I uninstall?

The app erases what it holds: it empties the audit table and deletes every key it wrote, then Atlassian detaches whatever is left and destroys it under its own retention policy — see Where your data goes. Your rules travel with the workflow because Jira stores them, so the modules stop working but the configuration is not in our storage to delete. Anything a post function already wrote into Jira stays there. Export the audit CSV first if you need it.

What stops working if our licence lapses?

The validator allows every transition and the post function does nothing, both recorded in the audit log. The condition keeps working, because its expression lives in the workflow and Jira evaluates it — there is no app code at transition time to switch off. Nothing is deleted, every rule stays readable and editable, the audit log and its CSV export stay open, and renewing restores the behaviour with no reconfiguration. The full reasoning is on the overview page.

Why does an expired licence not just block everything?

Because these modules run inside your users' transitions. A validator that kept refusing after a trial ended would freeze the workflow over a subscription you no longer have, and nobody could transition an issue to sort it out. A post function that kept writing would keep changing your issues with nothing on screen to explain it. So one passes and the other stops — the direction that fails safe in each case.