ParticipantFlow for JSM (the “App”) is an Atlassian Forge app for Jira Service Management Cloud. This policy explains what data the App touches when a customer runs it, and what it does not do with that data.
In short: the App has no server of its own, no database, and no analytics. It runs entirely inside Atlassian’s Forge platform, reads and updates a Jira Service Management request’s Request Participants at the moment an Automation rule invokes it, and returns a result back into that same rule. Nothing is stored, logged, or sent anywhere outside Atlassian’s infrastructure.
The App adds one action to Jira Automation: Add Request Participants (ParticipantFlow for JSM). Given a Request/Issue key and a source (a Jira group, an email list, or a list of Account IDs), it adds the resulting people to that request’s Request Participants — without ever removing anyone already there — and returns counts and identifiers for the rest of the Automation rule to use.
Each time the action runs, for the single request specified by the Automation rule, it:
asUser()); the App never sees a password or token.The App runs as a Forge function hosted by Atlassian. It never calls any server operated by the vendor, and it never sends data to any third party. The only network calls the App makes are to Jira’s own REST APIs, within the same Atlassian Cloud site that installed it. Data residency therefore follows the customer’s own Atlassian Cloud data-residency configuration; the App has no infrastructure of its own to introduce a separate region.
| Scope | Purpose |
|---|---|
read:servicedesk-request | Read a Jira Service Management request and its current Request Participants, and confirm the running user’s access to it. |
write:servicedesk-request | Add Account IDs to a request’s Request Participants. |
read:jira-user | Resolve an email address to an Account ID when the email-list source is used. |
manage:jira-configuration | Read Jira group membership when the group source is used. This scope is required by Atlassian’s own Group Members API for this operation; there is no lighter-weight alternative scope. |
These are the only scopes the App requests. Every one of them is used only to read or add data the customer explicitly asked the Automation rule to act on; the App cannot create, delete, or modify anything else in Jira.
None. The App integrates no third-party service, analytics vendor, email provider, or storage provider of its own. The only infrastructure involved is Atlassian’s own Forge platform, which is already covered by Atlassian’s own privacy and security commitments to the customer.
Because the App retains nothing after each Automation run completes, there is no App-held personal data to access, export, or delete. Account IDs added as Request Participants are retained only by the customer’s own Jira Service Management site, under the customer’s own control. If you believe the App has behaved differently from what this policy describes, contact us using the details below and we will investigate promptly.
If this policy changes in a way that affects how the App handles data, we will update the effective date above and, for material changes, note it in the App’s Atlassian Marketplace listing.
Questions about this policy or the App’s data handling: support@asunoki.jp.