We have an issue where we are seeing a 400.1.404 Referenced object not found when submitting for an Access Profile via the API.
We receive back { "detailCode": "400.1.404 Referenced object not found", "trackingId": "[[trackingId", "messages": [ { "locale": "und", "localeOrigin": "REQUEST", "text": "Referenced ACCESS_PROFILE [[AccessProfileId]] was/were not found." }, { "locale": "en-US", "localeOrigin": "DEFAULT", "text": "Referenced ACCESS_PROFILE [[AccessProfileId]] was/were not found." } ], "causes": [] }
But when using the GET API to retrieve the same AccessProfileId, it is returned with a status code 200.
The error is happening when we use the API from either ServiceNow or direct in Postman. It is weird though, as the AP was requested back in mid-August without incident.
We have tried to Change the Name of the Access Profile, as well as make it non-requestable and back to requestable, and we have also changed the entitlements associated with the Access Profile all with no changes to making the Request Access API find the Access Profile.
We are trying to not have to create a new Access profile, as there are multiple that this is occurring on.
There seems to have been an issue that has affected entitlements and AP’s in different ways. If your issue popped up only yesterday, it could be related.
Good Morning @agutschow - We are currently using the latter, ServiceNow workflow to call the ISC API. But i can also call the API in Postman and receive back the same response.
Thanks @jesvin90 - I too saw this after my post, and was thinking the same thing, but the issue we have started (the furthest back submission) for this issue back on October 4th, so the likely hood of them being connected is slim. I did also run our Access Profile report, and found no missing Entitlements on any Access Profile.
Have you tried requesting the access profile through the UI? Does it produce the same error?
My next question may seem odd but it fixed an issue for me last week. Is the error occurring for all users (i.e. all access tokens)? Can you have someone else try or can you generate a new token and try the request?
Thanks @agutschow — We have not tried to request through the UI. That process is not something we have available to users and I try to avoid that.
As for the error occurring for all users, yes, the call from ServiceNow is a different access token than what I was using in Postman. But both have the same Org Admin permissions.
Hello @yannick_beot — yes, the Access Profile is Enabled as well as marked Requestable. (both eq true)
to see the Access Profile
It is visible in the UI under Access Model >>> Access Profile
It is found when making a call in beta (returns count=15); /access-profiles?count=true&sorters=name&filters=source.id eq “[[source.id]]”
it is found when making a call in beta; /access-profiles/[[accessProfileId]]
it is visible in the UI under Connections >>> Sources >>> [[Source]]] >>> Access Profiles
it is NOT visible in the UI under Request Center
It is NOT visible when making a call in beta (returns count=3); /requestable-objects?count=true&filters=name sw “[[accessProfileNamePrefix]]”&sorters=name
To request the Access Profile, we are using the following to make a call in beta; /access-requests with the following body { "requestedFor": ["[[identityId]]"],"requestedItems": [{"id": "[[accessProfileId]]","type": "ACCESS_PROFILE","comment": "Test for ACCESS_PROFILE"}],"requestType": "GRANT_ACCESS"}
this call results in a 400 Bad Request withthe reponce body of { "detailCode": "400.1.404 Referenced object not found", "trackingId": "b2...e3e", "messages": [ { "locale": "und", "localeOrigin": "REQUEST", "text": "Referenced ACCESS_PROFILE [[accessProfileId]] was/were not found." }, { "locale": "en-US", "localeOrigin": "DEFAULT", "text": "Referenced ACCESS_PROFILE [[accessProfileId]] was/were not found." } ], "causes": [] }
The Access Profile CAN be found in Search, yes.
Search in the UI shows it
Search via the v3 API shows it as well. But here, it shows it as enabled eq false with no entitlements. Although running the v3 Get access profile, it shows it as enabled with having entitlements.
Hi Michael - can you confirm how the variable [[AccessProfileId]] (and [[IdentityId]] for that matter) is getting populated in the POST body? It is possible that they are getting populated in URL parameters (based on your testing), but not within the body of the POST. The error message says that “[[AccessProfileId]] was/were not found”, ie the variable name not the variable value. Admittedly it could be that you edited the message and used that format to obfuscate the actual GUID and if so, I’ll get my coat.
Hi @j_place – yes, that was me “commenting them out”.
but for @everyone else —
some weird things i have found…
when in Search via UI - i see the Access Profile, but it shows zero (0) Entitlements. But when I click on the AP, it shows one (1) entitlement ((as it should)).
In Search API, when i look it up, it shows zero (0) entitlements, and enabled eq false.
in the v3 get Access Profile, it shows enabled with one (1) entitlement.
This is ocuring on about twelve (12) of our Access Profiles curently.
@masd1 It’s an expected behaviour for search. I too faced this issue it got resolved after several weeks. But when I was searching the documents related to this, I came to know the search should take 24 hrs to reflect the results if any change occurred in ISC.
Thanks @Santhakumar - the issue is still around, and the Search still has not been updated. I have an open ticket for about 10 days now, and no resolution. they have said they opened an internal support case on it, so i am waiting for more information. The unfortunate piece is this is in Predication and giving us lots of headaches. But we march on…
. Anyway if you have the info feel free to share here.