OOTB IIQ custom API calls are limited in terms of Authorization for running workflows. You can execute either all or none. Therefore the client has custom plugin for API calls where we can specify capability and workflow with an API path.
I was reviewing, fixing and extending the functionality for creating new Access Requests. The main objective was to avoid duplicated requests for Roles and Entitlements. E.g. access is already in progress or it is assigned. There were multiple challenges on the way.
Challenges
Multiple accounts for the same Application
Identities can have multiple account on one application and that can be ambiguous if you request an access for an identity only. Therefore I suggested to use the normal account if not specified. There is an option to input privileged account in the APIs.
Input for Entitlement is a displayName attribute
It is easier and simpler to use display name by application that call IIQ API, but more complicated on IIQ API backened. It is mainly due to different values for entitlements in different connectors e.g. Azure id, DN or simple name.
Additionally in the access request the item is a displayName too, not an identifier.
SAAS applications edge case
For cloud applications, like Okta or WebServices connector, we receive identifier after the account is created, therefore we cannot predict or check in Access Request whether user already exists based on Link id.
Logiplex setup
I also had to handle the logiplex application as the account most likely does not exist on sub-application and has to be found in the main logiplex application instead.
Summary
I have extended my knowledge with object model of Access Request, relations between Links and Identities and connectors in general.
It was possible to add few more error checks and make the requests more transparent with what account it is creating a request for.