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 has been submitted to the Atlassian Marketplace and is currently in review. Once approved, it will be installable directly from the Marketplace listing. In the meantime, contact us to be notified when it goes live.
  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.