Task discovery and task execution have different owners#
Workflow owns the human task lifecycle: task state, assignment, claim and progression. Messages owns the task's inbox projection and recipient/read state. The destination application owns the form, business authorization, transaction and authoritative result. This separation lets several applications show the same work without giving the inbox authority to execute it.
Messages never proxies claim, release, reassignment, a decision or a domain mutation. Opening an item is not a claim. Marking it read is not task completion. Workflow advances only through its authorized execution and outcome-reconciliation contracts.
Project tasks through a versioned contract#
Task projections are authenticated workload publications. Enrollment binds the projector to its principal, tenant, owner, source, audience selectors, policies and registered destination. Human tokens are not accepted as projector credentials.
The base contract accepts full snapshots and records monotonically advancing task revisions. A replay of the same revision must preserve its semantics. An older revision cannot replace the head. A terminal snapshot received before an earlier active snapshot leaves a tombstone, so out-of-order delivery cannot reopen settled work. Full snapshots permit catch-up without requiring every intermediate revision.
The registered-interaction extension uses POST /api/messages/v1.1/task-projections. Its interaction contains an ID, version and typed input, with optional direct/group audiences. The documented input bound is 2,048 canonical UTF-8 bytes. Use it for a bounded subject lookup and expected revision, not unrestricted business records or executable instructions.
| State owner | Data it authoritatively controls |
|---|---|
| Workflow | Task revision, status, assignment and claimant |
| Messages | Current projection, inbox visibility and recipient state |
| Destination application | Subject state, operation permission and committed business result |
| Identity/directory service | Current person, group and tenant observations |
Establish current eligibility#
Before exposing an actionable task, Messages intersects the original audience grant with current directory eligibility, Workflow task evidence and the destination owner's operation permission. For a claimed task, only the claimant remains actionable. Recipient history and previous read/dismiss state can be retained without leaving a stale task executable.
The destination eligibility query is a read-only, bearer-authenticated workload call. The workload identity permits that query; it does not authorize a business mutation as the human. The owner must establish the queried person's current tenant and subject-specific operation permission from trusted identity and application state.
Positive owner evidence has finite validity. The documented registered-task contract limits it to no more than 30 seconds ahead and rechecks the projection head after remote eligibility calls. A changed head, stale response, unavailable directory or owner failure withholds the row. These cross-service observations are bounded checks, not an atomic snapshot of every service.
Enroll a destination once#
- Register the application's trusted Web origin, API owner and scoped read-only query workload for the environment.
- Enroll its
registered-interactionlaunch target and the matching task/owner policies in Messages API and Worker. - Allowlist the exact interaction launcher in the canonical browser front door and register presentation identity separately from publisher identity.
- Register each operation's immutable interaction ID, version and input schema through its owning integration contract.
- Verify the application independently reauthorizes claim-related work and Save/Submit, including expected subject revision.
New operations reuse that enrolled launcher; they do not require operation-specific inbox routes. Informational publications cannot use the reserved registered-task destination to bypass task eligibility.
Diagnose the owning boundary#
For missing work, compare the latest projection with Workflow's current eligibility response, then check tenant/application enrollment and destination permission. For a visible item that cannot open, inspect registered browser and presentation targets. For a failed submission or missing completion, inspect the destination's authorization and durable receipt, then Workflow reconciliation.
Test revocation before delivery and after opening, competing claims, stale subject revisions, duplicate submission and a lost response after commit. Preserve the original owner receipt during recovery. Replaying an informational message cannot settle the task. Bounded local reference limits and package verification do not establish production user scale; qualify the intended workload separately.