Human tasks, identity and application interactions#

Workflow owns the authoritative human task: its eligibility, claim, decision, expiry and effect on process progress. Messages owns the notification and recipient read/dismiss state. The business application owns its interaction form, business permissions and committed domain change.

This separation permits a task to remain valid when a browser disconnects or notification delivery is delayed. It also prevents viewing a message, following a link or dismissing an inbox item from being treated as approval.

Human task authority stays in Workflow while Messages delivers the notification and the owning application commits the interaction.
Human task authority stays in Workflow while Messages delivers the notification and the owning application commits the interaction.Open diagram ↗

Roles and performers#

Concept Meaning
Principal An enrolled human or workload identity
Group selector A stable reference used to resolve human candidates
Authorization policy The owner's current permission rules
Workflow Role A business responsibility with an input/outcome contract
Human binding An approved selector, interaction and policy for that responsibility
Actual performer The authenticated person who commits the decision

A Workflow Role does not grant identity-provider permissions. A group identifies possible responders, while one actual human claims and completes a task in the documented profile. A service account does not become a human because it has a similar role label.

Stable identity and current authorization#

New task and recipient records use installation-scoped PrincipalId with explicit tenant scope. Validated provider aliases map to that identity through approved enrollment. Email, display name and a matching bare subject must not automatically link accounts.

Workflow's identity projections provide labels, lifecycle and synchronization status. They are not an offline authorization database. Current membership, tenant access, required owner permission and task revision remain action-time checks.

Human actions require delegated user context for the exact owner API audience. A workload credential plus a claimed user identifier cannot complete human-required work. Long-running service operations use their own workload credentials and durable decision references rather than retaining a person's bearer token.

Interaction sequence#

  1. Workflow creates a task using the published definition and approved human binding.
  2. A versioned task projection reaches Messages.
  3. Portal or an enabled application displays the user's eligible common inbox item.
  4. A registered action navigates to the owning interaction.
  5. The owner rechecks current identity, eligibility, resource permission and revision.
  6. The user claims or records the permitted typed decision.
  7. The authoritative receipt allows Workflow to settle the task and continue once.

Navigation is not mutation. GET requests and link previews must not claim, approve or complete work. Registered targets supply trusted destinations; business payloads cannot provide arbitrary execution endpoints or credentials.

Owner verification#

The documented application integration uses api/matrix/v1/interaction-eligibility to query current eligibility and api/matrix/v1/interaction-receipt-query to reconcile a committed action. The trusted owner API connection is configured separately from the public browser action origin.

Both the Workflow API and Worker must be able to reach and authenticate to the owner service. A working browser login or outbound registration does not prove that reverse connection. If the owner becomes unavailable, preserve the task and recover through the established receipt path rather than fabricating completion.

Decisions, expiry and notifications#

Concurrent claims or completions use revision checks so only one valid transition wins. A later permission revocation, reassignment or tenant change can invalidate an old task screen. The API enforces the current conditions independently of the controls displayed by that screen.

A deadline uses server-side expiry semantics. A delayed scheduler does not extend a human's authority. An explicitly published expiry continuation produces a system resolution and leaves the task Expired; it creates no human decision or approval.

Messages applies monotonic task-owner revisions and reconciles projection gaps. A terminal update must not be followed by an older actionable notification that resurrects the task. Read state remains separate for each eligible recipient.

For task data construction, see typed mappings. For immutable decision and uncertain-response handling, see durable operations.