Responsibility Matrices

A Responsibility Matrix is a named, reusable bundle of assignments that you can apply to an inbox, workflow, phase, or specific workflow run. If the same RACI pattern appears in more than one place in your company — say, every incident-response workflow has the same on-call lead as Accountable and the same SRE team as Responsible — defining that pattern once as a matrix keeps it consistent and easy to change.

Matrices live at Admin → IAM → Responsibility Matrices.

When to Use a Matrix vs. Ad-hoc Assignments

You can mix both: applying a matrix to an entity preserves any ad-hoc assignments already on that entity — the resolver returns both sets. Ad-hoc rows have a null matrixId; matrix-sourced rows are tagged with the matrix they came from.

Creating a Matrix

1. Admin → IAM → Responsibility Matrices → New Matrix
2. Name and description. Names must be unique within your company.
3. On the detail page, click Add assignment:
   • Choose a Responsibility (system Accountable / Responsible / Approver / Consulted / Informed / Backup, or any custom responsibility you've created)
   • Choose a principal via the tabbed picker: Users, Agents, Teams, Groups
   • Per-assignment notification toggles seed from the responsibility's defaults — override per row as needed
4. Repeat for every role you want the matrix to carry.

Invariants enforced on save:

• At least one assignment
• Exactly one Accountable
• The Accountable principal must be a user, agent, or team (groups are blocked for Accountable — too diffuse)

Applying a Matrix to an Entity

To a workflow

Admin → Workflows → select a workflow → Responsibility Matrix section

Applying a matrix at the workflow level populates assignments that are inherited by every phase of that workflow unless a phase overrides them.

To an inbox

Admin → Inboxes → select an inbox → Responsibility Matrix section

To a phase

Phases use ad-hoc assignments via the Responsibility editor in the workflow builder. To apply a matrix at phase level, use the per-phase editor and replicate the desired assignments (matrix-to-phase apply is planned for a follow-up UI).

Instance-Level Override + Per-Run Customization

When you launch a specific workflow run from Run Workflow, the modal shows a Responsibility Matrix picker plus a Customize for this run option:

• Use workflow default — the resolver falls back to whatever the workflow / phases have configured (includes any applied matrix).
• Pick any company matrix — that matrix's assignments apply to every phase and task of this one run, overriding entity-level configuration.
• Customize for this run — open the matrix in DRAFT mode for this instance only. You can swap individual principals, add/remove assignments, or change notification toggles. Save closes the draft and starts the instance with the customized assignments.

Per-run customizations are scoped to this one workflow instance. They do not affect the source matrix, do not leak into other instances, and do not survive to future runs. The customized snapshot is recorded on the instance itself.

Instance Matrix Snapshots

Every workflow instance captures a snapshot of its effective matrix at launch time in the database (per Phase 39J). This means:

• The instance viewer always shows who was Responsible / Accountable / Consulted / Informed at the moment that specific instance started — even if the source matrix has been edited since.
• Mid-flight matrix edits do not silently change who's on the hook for a running instance (with one exception below).
• Audit log entries for instance_matrix.* actions reflect the per-instance snapshot, so accountability stays attributable.

The one exception: instances that were launched with Pick any company matrix (without per-run customization) still resolve via reference. Edits to that matrix propagate. Instances launched with Customize for this run are fully snapshotted and never change.

Cloning

From the matrices list, click the Clone action to duplicate a matrix and its assignments. The clone is named {original} (copy) (or (copy 2), (copy 3) … if needed). You'll land on its detail page where you can rename, edit, and save.

In Use By

The matrix detail page shows which entities and workflow instances currently reference the matrix:

• Entities — inboxes, workflows, phases, services, offerings where this matrix is applied (keyed by entity type and ID)
• Workflow instances — up to 50 recently-launched runs that picked this matrix via the instance override

A matrix can only be deleted when it's not in use anywhere. The delete button is blocked with a message when references exist.

Notification Behavior

When the workflow engine notifies responsible parties (phase activation, phase change, overdue), each assignment's notifyOnAssign / notifyOnPhaseChange / notifyOnOverdue toggles are honored. This makes it easy to add, say, an "Informed" stakeholder who is only pinged when something goes overdue — not on every phase transition.

Change Propagation

Applying a matrix copies its assignments into the entity's EntityResponsibility rows (tagged with the matrix's ID). This means:

• Editing the matrix later does not automatically update entities that were already seeded from it. To propagate changes, re-apply the matrix on each entity.
• Instance-level application via "Pick any company matrix" stores a reference, not copies — edits to the matrix do affect live instances that picked it without customizing.
• Per-run customization (DRAFT instance flow) writes a full snapshot to the instance — edits to the matrix do not affect those instances.

This three-mode design lets matrices be used as:

• Starting templates at the entity level — running workflows shouldn't suddenly change stakeholders
• Live governance handles for ongoing instances — a specific run's stakeholder list can be deliberately overridden and kept in sync via "Pick any company matrix"
• Frozen per-run records when needed — "Customize for this run" gives a guaranteed-stable audit trail for compliance-sensitive runs

Audit Trail

Every matrix CRUD and apply/clear action writes an audit log entry, scoped by audit prefix:

• responsibility_matrix.* — matrix-level changes:
  • .create, .update, .delete, .assign, .update_assignment, .remove_assignment
  • .apply (attaching to an entity), .clear (detaching)
• instance_matrix.* — per-instance matrix snapshot changes (Phase 39J):
  • .snapshot (written when an instance starts), .customize (per-run customization saved before instance launch)

See Admin → Audit Trail to review who changed what, when. Instance-scoped matrix changes are filterable by the instance ID alongside the matrix ID.