Plan

Plan is Sankofa's project-management product. It's a full ticketing system — boards, tickets, sprints, releases, workflows, pages, comments, attachments, time entries — but uniquely bonded to the rest of the Sankofa platform: deploys, crash reports, session replays, and revenue events.

The bond means you can:

• Open a ticket and see every Catch issue, Switch flag, Deploy release, and replay tied to it.
• Group tickets by release and see what user-visible behavior shipped together.
• Filter tickets by the cohort they affected.
• Migrate from Jira in one go via the built-in importer.

Plan is dashboard-driven — there's no Plan SDK call in your app code. Integration is via the REST API + webhooks for tools that need to talk to it (CI, Slack, on-call rotations).

The Plan model

1. Boards

   Top-level container. A board is a collection of tickets sharing a workflow, field schema, and members. Most teams have one board per project, sometimes split by surface (e.g. "iOS", "Backend", "Growth").

2. Tickets

   The atomic unit. Tickets have a title, description, assignee, priority, status (mapped to the board's workflow), labels, and arbitrary fields defined by the board's field schema. Tickets attach files, link to other tickets, and bond to deploys + Catch issues + replays.

3. Sprints

   Time-boxed groupings of tickets with a start and end date. Sprints aggregate burn-down, velocity, and completion metrics.

4. Releases

   Versioned bundles of completed work. A release groups the tickets that shipped together and bonds to the corresponding Deploy bundle (when one exists).

5. Workflows

   The state machine that governs ticket transitions — Backlog → In Progress → In Review → Done, or whatever your team uses. Workflows are per-board, with role-based transition rules.

6. Field schemas

   Per-board custom-field definitions — text, number, date, select, multi-select, person, relationship. Field schemas are versioned, so changes don't retroactively invalidate historical tickets.

7. Pages

   Long-form documentation living alongside tickets — design specs, retros, decision records. Pages are versioned, link to tickets, and search alongside ticket content.

Bonded views

The cross-product bonds are what make Plan different from a stand-alone tracker. From any ticket you can:

These bonds are computed by the engine — you don't manually link them. The matching is based on shared release IDs, cohort intersections, and stack-trace fingerprints.

Workflows

A workflow is a directed graph of statuses with role-gated transitions. The default board workflow ships pre-configured:

• Backlog → Triaged → In Progress → In Review → Ready → Done
• Done → Backlog (reopen)
• Any status → Won't Do (close without resolution)

Each transition can require:

• A specific role (Editor to move to "In Review", Admin to move to "Done");
• Required custom fields filled (e.g. "estimate" required before "In Progress");
• A linked Deploy release (e.g. "Done" requires a release attached).

Workflows are editable per-board from /dashboard/plan/<board>/settings/workflow.

Sprints, releases, roadmaps

Sprints, releases, and roadmaps share the same ticket pool — moving a ticket between them is a metadata change, not a copy.

Jira migration

Plan ships a one-shot Jira importer that preserves:

• Tickets (with all custom fields mapped to Plan field schemas)
• Comments (with original timestamps and authors)
• Attachments
• Sprints + releases (mapped to Plan equivalents)
• Workflows (mapped 1:1 where shapes align, with manual review prompts where they don't)
• Member assignments (matched by email; un-matched users are flagged for invitation)

Run the importer from /dashboard/plan/migrate/jira. The migration runs in dry-run mode first — you review the diff, then commit. Re-running an import is incremental: only changed tickets are updated.

The importer engine lives in ee/plan/migrations/jira/.

Pages

Plan Pages are long-form Markdown docs that live alongside your tickets. They're useful for:

• Design specs linked from one or more tickets.
• Retros that summarize what shipped (or didn't) in a release.
• Decision records with their own ticket-linkage so the rationale survives the original conversation.
• Internal runbooks that benefit from inline ticket references.

Pages support full Markdown plus the same embed system used in tickets — you can drop a Catch issue, a Deploy release, or an Analytics insight directly into a page.

Notifications + integrations

Plan emits events to:

• Sankofa's audit log for every change.
• Webhooks you configure per board (/dashboard/plan/<board>/settings/webhooks).
• Slack via the standard Slack integration — per-board channel routing, configurable event filters.
• Email to assignees + watchers, with digest controls per user.

The webhook payload is documented at API → Webhooks.

API surface

Plan exposes a full REST API at /api/v1/plan/*. Endpoints include:

Authenticate with the dashboard JWT (project-role RBAC enforced); the public API key (sk_live_*) does not have Plan write access.

Plan limits by tier

What's next