Documentation

Everything you need to understand how Passdown works, before and after it installs.

Overview

Passdown solves one specific gap: every shift-based support team loses time at the start of a shift reconstructing what the previous person already knew. Passdown reads what actually happened on a ticket — comments, status changes, fields — and writes a plain-language account of it. The flagship feature fires automatically at shift boundaries, read from Jira Service Management's own on-call schedule. The same engine also runs on demand, for a single ticket, any time someone needs to catch up fast.

Passdown does not build or replace any rotation, scheduling, or delegation logic — it reads the schedule an existing JSM setup already maintains.

Requirements

  • A Jira Service Management Cloud project with an on-call schedule configured (for the automated shift-handoff feature — the on-demand per-ticket summary works on any Jira Cloud issue).
  • The installing admin's account needs visibility into the on-call schedules Passdown should watch.
  • An active Passdown subscription for installations above the free tier — see Licensing & billing.

Installation

Passdown is live on the Atlassian Marketplace. Install it directly from the Marketplace listing.
  1. A Jira site administrator installs Passdown from the Atlassian Marketplace listing onto their Jira Service Management Cloud site.
  2. The install confirms the requested permission scopes (see Data & permissions) before completing.
  3. Once installed, the on-demand summary panel appears on issue views automatically, and the scheduled shift-boundary check begins running against any on-call schedules the app can see.

The shift-handoff brief

Passdown checks the on-call schedule at a short interval. When it detects that the on-call person for a schedule has changed:

  1. It finds every ticket still open and assigned to the outgoing person.
  2. For each one, it generates a plain-language brief covering what happened during the shift, what's currently blocking (if anything), and what remains to be done.
  3. The brief is posted as a native Jira comment with the incoming person @-mentioned.
  4. The ticket is also reassigned to the incoming person — the primary, guaranteed notification signal, since an app-authored mention is not confirmed to reliably trigger Jira's own notification pipeline the same way a human mention does.
A schedule whose current on-call is a team or an escalation, rather than a single person, is skipped for this automatic handoff — there's no single incoming person to assign to. This is a known, current limitation, not a silent failure.

On-demand ticket summary

The same generation engine is also available as a panel on any individual ticket. Open it any time — mid-shift, after time off, picking up an escalation — to get a plain-language summary of that ticket's history without waiting for a shift boundary.

Roadmap: Slack & Teams

Pushing the handoff brief to Slack or Teams, in addition to the native Jira comment, is planned as a future release. It will be an explicit, admin-controlled opt-in — off by default, and not part of the current build.

Data & permissions

  • Reads ticket content: read:jira-work — summary, comments, status history, and fields needed to write an accurate summary.
  • Posts comments and reassigns tickets: write:jira-work.
  • Reads the on-call schedule: read:ops-config:jira-service-management, used only to detect shift boundaries.
  • Bounded storage: storage:app — one small record per on-call schedule (who's currently on-call), overwritten every check, never a growing history.

Full detail, including the hosted component used to read the schedule, is in the security policy and privacy policy.

Licensing & billing

Passdown is free for small teams (up to 10 users on the installation), with a paid tier above that threshold, billed through Atlassian. This mirrors the visibility-first pricing approach used for Isogun Labs' other early-stage apps — the goal right now is installs and real usage, not maximizing near-term revenue.

Troubleshooting

A shift boundary happened, but no brief was posted.

Check whether the outgoing person had any open tickets assigned to them at the time — Passdown only acts on tickets that were actually open and assigned. Also confirm the on-call schedule's current participant is a single person, not a team or escalation (see The shift-handoff brief).

The @-mention didn't send a notification, but the ticket was reassigned.

This is expected behavior, not a bug — reassignment is the guaranteed signal by design. The mention is a best-effort addition on top of it.

Support

Questions, problems, or feedback? Email support@isogunlabs.com. Best-effort support; typical response time is 1–2 business days.