Contractor access, specified.

01 / INTENT & BOUNDARIES

Approved access.
A defined end.

In this fictional scenario, contractor access is requested in an approved register and copied manually into identity and application systems. End dates can be missed, and nobody has a complete view of unfinished work.

The proposed workflow grants a limited, approved set of entitlements at the start of an engagement, removes workflow-owned access at expiry or withdrawal, and exposes exceptions to a named operator.

In scope

Individual contractor identities; an allowlisted set of applications and non-privileged roles; sponsored, time-bounded access; an operation and exception ledger.

Outside this design

Shared or privileged accounts, payroll, device shipping, unrestricted application administration, autonomous AI decisions and deletion of business data. Existing access owned by other processes is not automatically removed.

Before implementation

Validate the actual provider APIs, identity matching, entitlement ownership and session-revocation limits. Agree expiry-sweep cadence, maximum reconciliation delay, retry budget, alert thresholds and who responds. These are deployment gates, not unspecified guarantees.

02 / SOURCE & AUTHORITY

One request. A traceable decision.

The approved contractor register is authoritative for sponsor, engagement status, requested roles and access dates. Identity and application providers are authoritative for the state actually applied. Email addresses are attributes, never the sole identity key.

Required source fields

Immutable contractor ID and request ID; source revision; sponsor ID; application and role IDs; start and end timestamps in UTC; engagement status; and an approval reference. Store only the personal attributes required by the connected provider.

Events & scheduling

Create, revise, withdraw and expire events enqueue a reconciliation request. A periodic sweep also examines current records and due expirations so a missed webhook is not the only path to removal.

Validation gate

Reject missing or conflicting identity links, unknown roles, invalid date ranges, inactive sponsors and duplicate active requests with conflicting ownership. A match requiring judgement becomes an exception; the automation must not guess.

Policy authority

The client’s designated application owner defines the role allowlist. An authorised approver approves the exact request revision. The automation enforces these decisions; it cannot expand its own permissions.

03 / APPROVAL & EXPIRY

Approval has a scope.
So does access.

• The requester cannot approve their own access. The approver must be authorised for the target application and role; privileged roles are excluded.
• Approval binds contractor, targets, roles, dates and source revision in an immutable snapshot. A changed role, later end time or new target requires fresh approval before granting or extending access.
• Withdrawal or an earlier end time can reduce access without waiting for a new grant approval. Expired approval cannot reactivate an ended engagement.
• Immediately before a grant, recheck current authority, approval and time bounds. Serialise operations per contractor and target; a withdrawal supersedes queued grants. An in-flight grant is read back and removed if it completes after withdrawal.
• At expiry, remove only workflow-owned entitlements and invoke supported session-revocation controls. Keep the request in revocation until removal is verified for every target. Any remaining access is an unresolved exception, not a completed request.

04 / EXECUTION & RECONCILIATION

A retry must not become a second grant.

Durable intent

Persist the approved desired state and outgoing work in one transactional boundary. Workers claim a per-target operation from the durable queue. Delivery may be repeated; this design does not assume exactly-once messages.

Idempotency

Use a unique operation key from request ID, revision, target and action. Persist attempts, provider references and verified outcomes. Repeated events find the existing operation instead of issuing an unrelated write.

Uncertain provider outcomes

After a timeout, query the provider by its stable identity and assignment reference before retrying. Use native idempotency keys where available. If neither reliable lookup nor safe repeat writes is possible, stop that adapter for operator review.

Reconciliation

Compare current approved intent, the operation ledger and observed provider state. Stale events cannot overwrite newer revisions. Restore missing approved access only while authority, approval and dates remain valid; remove excess workflow-owned access. Flag other access for its owner.

Audit record

Record source revision, decision and approver reference, operation key, before/after entitlement state, provider result and timestamps. Keep credentials out of logs; restrict access and agree retention and deletion policies before deployment.

05 / FAILURES & ESCALATION

Every exception needs an owner.

Unavailable authority

Block new or expanded grants when the source or approval cannot be verified. Continue known expiry and withdrawal actions from durable records. Alert the designated operational owner; source recovery triggers reconciliation before grants resume.

Rate limit or temporary fault

Respect provider retry guidance and use bounded backoff within the agreed retry budget. Exhaustion creates a visible exception, never an endless silent retry. Access removal failures follow the agreed higher-priority escalation path.

Partial provisioning

Track each target separately. The sponsor sees the request as incomplete. Before deployment, the application owner chooses whether a partial grant can remain or requires removal of the grants made by this request. The automation does not invent that decision during a failure.

Who responds

The designated client operator owns the exception queue and manual intervention. The application owner approves entitlement decisions; the security owner handles unresolved exposure. Agree their contact routes, response expectations and escalation cover before enabling the workflow.

Alert contents

Include request and operation references, the affected target, remaining access, safe next action and runbook link. An acknowledged alert is not a resolved exception: closure needs a verified provider result or a documented, still-visible limitation.

06 / ACCEPTANCE CRITERIA

Specify the evidence before the build.

Proposed acceptance tests — not executed. These criteria illustrate how this design would be evaluated; they are not test results.

Run these cases with synthetic identities and controlled failure injection in a suitable test environment. Before rollout, the client’s authorised acceptance owner reviews recorded results, provider limitations and unresolved risks against the agreed criteria.

07 / RECOVERY LIMITS

Stopping safely is a designed path.

1. Pause grants. A documented control stops new provisioning without disabling known-expiry processing, the exception queue or audit capture.
2. Establish the actual state. Reconcile provider read-back with the ledger. Preserve operation evidence; do not replay ambiguous writes blindly.
3. Use an authorised recovery action. Remove only the entitlements created and owned by this workflow. Never automatically restore access revoked by expiry or withdrawal. Manual actions use client-controlled credentials and are recorded for reconciliation.
4. Validate before resuming. Correct the cause, review pending intent against current authority and confirm provider state. The designated change owner authorises resumption.

Removal cannot guarantee that existing sessions immediately terminate where a provider lacks the control. It cannot undo exported data, messages sent or other external side effects. This design does not delete business data or promise universal rollback. An unavailable revocation API creates an unresolved access exposure for the client’s security owner.

08 / HANDOVER & OWNERSHIP

The client can operate what is built.

• Client-owned assets: source and configuration repository, deployment instructions, dependency inventory, service accounts and secrets held in an approved store.
• Operational runbook: queue inspection, alert routing, reconciliation, expiry verification, pause/resume, manual removal and provider-outage procedures.
• Decision record: approved scope, field mapping, entitlement ownership, approver policy, cadence and retry settings, partial-failure policy and recovery limits.
• Acceptance pack: actual test evidence collected during implementation, owner sign-off, unresolved risks and any conditions preventing rollout. This fictional sample contains no such results or sign-off.
• Ownership transfer: a client operator walks through an exception and recovery scenario; responsibilities and access revocation are confirmed. Any retained engineering capacity is separately agreed.

A real specification would name the actual systems, decision makers and agreed operating thresholds. This specimen defines the design and the decisions needed before implementation without inventing a customer environment.