Lifecycles

A lifecycle defines the states a party can be in and the transitions between them. A new vendor walks from prospect to due-diligence to qualified to active. An applicant might walk applied → screening → conditional-offer → enrolled. Each state and each transition is part of the lifecycle definition.

Lifecycles are versioned. The current shape that governs party transitions is one version of the lifecycle definition; previous versions remain referenceable for parties already past those transitions. Audit reviewers see what lifecycle version a party walked at the time, not what the lifecycle looks like now.

When you would reach for this

You define a lifecycle when:

• A party type’s journey needs structure: defined states, allowed transitions, sign-off discipline.
• An existing lifecycle needs evolution: a new state, a tightened transition rule, a removed shortcut.
• A regulator or framework requires audit-grade evidence of how parties move through onboarding or qualification.

You don’t reach for this for one-off parties. Lifecycles are reusable definitions.

What lives in a lifecycle

Three record types:

Lifecycle definition is the named lifecycle (“vendor onboarding,” “buyer onboarding,” “candidate screening”). It carries a key, a name, an owner.

Lifecycle version is a specific revision of a definition. Each version captures the full state graph: the named states, the allowed transitions, the conditions and actions that apply per transition. Versions move through draft → published → retired.

Step instance is one party’s actual walk through a lifecycle. It captures which lifecycle version applies, which state the party is currently in, the history of transitions taken, the timestamps, the actors.

A new party starts a step instance from the current published version. As they transition, the step instance records the journey.

A worked example: the procurement marketplace’s two lifecycles

Felipe defines two lifecycle definitions for the marketplace.

Lifecycle 1: vendor-lifecycle. Vendors walk these states:

prospect
  → due-diligence       (transition: vendor submits intake form)
  → qualified           (transition: due-diligence approved by compliance + category lead)
  → active              (transition: vendor agreement signed)
  → suspended           (transition: any party with suspend role triggers)
  → closed              (transition: from active, suspended, or any earlier state, with rationale)

The first published version of this lifecycle captures these states and transitions, plus the conditions (eligibility rules in the next page) and actions (forms, responsibilities, approvals).

Lifecycle 2: buyer-lifecycle. Buyers walk:

prospect
  → kyc-checked         (transition: KYC verification completed and approved)
  → active              (transition: buyer agreement signed)
  → suspended
  → closed

Both lifecycles share the suspended and closed terminal handling patterns; their middle states differ because the work is different.

Six months later, the buyer lifecycle needs a new state: enhanced-due-diligence for buyers in higher-risk categories. Felipe creates a new version of buyer-lifecycle adding the state. The old version remains; buyers already past their KYC walk under the old version’s transitions. New buyers walk under the new version. The audit can see which version each buyer was processed against.

Transitions and what they trigger

Each transition can carry:

• A precondition referencing one or more eligibility rules.
• A form that must be completed as part of the transition.
• A responsibility that owns the transition decision.
• A review-approval requirement that gates the transition behind named sign-off.
• A bound action that fires on transition (notification, lifecycle hand-off, evidence request).

A vendor’s transition from due-diligence to qualified, in Felipe’s setup, requires:

• Precondition: the financial standing eligibility rule passes.
• Form: the compliance review form is completed and submitted.
• Responsibility: the compliance officer (specific responsibility assignment).
• Review-approval: a category lead must approve before transition fires.
• Bound action: on approval, notify the vendor that they’re qualified.

What you’ll see in the product

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

The Definitions list shows every lifecycle with current published version, kind, owner, count of parties currently walking it.

Inside a definition, you see versions with status. The current published version shows the state graph visually.

Inside a version, you see the states, the allowed transitions, the bindings per transition.

Step instances are visible per party from the party’s record.

Every change is captured in the workspace Audit Log.

Versioning fidelity

A lifecycle version, once published, doesn’t change. A new revision creates a new version; the old version remains. Parties walking under the old version stay on it; new parties walk under the new version (or are explicitly migrated).

This matters because audit reviewers ask: “what process did this party walk through?” The answer is “this version of the lifecycle, with these states and these gates, as published on this date.” The fidelity prevents quiet rewriting of history.

Common workflows

Defining a new lifecycle

1. Lifecycles → New definition. Pick name, key, owner.
2. Create the first draft version: states, transitions, bindings.
3. Review and publish.
4. Reference the lifecycle from the relevant party type’s default lifecycle.

Revising a lifecycle

1. From the definition, create a new version draft from the current.
2. Add states, modify transitions, update bindings.
3. Decide migration policy: do existing parties stay on the old version (typical) or move to the new (only when justified).
4. Publish.

Walking a party

1. A party of the type is created.
2. A step instance is automatically created on the current published version.
3. Each transition is recorded in the step instance.
4. The party moves through the lifecycle, with each transition carrying its forms, approvals, and bound actions.

Related

• Overview - the full party governance story.
• Party Types - types reference lifecycles.
• Eligibility - rules gating transitions.
• Forms - forms bound to transitions.
• Review & Approval - approvals gating transitions.
• Responsibilities - duties owning transitions.