/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?

1 Like
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.