Assign work and access to a position

Assign a ticket or task to IT manager, then change the position's acting owner when someone covers the job. The saved assignment stays on IT manager. The replacement receives the position's app roles and shared-resource grants while they act in it.

Configure the position

1. Open Settings → Positions and choose the existing position.
2. Add its required app access in Permissions. Share its private project, ticket queue or CRM pipeline with the position using the resource's sharing dialog.
3. Choose one active human workspace member as acting owner. Helpers and agents receive no inherited grants. One person can act in several positions.
4. In an assignment picker, choose the position under Positions. Its acting owner is a display label. Unavailable choices explain that they need an owner or are not eligible for this assignment.

The position must carry the whole permission bundle itself. The replacement's personal grants or another position's grants do not make an incomplete bundle ready. An explicit app disable still applies. Changing the acting owner carries existing unfinished work and grants without rewriting each item or granting the replacement permanent personal access.

Cards, checklist items, tickets, CRM task activities and Control Calendar runs support position responsibility. CRM meetings and other activities retain their existing person ownership. SOP birth holder, report submitter, actual performer and named approver remain separate facts. Completed work shows its recorded owner at completion; reopening uses the current acting owner.

Staffing receipts

Review the current owner and staffing version before confirming a handover. A stale confirmation returns POSITION_STAFFING_CONFLICT; refresh and review the new state before starting another request.

When confirmation is unknown, retry the exact request ID and payload or recover its receipt. Do not create another UUID or change the replacement automatically. A receipt with delivery pending means the staffing change committed and notifications are still being delivered. A request-ID payload conflict returns POSITION_REQUEST_CONFLICT.

Assignment targets

Web actions use assigneeTarget. MCP tools use assignee_target:

{"kind":"position","id":"<discovered position UUID>"}

Use {"kind":"person","id":"<person UUID>"} for a named person. Omit the field on an edit to preserve the saved target; send null to clear it. Combining a typed target with a legacy person alias is refused, including a null alias. Acting-owner summaries and completion fields are read-only.

Call stackr_search_assignees, tickets_search_assignees or crm_search_members with target_kind: "position" or "all" after selecting an accessible source. Omission preserves the original person-only response. Position choices require operator enablement for new authoring; existing responsibility, permissions, repair and recovery continue when authoring is disabled.

Original due work

A blocked scheduled run remains owed at its original due time. Editing, pausing or deleting a schedule does not discard it. Open Original due work from the position or saved schedule, repair its source and destination permissions, or explicitly skip/cancel it with a reason. Only a currently authorized source manager can see and resolve that source's dues.

Use the same request ID and payload to recover an uncertain disposition. stackr_list_owed_runs and control_calendar_list_owed_runs return source-scoped original dues. When next contains continuation, pass that opaque string as the next call's continuation; scanPending means the bounded scan has more work, even when the current page has no rows. Legacy paired after_due_at and after_id pagination remains supported; do not combine those fields with a continuation. Their corresponding *_dispose_owed_run tools require source, occurrence, request ID, disposition and reason. Owed runs are not already-created tasks.

An authorized manager can Cancel run… when a position SOP run awaits approval. The report and its named submitter/approver history remain retained, read-only and unapproved. The result reads Cancelled · not approved and identifies who cancelled it. A lost confirmation is recovered using the same cancellation request, even after closing and reopening the dialog.

Local executable walkthrough

Use an isolated development database and the normal local email sign-in provider. Enable the app tier gates and POSITION_WORK_AUTHORING_ENABLED=true on that local server. From a repository checkout:

NODE_ENV=development pnpm db:seed:position-continuity
POSITION_WORK_AUTHORING_ENABLED=true pnpm --filter @metadot/platform dev

Sign in through local email as morgan@position-demo.test. Bob initially acts as IT manager; Alice starts with no independent private grants. The seed includes the private IT support queue and five kinds of position work. It is idempotent and does not reset a handover already completed in this database.

Create a Standard local PAT with Tickets scope in Account → API Keys and set METADOT_MCP_TOKEN in the process environment. Run the checked-in example:

METADOT_MCP_URL=http://localhost:3000/api/mcp/position-continuity pnpm --filter @metadot/mcp-server exec tsx examples/position-ticket-quickstart.ts

The example checks the bound demo workspace, discovers the queue and position IDs, creates one ticket with the position target, reads it back and asserts the saved target. It accepts only a loopback development endpoint and never substitutes Bob or Alice's user ID. The matching registered-SDK fixture lives in packages/mcp-server/src/tools/tickets.test.ts:

pnpm --filter @metadot/mcp-server test src/tools/tickets.test.ts

Then change the acting owner to Alice in the position page. Sign in normally as Alice, open and perform the assigned work, and verify Bob's position-derived access is gone. Confirm completed history and named approvals remain truthful. This exercise verifies the product flow; a fixture does not establish a real covering person's adoption result.

Declare the clock before beginning: start when the covering person first opens the workspace; stop when they can read and perform their first assigned private item. Record the app, source, prerequisites and interruptions.

Checkpoint	Start/end or elapsed	Result or blocker
Find the position and its acting owner	Record locally
Find and read assigned private work	Record locally
Perform the work under inherited grants	Record locally
Confirm old-holder denial and retained history	Record locally

The first-use target is 2–5 minutes after prerequisites; actual human timing remains to be measured.

Troubleshooting

Native failures include a safe code, message, remediation, retryability, correlation ID and documentation URL. Keep the correlation ID for the authorized manager; private source details and database errors are not included in the response.

Code	Next action
INVALID_ASSIGNMENT_TARGET, CONFLICTING_ASSIGNMENT_TARGET, READ_ONLY_ASSIGNMENT_FIELD	Supply one writable target using the assignment-target contract.
POSITION_TARGET_UNAVAILABLE	Choose an eligible target or ask its authorized manager to repair the position bundle.
POSITION_STAFFING_CONFLICT	Refresh the current owner/version and review a new confirmation.
POSITION_REQUEST_CONFLICT	Recover the original request using its identical payload.
POSITION_WRITE_FAILED	The required native write failed; refresh and retry the authorized operation. Preserve the existing request if its outcome is unknown.
RESTORE_NATIVE_RESPONSIBILITY_BLOCKED	Use the source-manager recovery process described below.

Generic backups

Generic backup restore refuses incoming native responsibility and refuses older backups over a workspace with live native state or retained debt before deleting data. An authorized source manager must repair or explicitly resolve the original dues. Native restore/import is not supplied by the generic backup path. Legacy-only restores use one fenced transaction, including event identity relinking.

Automatic dated vacation coverage and return are not included. A manager performs each deliberate handover.