Responsibilities

Responsibilities define who is engaged with work on inboxes, workflows, phases, and tasks — who acts, who approves, who is kept in the loop, and who picks up the work when someone else doesn't. Unlike roles and policies (which govern what you can access globally), responsibilities grant instance-scoped permissions: assignments on a specific entity grant permissions on that entity, resolved through the linked IAM Role's policies.

Engagement Types (RACI + Backup)

Nembl ships with six system responsibilities per company, each mapped to a RACI-style engagement type:

System responsibilities are non-deletable and their names and engagement types are locked. You can change the IAM Role they link to, which lets you customize exactly which permissions flow through each engagement type.

Custom Responsibilities

Beyond the six system responsibilities, you can define your own — for example:

• QA Reviewer (Consulted engagement, linked to a custom "qa-reviewer" IAM Role with policies you've authored)
• Compliance Watcher (Informed engagement, linked to a role that also gets access to the audit trail)
• Budget Approver (Approver engagement, same permission set as the system Approver but a distinct name for reporting)

Creating a custom responsibility

1. Admin → IAM → Responsibilities → New Responsibility
2. Name — what you'll see in the picker (e.g. QA Reviewer)
3. Engagement type — one of the six. Drives default notification behavior and the "exactly one Accountable" invariant.
4. Linked IAM Role — pick any role in your company. The role's attached policies define the actions this responsibility grants when assigned.
5. Description and default notification toggles (see below).

When unlinked from an IAM Role, the responsibility falls back to a legacy hardcoded permission map — a warning is logged, and you should link a role as soon as possible.

Assignable Principals

You can assign any of these principal types to a responsibility on an entity:

• Users — individual team members
• Agents — AI agents
• Teams — all members of the team (expanded at resolution time)
• Groups — users, teams, and agents in the group
• Organizations — all teams in the organization

Important constraint: the Accountable principal must be a user, agent, or team — not a group or organization (too diffuse for a single point of accountability).

Where Responsibilities Apply

Inbox (Queue) Responsibilities

Assign parties to an inbox to control who is notified when new requests arrive and who can act on them.

Admin → Inboxes → select an inbox → Responsibilities section

Workflow Responsibilities

Assign a matrix at the workflow level and it is inherited by every phase of that workflow. Use this when the same group of people handle an entire process.

Admin → Workflows → select a workflow → Responsibility Matrix picker

Phase Responsibilities

Phase-level assignments override anything inherited from the workflow. Use this for phases that need different approvers, specialist consulters, or dedicated agents.

Open the workflow editor → click a phase → Responsibilities section

Instance-Level Override

When launching a specific workflow run from Run Workflow, the modal includes a Responsibility Matrix picker. Choose a different matrix to override the workflow-level default for that single run — useful for escalations, temporary reassignments, or parallel runs that need different stakeholders.

Inheritance Order

The resolver walks most-specific to least-specific and grants permission on the first level where you have a matching assignment:

instance matrix  →  task  →  phase  →  workflow  →  inbox

Notification Defaults

Each responsibility has three notification toggles that seed onto new assignments using it:

• Notify on assign — when a principal is first assigned or when work reaches their phase (default: on)
• Notify on phase change — every time the workflow advances (default: off to reduce noise)
• Notify on overdue — when an escalation deadline fires (default: on)

These are defaults — every assignment can override them individually, either in the matrix editor or on the per-entity Responsibility editor.

Team Escalation Target

When a team is Accountable on an overdue phase, the escalation cron resolves a single escalation target for that team — it does not spam every member. Each team configures its escalation strategy:

Configure at Admin → Teams → select a team → Escalation target card.

Managing Assignments

Using the Responsibility Editor

The editor appears inline on inbox detail pages and phase property panels:

1. Add — pick a principal type (User / Agent / Team / Group), pick the principal, pick a responsibility
2. Agent config — for agents, set autonomy level and allowed actions (these drive how the agent behaves when its phase activates)
3. Remove — the X button on any row
4. Priority — numeric ordering for display / escalation-preference purposes

Using a Responsibility Matrix

When the same assignments apply across multiple inboxes or workflows, define a named Responsibility Matrix once and apply it everywhere. See Responsibility Matrices.

Best Practices

• Exactly one Accountable per entity — enforced by the matrix editor and server-side validation.
• Use Backup assignments for SLA-sensitive phases so overdue alerts reach someone even when the Responsible party is unavailable.
• Use teams for shared responsibility rather than picking a single individual — the team escalation target still ensures a single person is paged on overdue, but vacations and handoffs become invisible to process design.
• Assign agents as Responsible when you want them to drive the phase autonomously. Assign them as Consulted when you want analysis without advancement.
• Prefer matrices over ad-hoc when the same assignment pattern appears on more than two entities — maintenance becomes a single edit.