run_68e665559ae42bc7

input

{
  "request": "Triage Jira ticket MZCLD-3653: implement PagerDuty offboarding",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/MZCLD-3653"
  ],
  "sourceContext": {
    "issue": "MZCLD-3653"
  }
}

summary

MZCLD-3653 is a Backlog ticket requesting implementation of automated PagerDuty offboarding for departing employees. The ticket currently has no description detail beyond the initial observation, no comments, and no linked runbook or design doc to reference. Triage recommendation: gather requirements (identity source of truth, trigger event, PagerDuty API scope needed) and route to the IAM/identity-lifecycle automation owner, since this overlaps with existing employee offboarding workflows (e.g., LDAP/Workday-triggered deprovisioning) rather than being a standalone PagerDuty-specific effort.

findings

• Ticket is a bare feature request with minimal detail: it only states that PagerDuty offboarding is not happening and should be automated. No acceptance criteria, no technical design, no linked runbook/Confluence doc.
• No references (Confluence runbook/design doc) are attached to the ticket or provided in the trigger beyond the Jira issue link itself, so there is no existing design to validate against.
• Status is still 'Backlog', meaning no work has started; this is a planning/requirements-gathering stage ticket, not an in-progress implementation needing a status update.
• The request implies dependency on an identity lifecycle event (employee exit trigger) which is typically owned by IAM/HR-integration systems (e.g., Workday/LDAP deprovisioning hooks) rather than being solvable purely within PagerDuty tooling.

proposed actions

Thanks for filing this. Before moving this out of Backlog, we should nail down a few things:

1. **Trigger source**: What system signals an employee exit that we can hook into (Workday, LDAP/AD deprovisioning event, People-Ops ticket, etc.)? Is there an existing offboarding automation pipeline we should plug into rather than building a PagerDuty-specific one?
2. **Scope of 'offboarding' in PagerDuty**: Does this mean removing the user entirely, or just removing from schedules/escalation policies and disabling login while preserving incident history/audit trail?
3. **API/permissions**: PagerDuty's REST API supports user deletion and removal from schedules/escalation policies - we'd need a service token with appropriate admin scope. Can we confirm the auth approach (e.g., existing service account vs. new dedicated integration credential)?
4. **Runbook/design doc**: No existing runbook or design doc is linked. If one exists elsewhere, please link it; otherwise we should draft a short design doc covering trigger, API calls, error handling (e.g., user still on-call), and idempotency before implementation.

Recommend keeping this in Backlog until requirements above are captured, then re-triage with an owner (likely IAM/identity-lifecycle team given the dependency on the employee-exit trigger) and estimate.

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3653"
    },
    "result": {
      "key": "MZCLD-3653",
      "summary": "implement PagerDuty offboarding",
      "status": "Backlog",
      "description_text": "As near as I can tell, we\u2019re not doing any offboarding for PagerDuty when employees exit. We should do that. Preferably automated.",
      "comment_count": 0,
      "comments": []
    }
  }
]

log