Set up approval flows so users can request access to reports and datasets — directly from the catalog, with the right people in the loop.
When this feature is turned on for an asset type, a Request Access button appears on every asset of that type:
Users who don't yet have access (or who simply want to formalize their request) can click it, enter a reason, and submit. The request then moves through a configurable sequence of approval steps until it's approved or rejected.
A typical setup combines a business approval step with an automated handoff to IT:
Users initiate their access request from the catalog — no need to switch to a ticketing tool and re-enter context about which asset they need.
The business stakeholder (often the asset owner) reviews and approves first.
An automated final step creates a ticket in your ticketing system (Jira, Xurrent, ServiceNow, …) with all the relevant context, so the IT team can grant the actual permission.
You can also foresee a writeback so the approval is set to completed once the ticket is completed in your ticketing system.
Enabling Request Access on an asset type
Approval flows are configured per asset type. Turn it on for Dataset, for example, and every dataset in your catalog gets the Request Access button.
To enable it:
Go to the admin portal > Asset Types.
Select the asset type you want to enable it for.
Open the Settings tab.
Toggle Request Access on.
Building the approval flow
Once Request Access is enabled, you can define the steps a request must pass through before it's granted. Steps run consecutively: step 1 must complete before step 2 starts, and so on.
Three step types are available:
1. Owner approval
The request is routed to the asset's assigned owners. Any one of them (or any member of an owning team) can approve to move the request to the next step. See Ownership & suggestions for how owners are assigned.
2. Collaborator approval
The request is routed to a specific user or team you pick when configuring the step — independent of who owns the asset. Useful when a central team (for example, Data Governance or Security) needs to weigh in regardless of which dataset is being requested.
3. Code (automated)
When this step is reached, a script you write is executed automatically. This is the integration hook for things like creating a ticket in your ticketing system, calling an identity provider's API, or notifying an external workflow. The step completes once the script finishes.
Common pattern: Step 1 = Owner approval (business sign-off), Step 2 = Code (automatically create an IT ticket with the requester, the asset, the reason, and the requested dates). The owner approves once; the technical handoff happens automatically.
Don't forget to click Save flow after configuring or changing steps.
Requesting access (as a user)
When a user opens an asset of a type that has Request Access enabled, a Request Access button appears in the asset's header. Clicking the button opens a dialog where the user provides:
A reason (required) — why they need access.
A start date(optional) — when they need the data by.
An end date (optional) — how long they'll need it for.
After clicking Send, the request enters the approval flow at step 1.
Tracking requests on the homepage
The dScribe homepage shows everyone's access-request activity in one place — both requests you've sent and requests you need to act on.
My requests
Under Access Requests > My requests, users see every request they've submitted, with its current status and which step it's on (for example, "Step 1/2"). Status badges include In progress, Completed, and Rejected.
To approve
If you're an approver on one or more requests (because you're an owner, or you've been picked as a collaborator approver), the To approve tab lists the requests waiting on you, with a count next to the tab.
Approving or rejecting a request
Each access request shows the requester, when the request was submitted, the reason, optionally the requested start and end dates, and the full sequence of approval steps with their current state:
You can:
Approve step — advances the request to the next step (or completes it, if this is the last step).
Reject — ends the request immediately with a Rejected status. Requesters can re-submit starting from this step if relevant.
Add a message (optional) — share context with the requester, visible alongside your approval or rejection.
Note: Approving a step doesn't itself grant the user permission to read the underlying asset. The approval flow's job is to capture the right sign-offs and (via the Code step) trigger the system that actually provisions access — typically your ticketing tool or identity provider. dScribe orchestrates the workflow; the permission grant happens in whichever system owns the data.
Where to go next
→ Asset types — configure your asset types
Have a question or can't find what you're looking for? Use the chat icon inside the catalog to reach the dScribe support team.