Share all details about your problem, including any error messages you may have received.
Dear Community,
I am managing third party users’ access to my org Azure (Entra). i have developed a workflow called External joiner which is referring Identity request initialize in the backend to generate the access request for joiner event and create an account in AD but i want to differentiate the Access requests created for this application and this event for example a string to be appended in the access request Id - Azxxxxxx.
I have made some changes in the Identity request initialize wf and setting/updating the request ID but it is not updating the decisions status and status for the access request shows Waiting instead of provisioning or complete.
It sounds like the issue is related to modifying the Request ID within the Identity Request Initialize workflow.
The Request ID is a system-managed identifier that is used internally to correlate the Identity Request, approval decisions, provisioning activities, and status updates. Modifying this value can break those relationships, which may explain why the access request remains in a “Waiting” state and the decision/provisioning status is no longer updating correctly.
Instead of changing the Request ID, consider using a custom attribute, metadata field, or request comment/tag to identify requests generated by your External Joiner workflow. You could populate a custom value such as “AZ” or “ExternalJoiner” and use that for reporting, filtering, or downstream processing while leaving the system-generated Request ID unchanged.
Could you share:
The exact changes you made in the Identity Request Initialize workflow?
Whether you are updating the id field of the Identity Request object or another attribute?
Any workflow execution errors or provisioning errors shown in the logs?
That would help determine whether the request correlation has been broken by the customization.
@Sammy271200 Would not recommend changing the request id logic, as it is being auto generated and is dependent on the internal logic for increment. Instead, you can try introducing a new request type like ExtJoinerRequest which will help you differentiate regular request against external joiner requests. You need to add the entry in the key=“accessRequestTypes” in SystemConfiguration.
If I understand your requirement correctly, you want to create separate access requests for AD and Entra provisioning for external users.
Since access requests are generated per provisioning plan, you can create two distinct provisioning plans in your workflow - one for AD and another for Entra. First, pass the AD provisioning plan to the LCM Provisioning workflow. After it completes successfully, pass the Entra provisioning plan to the same workflow. This approach ensures that each plan is executed independently, resulting in two separate access requests.