Passdown is a Jira Service Management app built primarily on Atlassian Forge, with one small hosted component used only to read your on-call schedule (see Security for why). This policy explains what data Passdown accesses, what it stores, and what it does not do with either.
What Passdown accesses
To write a summary, Passdown reads a ticket's summary, comments, status history, and
relevant fields, using the read:jira-work scope. To post the handoff and
reassign a ticket, it uses write:jira-work. To detect shift boundaries, it
reads on-call participant data (who is currently on-call on a schedule) using
read:ops-config:jira-service-management. It does not read fields or
tickets unrelated to generating a summary or checking on-call state.
What Passdown stores
One small record per on-call schedule, holding only who is currently on-call for that schedule. This record is overwritten every time the schedule is checked and is used solely to detect the next change — it never accumulates history, and no ticket content or generated summary text is ever stored. Passdown keeps no database of past handoffs or summaries.
Where your data goes
Ticket content and summary generation stay inside Atlassian's platform: Passdown's resolvers and its Atlassian-hosted AI model calls run entirely on Forge. The one exception is reading the on-call schedule itself, which is proxied through a small hosted component (a Cloudflare Worker) operated by Isogun Labs, using a token scoped to that single read — see Security for the full technical detail and why this exists. That component does not see ticket content or generated summary text; it only relays schedule/on-call data.
Data retention and deletion
The one stored record per schedule is deleted when the app is uninstalled. Since no ticket content, comment text, or generated summaries are ever stored, there is nothing further to retain or delete for those categories.
Contact
Questions about this policy or Passdown's data handling can be sent to support@isogunlabs.com.