Patch access profile "requestable" field

Hi all,

I’m having trouble using the endpoint listed here: patch-access-profile | SailPoint Developer Community

I’m attempting to patch the “requestable” field to value false in order to remove a specific access profile from the list of access a user can request. The access profile is only used in a role and provisioned automatically. I can’t remove it from the application itself because our custom connector for the source creates access profiles automatically for each entitlement with a 1to1 relationship.

Here’s the payload:

[
    {
        "op": "replace",
        "path": "/requestable",
        "value": false
    }
]

Here’s the first 5 lines of the response(status: 200 OK):

{
    "description": "Roles used by all -redacted- employees",
    "enabled": false,
    "requestable": false,
    "owner":

However, once I perform a GET api call for the same access profile, the response shows "requestable": true

Going through the GUI search, I can see the UPDATE event for the access profile from my user creds but the details show that nothing was actually updated.

Am I doing something wrong here or is this a bug? Looks like the PATCH call just returns the response but isn’t actually applied.

Hi @M_rtenH,

I spoke with our product team, and they informed me that access profiles are always requestable, and therefore can’t be PATCHed via the API. The API should not have returned a 200 in this case, and the spec should clearly state that requestable can’t be modified. We are working to resolve this on our end.

I apologize for the confusion.

@colin_mckibben - is this changing with the release of the new Request Center?
The initial documentation that I received stated to use the beta Access Profile API to make it requestable (true/false). and i am running into the same issues as above. Change it to FALSE, yet it returns a 200, and go verify, and it is still TRUE.

@colin_mckibben the API doco page still lists requestable as a patchable field:


Can we please have this corrected as it is likely to catch people out as it has been above.

So weirdly enough I’ve now come across access profiles where requestable=false. I’ve spoken to my colleagues who’ve set these sources/access profiles up (via UI) and they’ve no idea how they ended up in this state
image

Ok, figured out why the above was happening. They’d set up the approver as the same person as the access profile AND source owner so due to IDN not having any fallback options the access profiles couldn’t be requested.

So you’re saying there’s a way to make these non request-able :smiley:

1 Like

Hah! I guess that’s one way to look at it. Sadly it still stays visible for the end-user.