To run data access requests in ServiceNow using a data catalog, let people find the asset and click request in the catalog, and let ServiceNow carry the request through fulfillment. The catalog submits a requested item against a dedicated Service Catalog item, and approval runs either in your ServiceNow flow or in the catalog’s own workflow before the request is submitted. Fulfillment tasks then grant the access, and the final request state syncs back so the requester sees the outcome on the asset.
What happens when a data access request moves from a data catalog into ServiceNow?
A data access request crosses two systems, and each one owns a different half of the job. The data catalog knows the asset: its owner, its sensitivity, its lineage, and who is asking. ServiceNow runs the process: the request record, the team that grants the permission, the fulfillment state and, when you choose, the approvals.
Inside ServiceNow, every request rides on the same record chain. ServiceNow’s Request Management architecture starts the process only when someone orders an item from the Catalog Item table (sc_cat_item). Checkout writes a Request (sc_request) and a Requested Item (sc_req_item, often called the RITM). Catalog Tasks (sc_task) sit below the Requested Item and hold the fulfillment work. The same page states that variables, the answers to the form questions, are associated only with the Requested Item table. That detail matters: the asset name, the access level and the business reason all live on the RITM, so your flow reads them from there.
| Step | Where it happens | ServiceNow record |
|---|---|---|
| Find the asset and click request | Data catalog | None yet |
| Submit the request | Catalog calls ServiceNow | sc_request and sc_req_item |
| Approve or reject | ServiceNow flow, or the catalog’s own workflow | Approval records on the RITM when the flow approves |
| Grant the permission | Fulfiller or automation | sc_task, then the source system |
| Show the outcome | Catalog reads the final state | Request state, for example Closed Complete |
An external catalog can submit the order through the Service Catalog REST API. Its order_now endpoint orders a specific catalog item and returns the new request number and ID, which the catalog stores so it can match later status changes to the right asset and requester.
Which ServiceNow pieces do you configure for data access requests?
Four ServiceNow building blocks carry the request from submission to granted access.
A dedicated catalog item. Create one catalog item for data access, with variables for the asset, the access level, the duration and the reason. A Requested For variable records who the access is for; if it has no default, the logged-in user submitting the request becomes the Requested For value. A catalog item can hold only one Requested For variable.
A flow with a Service Catalog trigger. In Workflow Studio, a Service Catalog trigger fires on every request for the catalog item that points to that flow, and the requested item becomes the flow’s trigger record. You attach the flow through the catalog item’s Flow field. Catalog variables cannot be used in the trigger condition, so read them in the body of the flow.
An approval step. The Ask for Approval action supports rules such as anyone approves, all users approve, or a percentage of users approve. Approvers can be users, groups or a field on the record, such as the data owner. A due date stops the flow from waiting forever, and the action returns states including Approved, Rejected and Skipped. If the catalog already approved the request in its own workflow, the flow can go straight to fulfillment instead.
Fulfillment. After approval, the flow either creates a catalog task for the team that grants permissions or calls the source system directly. Integration Hub provides the reusable integrations with third-party systems for the automated route, and it needs a separate ServiceNow subscription.
How does ServiceNow’s own Data Catalog handle access requests?
If your team uses the Data Catalog inside ServiceNow Workflow Data Fabric, access requests follow this path. Per the request access procedure for the Brazil release, a user with the WDF Consumer role (wdf_consumer) opens Workflow Data Fabric Home, selects the Data catalog icon, finds a data product or data interface, and clicks Request access. The data steward is notified, and the requester gets an email when the status changes.
On the approval side, the review and approve procedure works like this:
- Approvers belong to the Data Catalog approvers group and hold the approval_user and dcg_catalog_readable roles.
- Any one member of that group can act, and one approval is enough.
- Pending requests appear under Self-Service, then My Approvals, with a short description naming the user and the asset.
- On approval, the requester is automatically granted the role needed to query the asset and the task closes. On rejection, the requester is notified and the task closes.
Both procedures state that access requests cover data products and data interfaces. The Data Catalog overview describes consumption after approval through Data Fabric tables, APIs, dashboards or AI agents.
How do you keep approvals, request states and audit evidence in sync?
The integration fails quietly when the two systems disagree about what “done” means. Settle these points before the first request goes live.
Pick the closing state. Decide which request state means access was actually granted. For example, Closed Complete. An approved RITM only means someone said yes; the catalog should report success only when fulfillment has finished.
Keep approval and provisioning separate. Approval answers “should this person have it?” Provisioning answers “did the grant happen?” Model them as separate steps, whichever system runs the approval, so a rejected request never creates a fulfillment task and an approved one never closes without one.
Grant the smallest access that does the job. The NIST glossary defines least privilege as a principle that a system should restrict the access privileges of users, and of processes acting for them, to what their assigned work requires. In practice, ask for the access level and a duration in the catalog item variables, and route anything above read access to a second approver.
Keep the evidence. Auditors usually sample access request tickets and look for the approver’s identity and the timestamp. The RITM, its approval records and the catalog’s activity log together give you that trail. For templates that map each control to its evidence, see how to document data access controls for audits.
Measure the queue. Track the time from request to grant per asset domain. Slow domains usually point to a missing owner or an approver group that is too large, and both can be fixed in catalog metadata. The wider trade-offs are covered in how to balance self-service and data governance.
How does Atlan run data access requests through ServiceNow?
Atlan connects to this pattern through governance workflows. An Atlan admin turns on the Governance Workflows and Inbox module under Labs, then builds an access management workflow. Approval happens in that Atlan workflow: the workflow builder sets approvers as anyone approves, all in parallel, or all in sequence, with optional auto-approval rules and forms that collect context from requesters.
ServiceNow then holds the ticket and its fulfillment. Per the Automate data governance docs, the access management template can raise a ServiceNow request to grant or revoke access on the source: Atlan creates a request in the Atlan Data Access catalog for your team in ServiceNow and shows its status in Atlan. The release note for the integration states that tickets are created in ServiceNow once requests have been approved.
Setup, as documented in Integrate ServiceNow, takes an Atlan admin and a ServiceNow System Administrator with the security_admin role:
- Create an OAuth application in ServiceNow and connect it from Atlan’s Integrations settings.
- Import and commit the Atlan update set. It adds the Atlan Data Access catalog, a business rule that sends status changes back to Atlan, a service role with write access on sc_request, and a scripted REST API.
- Create an atlan.service user with the atlan_service_account_role.
- Click Connect and test. Atlan creates a sample request in ServiceNow and waits for the webhook event before it shows CONNECTED.
Requesters other than the user who set up the integration may first need to link their own ServiceNow account from their profile. In the workflow, you select the ServiceNow request state that completes the request. The troubleshooting page explains that the included auto-approve workflow approves the RITM, which does not complete it: Atlan waits for the selected final state, such as Closed Complete, before marking the request complete. You can remove that workflow and set the catalog’s Process Engine to follow your existing process.
General Motors named API infrastructure as the first of three reasons it chose Atlan. Sherri Adame, Data Governance Lead at General Motors: “The reason that we chose Atlan was because of the API infrastructure. We can do things in an automated way so we can get anything out, and anything in that we need to, and it embeds directly in our engineering processes.”
FAQs about data access requests in ServiceNow
Do I need a separate ServiceNow catalog item for data access requests?
Yes, in most setups. A dedicated catalog item gives the request its own variables, its own flow and its own reporting. It also keeps data access separate from hardware or software requests, so approvers see the asset, the access level and the reason on one form, and auditors can pull every data access request with a single filter.
Which ServiceNow record holds the details of a data access request?
The Requested Item, stored in the sc_req_item table and often called the RITM. ServiceNow associates catalog variables only with that table, so the asset name, access level, duration and business reason all live there. The parent Request groups the order, and Catalog Tasks hold the fulfillment work assigned to the team that grants permissions in the source system.
Can approvals happen in the catalog instead of ServiceNow?
They can, but pick one system as the approval owner for each request type. If the catalog approves and then creates a ServiceNow request only for fulfillment, ServiceNow approvals should be skipped or automatic. If ServiceNow owns approval, the catalog should wait for the final request state before it reports the request as done.
How do I revoke access that was granted through ServiceNow?
Treat revocation as its own request type with its own catalog item or workflow branch. The flow should create a fulfillment task to remove the grant in the source system and close only when removal is confirmed. Keeping grant and revoke records side by side gives auditors a full history of who held access and for how long.
How long should a data access request take?
Set a target per sensitivity tier rather than one target for everything. Low-risk data can follow an auto-approval rule, while restricted data may need a second approver and a longer window. Use due dates on approval steps so requests never wait without an owner, and review the slowest asset domains on a regular schedule.
Sources
- Request Management Architecture, ServiceNow Docs
- Service Catalog API, ServiceNow Docs
- Requested For Variable, ServiceNow Docs
- Create a Flow with a Service Catalog Trigger, ServiceNow Docs
- Ask for Approval Action, ServiceNow Docs
- Integration Hub, ServiceNow Docs
- Request Access to Data Assets, ServiceNow Docs
- Review and Approve Data Access Requests, ServiceNow Docs
- Explore Data Catalog, ServiceNow Docs
- Least Privilege, NIST Computer Security Resource Center Glossary
