Jira & Confluence · Available
Every ticket closed, every page shipped, credited to a person.
Install a thin Forge app and link your site, and the previous 90 days load before the first live change arrives. One manifest covers both Jira and Confluence — there is no second thing to install.
- Status
- Available
- Authenticated with
- An RS256 Forge Invocation Token, verified against Atlassian’s JWKS on every request. There is no Atlassian credential of our own to store, rotate or leak.
- Becomes
- tickets_created · tickets_closed · comments · pages_created / pages_edited
What it sends
What arrives, and what it becomes on a board
| When | Becomes | Worth knowing |
|---|---|---|
| An issue is created | tickets_created | One per issue, from the Forge trigger Atlassian fires the moment it is filed. |
| An issue is resolved | tickets_closed | Watches Jira’s own resolution field moving from empty to set — not a status name — so it works whatever your last column is called. Reopening and resolving again is a second close, which is also what a person watching the board would count. |
| A comment is added | comments | That one was added, and by whom. Never its text. |
| A Confluence page is created or edited | pages_created / pages_edited | Every version bump counts, not only the first publish. |
Moving a ticket between columns without resolving it is real work, but rewarding it as a ranked measure rewards moving tickets between columns — so an update that resolves nothing contributes none of the metrics above.
Setting it up
Three steps, and none of them is a ticket to us.
- 01
Install the Forge app
From your Jira or Confluence site’s app marketplace. It is a manifest naming which events to forward — no JavaScript runs inside your site, and no UI shows up in it.
- 02
Link the site
One OAuth click from the Integrations page inside the product connects the site to this organization and starts loading the previous 90 days.
- 03
Link identities once
An Atlassian account whose email matches a member is linked automatically. The rest appear on the identities page, with the actor’s real Jira email attached as a hint rather than a guess.
What it will not do
The refusals, in writing.
- Read what a comment or a page says. It knows one was added and by whom, never the text.
- Write anything back. The manifest ships with no write scopes — no comments, no transitions, no labels, on either Jira or Confluence.
- Hold your Atlassian credentials. Every invocation token is minted fresh by Atlassian for that one request and never stored.
- Count the same change twice. A live event and a backfilled one build the same key from Jira’s and Confluence’s own ids, so re-running the backfill is always safe.
Questions
The ones that come up
Does this need admin on our Atlassian site?
Installing a Forge app needs the same permission installing any app does — usually site admin, granted once. It asks for no more than that; the manifest carries no elevated or write scopes.
What if our last column is not called “Done”?
It does not matter. This watches Jira’s own resolution field rather than a column name, so a project calling it Shipped, Live or Resolved works identically.
Can you read anything back out of Jira or Confluence?
No. The connector runs inside a five-second trigger budget with no room for a callback, the invocation token is verified and dropped, and nothing installed holds a credential to fetch with afterward.
Why one integration for two products?
One Forge app, one manifest. Confluence’s page events ride the same triggers and the same normalizer as Jira’s issue events, so turning one on is not a second thing to install.