Responsibilities

A responsibility is a named duty inside your workspace: “compliance officer for vendor due diligence,” “category lead for industrial-components vendors,” “buyer credit assessor.” Each responsibility is assigned to one or more members or roles, and the assignment is the audit-grade record of who owns what.

Without responsibilities, party work sits in queues with ambiguous ownership. With them, every transition, every approval, every notification has a defined owner whose name appears in the audit trail.

When you would reach for this

You define responsibilities when:

• A specific kind of party work needs a named owner, not just a team.
• A regulator or framework requires defined ownership of specific tasks.
• Approval routing on lifecycle transitions needs to flow to a defined responsibility-holder.
• A backup or escalation chain needs to be explicit.
• An audit needs to see “who was responsible for X at the time Y happened.”

You don’t reach for this for ad-hoc work or individual tasks. Responsibilities are for standing duties.

What lives in a responsibility

Two record types:

Responsibility definition is the named duty. It carries:

• A name and a stable key (compliance-officer-vendor-dd, category-lead-industrial-components).
• A scope (which kinds of work this responsibility owns).
• A status (active, retired).

Responsibility assignment is one assignment of a responsibility to one member (or role). It carries:

• The responsibility.
• The subject (member or role).
• A start date and (when applicable) an end date.
• A backup or escalation reference (when the primary is unavailable).
• A status (active, expired, revoked).

A single responsibility can have multiple concurrent assignments (multiple compliance officers for different vendor categories) and rotates assignments over time as the team changes.

A worked example: the procurement marketplace’s responsibility map

Felipe defines the responsibilities his marketplace governance program needs.

Responsibilities for vendor onboarding:

• compliance-officer-vendor-dd — owns the compliance review portion of vendor due diligence. Currently assigned to two team members; either can act.
• category-lead-industrial-components — owns category qualification for industrial-components vendors. Assigned to one member with a backup.
• category-lead-packaging — for packaging vendors.
• category-lead-logistics — for logistics vendors.

Responsibilities for buyer onboarding:

• buyer-credit-assessor — owns buyer KYC and credit assessment.
• buyer-account-officer — owns ongoing buyer relationship.

Responsibilities for ongoing engagement:

• vendor-account-officer — owns ongoing vendor relationship.
• marketplace-compliance-lead — owns the marketplace’s overall compliance posture; final approver for high-stakes transitions.

Lifecycle transitions in the Lifecycles module reference these responsibilities. The due-diligence → qualified transition on the vendor lifecycle routes to whoever currently holds compliance-officer-vendor-dd plus the relevant category-lead. When responsibilities are reassigned (a team member changes roles), the new assignment takes effect immediately for new transitions, while historical transitions retain the assignment that was in effect at the time.

What you’ll see in the product

Responsibilities lives under Governance → Party → Responsibilities in the workspace.

The Definitions list shows every responsibility with its key, scope, current assignment count, status.

Inside a definition, you see:

• The full record and scope.
• Current and historical assignments.
• The lifecycle transitions, review-approval workflows, and other records that reference this responsibility.
• Activity history.

Every change is captured in the workspace Audit Log.

Why responsibilities, not just roles

A role grants permissions (see Roles & Permissions). A responsibility owns a duty. Both matter, and they’re different.

• Many members hold the same role (everyone in the compliance team has the “Compliance” role).
• A responsibility names a specific duty within that role; only some members hold it (“compliance officer for vendor due diligence” is a subset of the compliance team).

Responsibilities let governance say “this work routes to a specific named person or rotation,” not “this work goes to whoever in the compliance team happens to pick it up.”

Common workflows

Defining a responsibility

1. Responsibilities → New definition. Pick name, key, scope.
2. Activate.

Assigning to a member

1. From the responsibility, create a new assignment.
2. Pick the subject (member or role).
3. Set start date and (optionally) end date.
4. Activate.

Rotating assignments

1. End the outgoing member’s assignment (set end date).
2. Create a new assignment for the incoming member.
3. The transition is captured in the audit trail; new work routes to the new assignment immediately.

Investigating ownership at a point in time

1. From the responsibility, look at the historical assignment list.
2. Filter by the time period of interest.
3. The audit-grade record shows who held the responsibility when.

Related

• Overview - the full party governance story.
• Lifecycles - transitions route through responsibilities.
• Review & Approval - approval routing references responsibilities.
• Roles & Permissions - the permission layer is distinct from responsibilities.
• Members & Invitations - the members holding responsibilities.