If an access profile like this is created and access is requested, it results in the GET /v3/access-request-status endpoint returning a 500 response ‘downstream resource was unavailable’ if you filter the results to the identity the access was requested for.
Same thing will occur in the UI, meaning an identity will be unable to look at their past requests.
Is there a reason I’m missing why it needs to be nullable? I’d reason that if approverType is ‘Governance Group’, approverId needs to be included.
I think that the approverId is only applicable when you specify an approverType of GOVERNANCE_GROUP. The other three approver typers are MANAGER, OWNER, and SOURCE_OWNER, and you would not put an approverId for those types since they are derived from the access profile settings. It’s not the greatest API design to have four types of approvers and only one requires an approver ID, but that is the intention in this case.
So if you are using a governance group approver, set the approver ID. Otherwise, you can leave it null.
I was trying to highlight that this allows you to break ISC since some other endpoints will be returning 500 with seemingly no workaround, because of this null object