/access-request-status endpoint - why is ORG_ADMIN required to view access requests for others?

Identity Security Cloud (ISC) ISC Discussion and Questions
1

Use Case
We need the ability to join data from ServiceNow to the /account-activities data so in Power BI we can include information about the request from the IDN side and include the link to the ServiceNow request.

image
image1325×259 29.9 KB

The ServiceNow workflow in the Service Catalog Integration has a step where it writes the accountActivityItemId to the ServiceNow record, so the join sequence is

  1. ServiceNow (sn) to /access-request-status (ars) using sn.accountActivityItemId = ars.accountActivityItemId

  2. /access-request-status (ars) to /account-activities (aa) using ars.accessRequestId = aa.id

We use the completed date on the account activity record to show the “Provision Date” on the report.

Here’s the issue
Access to the access-request-status endpoint requires a token with ORG_ADMIN access. Curiously, access to the /account-activities endpoint does not. They have virtually the same data, so why does one require such elevated permissions?

Workaround
If you utilize the clientMetadata object in the /access-requests payload, then you can put all the identifying information that you need there and link directly to the /account-activities record. We have done that, but it took us months to discover it was needed, so there are a bunch of records without clientMetadata on them, which is why the intermediate join using the /access-request-status data is required.

2

@colin_mckibben since you’ve taken the time to edit my API documentation link, do you have any insight you can provide on my question?

3

Hi Mark,

With the release of the new developer portal I had to update broken links in a lot of posts. I did forward your question to the product team, but with the Navigate conference happening this week it might take some time to get a response.