A data access approval workflow should capture a specific consumer and purpose, route the request to an accountable owner, record the approved scope and duration, and verify that the delivery system enforces that decision. Treat approval, provisioning, and verified access as separate states. An approved ticket is not proof that the right fields reach the right application.
Imagine a support application requesting five customer fields. The owner accepts three and declines two. The workflow must preserve that narrower decision, tell the consumer what changed, and prevent the original five-field request from becoming the runtime grant. This guide shows how to design that path, including incomplete requests, absent owners, expiry, and exceptions.
The workflow, identities, dates, field decisions, and response below are synthetic recommendations. They are not an Elementrix UI walkthrough, actual customer activity, or verified test results. Partial approval and automatic expiry must be checked in the implementation you use.
Capture purpose, consumer identity, requested fields, and duration
Replace “please give us customer data” with a request a reviewer can assess. Identify the human submitting the request and the application or user that will consume the data. Those identities may differ: a developer can submit on behalf of a service, but their personal login should not silently become the service’s authorization identity.
Ask for the task the data supports, the product and version, the requested operations, record boundaries, named fields, and the proposed access period. Include whether responses will be stored, exported, or shared downstream. An application needing account status does not automatically need contact information or national identifiers.
| Request section | Capture | Reviewer question |
|---|---|---|
| Consumer and sponsor | Registered application or user ID; environment; business sponsor; contact. | Can we identify the actual runtime consumer and its accountable team? |
| Purpose and product | Specific task; product ID and version; supported operation. | Does this use fit the product’s permitted purposes? |
| Data scope | Requested fields; region, tenant, or other record boundary; reason for each sensitive field. | What is the smallest useful scope? |
| Duration and handling | Start and expiry timestamps; renewal reason; downstream storage and recipients. | How will access end, and what happens to already delivered copies? |
| Decision and evidence | Request revision; reviewers; outcome; reason; approved scope; provisioning and test references. | Can we connect the decision to what was actually provisioned? |
Return incomplete requests for clarification before routing them. Keep the original submission and the clarified revision linked so that reviewers know which scope they are deciding on. A missing owner, unknown application, or unclassified sensitive field should produce an explicit unresolved state rather than a permissive default.
For the full lifecycle and terminology, use our data access management guide. For product definitions and consumer boundaries, the data product specification template provides a complementary worksheet.
Route requests to the right owner
Name one accountable product owner and an accepted substitute. Maintain the routing rule with the product, not in the requester’s memory. The owner decides whether the proposed use and scope are appropriate; an access operator implements the resulting grant. Add specialist review only when a stated rule requires it, such as a sensitive field, external recipient, or unusual retention request.
Choose sequential and parallel review deliberately
Use sequential stages when a later reviewer needs an earlier decision: a sponsor confirms the business purpose before a specialist reviews an exception. Independent reviews can run in parallel if each receives the same request revision and the final decision requires all mandatory approvals. Write down whether one reviewer can act for a group or whether every named reviewer must approve. Never infer that rule from who clicked first.
Route rejection and clarification separately. A rejection ends that request revision with a reason. Clarification asks the requester to resolve an open issue. Changing fields, purpose, consumer, or duration during review should invalidate affected approvals and start a new review revision; a reviewer should not approve one scope while another is provisioned.
Assign a queue owner, a reminder interval, and an escalation path for absence or stalled reviews. Escalation transfers responsibility to an authorized substitute; it does not convert silence into approval. An urgent request still needs a decision by someone entitled to make it.
Existing platforms illustrate why these handoffs need explicit states. Microsoft Purview’s access-policy documentation distinguishes an approved request from completed provisioning and describes an optional access-provider stage. This is a useful design distinction; it does not establish the same screens or behavior in another product.
Handle partial approval, expiry, and exceptions
Record the approved subset without erasing the original request
When only part of a request is acceptable, retain both the requested and approved sets. Explain each exclusion and ask the consumer to confirm that the smaller response still completes its task. Otherwise, the team may provision an unusable contract or work around the decision by requesting broader access elsewhere.
If your platform supports field-by-field decisions, record them directly and verify that provisioning uses only the accepted subset. If it supports only approve or reject for an entire request, reject or withdraw the broader request and submit a linked, narrower request. Do not approve five fields and rely on an email saying “only use three.” Reuse the original purpose and evidence where appropriate, but obtain approval for the final scope.
| Decision item | Example record | Operational consequence |
|---|---|---|
| Consumer and purpose | support-status-app; Customer Operations sponsor. Check current account service status; no marketing or identity verification. | Use the registered service identity, not the submitting developer’s personal credentials. |
| Product and scope | customer-service-status v1; read only; assigned REGION-A records. Requested five fields below. | Validate product version, operation, record boundary, and every requested field. |
| Owner decision | Customer Data Owner approves three fields and declines two with reasons. Consumer accepts the narrower contract. | Provision only the accepted subset; use a revised three-field request if the platform requires whole-request approval. |
| Time boundary | Illustrative access window: 2026-10-11T06:00:00Z to 2026-11-10T06:00:00Z. | These are proposed dates, not evidence of a real grant. Define and test enforcement of the expiry. |
| Completion record | Decision recorded; provisioning and acceptance-test evidence still required. | Business review is complete. Runtime access remains unverified until implementation checks pass. |
| Field | Decision | Reason |
|---|---|---|
| customer_id | Approved | Identify the service account record with an opaque enterprise key. |
| account_status | Approved | Answer whether service is active, suspended, or closed. |
| service_region | Approved | Confirm the application is using its assigned operational region. |
| contact_email | Declined | Contacting the customer is outside this status-check purpose. |
| national_id | Declined | Identity verification is outside the purpose; the service key is sufficient. |
Separate request expiry from access expiry
A review deadline controls how long a pending request stays open. A grant expiry controls when provisioned access stops. Record both explicitly; closing an old ticket does not remove a runtime permission. Require a fresh decision for renewal when purpose, fields, record scope, sponsor, or risk has changed.
Choose who enforces the end time and how failure is detected. If the delivery system cannot enforce an expiry directly, record the compensating removal process and its owner, and test that process before representing access as time bounded. A calendar reminder is a task, not an authorization control. Account for tokens, cached decisions, and other delivery paths when verifying removal.
Make exceptions bounded and reviewable
An exception record should identify the specific rule being varied, the reason, approving authority, allowed scope, compensating control, end time, and follow-up owner. Link it to the request revision and grant. Avoid an open-ended “approved by security” note that cannot be mapped to a consumer or field set.
For a recurring emergency, fix the ordinary routing or product design rather than renewing the same exception indefinitely. Revocation prevents future authorized retrieval through the controls you operate; it does not automatically erase files a consumer already downloaded. Agree downstream handling separately and retain the evidence relevant to it.
Connect the approved grant to delivery
Use the decision as input to provisioning, with a stable reference linking request, approved scope, and runtime grant. A handoff should contain the consumer ID, product/version, allowed operations, field set, record boundary, start/end conditions, and decision revision. Provisioning must not reconstruct scope from the original ticket title or an attachment that changed after review.
An illustrative response for the accepted three-field contract might look like this:
{
"customer_id": "CUST-042",
"account_status": "active",
"service_region": "REGION-A"
}This JSON is an explanatory example, not output from a live test. Authentication identifies the caller; authorization determines whether that caller can perform the operation and receive the requested data. Implement the decision at the delivery boundary, including routes that read prepared or cached data. Hiding fields in a request form alone is insufficient.
The OWASP Authorization Cheat Sheet recommends least privilege, denial by default, permission checks on every request, and authorization testing. Apply those principles to the final scope rather than treating approval as a permanent bypass. Our guide to zero trust data access governance discusses the wider policy-to-delivery connection.
| Case | Expected behavior for this design | Evidence to record |
|---|---|---|
| Approved consumer | The registered application receives only the three approved fields for its permitted region. | Consumer identity, grant revision, timestamp, response field set, and test result. |
| Excluded fields | Requests for contact_email or national_id are denied or omitted according to the documented contract; values are never exposed. | Attempted field, actual response or error, and enforcement-path reference. |
| Wrong identity or record scope | An unapproved application or out-of-region request does not receive restricted data. | Negative-case result without unnecessary sensitive payloads in logs. |
| Changed or expired grant | The previous scope cannot continue through stale credentials, cached authorization, or an alternate route. | Expiry/removal action and observed denial across relevant delivery paths. |
| Incomplete provisioning | A failed handoff remains in an actionable failed or pending state; the requester is not told access is complete. | Failure reason, responsible operator, retry or repair action, and subsequent result. |
These are proposed acceptance criteria. Add actual outcomes after running the checks; a planning checklist is not a passed test. Preserve useful evidence while minimizing sensitive values in logs. If any route still returns declined fields, keep the request out of the completed state and correct the implementation.
Measure wait time and review recurring exceptions
Track timestamps for submitted, clarification requested, resubmitted, review started, decision recorded, provisioning started, and access verified. Use one clock basis, such as UTC, and preserve state changes so that reopening a request does not erase its history. Measure business-review delay separately from technical-provisioning delay.
- Decision wait: submission to the final decision. Report clarification time separately so it remains visible.
- Provisioning wait: approval to completed delivery checks. Approval speed alone can hide a long access backlog.
- Queue age: how long each unresolved request has remained in its current state, grouped by owner and reason.
- Exception recurrence: repeat exceptions by product, field, rule, or consumer purpose. Use this to find unclear policies or missing product contracts.
- Control failures: grants that do not match approvals, access surviving an expiry, or completion marked before verification. Assign an owner to each failure.
A synthetic timing example makes the distinction clear: a request submitted at 09:00, decided at 11:00, and verified at 14:30 has a two-hour decision wait and a three-and-a-half-hour provisioning wait. Its end-to-end elapsed time is five-and-a-half hours. These are illustrative numbers, not Elementrix performance results. Use business-hour measures only when the service calendar and calculation are explicitly defined.
Start with a baseline from real requests before setting targets. Review medians alongside tail delays, unresolved queues, and failed checks; a fast average can conceal stranded requests. Shorten avoidable routing and clarification loops without rewarding reviewers for approving inappropriate scope.
Start with one approval bottleneck
Pilot the workflow with one product, one accountable owner, and one consumer. Complete the request form, agree the final field set, identify every required handoff, and verify the delivery and expiry cases. Keep request revision, decision, grant, and evidence connected as the workflow expands.
Bring one approval bottleneck to an Elementrix workflow demo. Share the product, consumer identity, requested fields, and time boundary. Ask which decisions the current implementation supports directly, how narrower requests are handled, and what evidence confirms that delivery matches the grant.