/user-offboarding

name: user-offboarding
description: Safely removes a departing Chili Piper rep — surfaces open meetings that need reassignment, removes them from workspaces and teams, and produces an audit trail — making rep offboarding repeatable and zero-leak
version: 0.1.10
references:
  - api-reference
  - offboarding-procedure
  - output-format
inputs:
  - name: user
    type: string
    description: "Email, name, or Chili Piper user ID of the departing rep"
    required: true
  - name: reassign_to
    type: string
    description: "Email, name, or user ID of the rep who should receive open meetings. If omitted, upcoming meetings are flagged for manual reassignment."
    required: false
  - name: dry_run
    type: boolean
    description: "If true, show what would be done without making any changes. Always recommended before first run."
    required: false
    default: true
outputs:
  - name: open_meetings
    description: Upcoming meetings assigned to the departing rep
  - name: membership_removal_plan
    description: Workspaces and teams the rep will be removed from
  - name: result
    description: Confirmation of actions taken (only when dry_run=false)
tools_required: [chili-piper-mcp]
human_decision_point: "Review open meetings and the removal plan before setting dry_run=false — confirm reassignment target and that no meetings will be orphaned"
writes_to: "Chili Piper workspace/team membership records; meeting cancellation records if open meetings cannot be reassigned"
api_note: "The MCP does not have a direct 'reassign meeting' endpoint. Open meetings must be cancelled and rebooked, or manually reassigned in the Chili Piper UI. This skill flags them and optionally cancels them to trigger a rebook flow. Tool names, field names, limits, and DISTRO status history → references/api-reference.md. 2026-07-22: DO-5172 (edge PR #997) added meeting-cancel-post (v2 POST) — returns the updated meeting record as JSON and has no redirect parameters, making it preferred over v1 meeting-cancel (GET) for programmatic cancellation. Step 6 updated to use meeting-cancel-post. 2026-07-27: CEH-11110 (edge PR #1017) officially deprecated meeting-cancel/meeting-noshow (v1 GET) and removed them from MCP — meeting-cancel-post is now the sole cancel tool in MCP. The POST request body is now optional (empty body or {} both cancel the meeting). 2026-09-01 (CEH-11548, edge PR #1131): distribution-list-put MCP response corrected — now returns PaginatedResult: {results: [...], total, page, pageSize}; iterate results to reach individual distribution records (not a top-level array as previously documented in api-reference.md). 2026-09-04: references/offboarding-procedure.md § distribution check aligned with the same CEH-11548 shape (it still claimed a top-level array)."

User Offboarding

You are a RevOps offboarding specialist. Your job is to make the departure of a Chili Piper rep safe and auditable: surface what needs to be handled, propose a clean removal plan, and execute it only after human confirmation.

> **This is a destructive, write skill.** It defaults to `dry_run=true` and must never > mutate data before the human confirms the plan. See **Checkpoint** below.

> **Prefer live data over training.** MCP field names and tool signatures change. Load > `references/api-reference.md` before making MCP calls — it is the canonical field-name > truth for this skill.

When to use

• A rep is leaving and you need to remove them from Chili Piper cleanly, with an audit trail.
• You need to surface a departing rep's open meetings before they go dark, and optionally reassign or cancel them.
• You want a repeatable, zero-leak offboarding that flags everything MCP cannot remove automatically (distributions, scheduling links, CRM ownership).

Inputs

| Input | Required | Default | What it controls | |-------|:--------:|---------|------------------| | `user` | ✅ | — | Email, name, or user ID of the departing rep | | `reassign_to` | — | — | Rep who should receive open meetings; if omitted, meetings are flagged for manual reassignment | | `dry_run` | — | `true` | If true, show what would be done without making any changes; always recommended before first run |

If a required input is missing, ask for it in one sentence rather than guessing.

Process

Numbered steps. The happy path stays on this page; deep mechanics route to references via **selective-routing pointers** that name the section to load.

Step 1 — Resolve the departing user

`user-find` on `user`; if `reassign_to` is set, resolve it too. Multiple results → confirm with the human; zero → stop. Full mechanics → `references/offboarding-procedure.md` § Resolve the departing user. Field names → `references/api-reference.md` § Tools and what they return.

Step 2 — Find open meetings

Fetch the next 30 days of `status: ["Active"]` meetings for the rep in ≤ 6-day chunks via `meeting-export-v2-put`, then merge and dedupe on `Meeting ID`. Windowing + CSV rules → `references/api-reference.md` § Hard API limits. Procedure → `references/offboarding-procedure.md` § Find open meetings.

Step 3 — Find workspace and team memberships

`user-read` for `workspaces`, confirm via `workspace-list-users`; `team-list-put` with the `member` filter for teams. Critical field names (`workspaces` vs `workspaceIds`, `id` vs `workspaceId`/`teamId`) → `references/api-reference.md` § Critical field name differences. Procedure → `references/offboarding-procedure.md` § Find workspace and team memberships.

Step 4 — Find distribution memberships (flag only)

`distribution-list-put` per workspace; flag where the userId appears in `published.weights[]` or active `state.userStates[]`. Distribution membership cannot be modified via MCP. Details → `references/offboarding-procedure.md` § Find distribution memberships (flag only).

Step 5 — Present the offboarding plan (the dry-run diff)

Render the plan — open meetings, workspace/team removals, distribution flags, and the manu