I couldn't find a single place that had the state definitions outlined. If it does exist, let me know and I can reference it. The following access request state descriptions are compiled from conversations and my own research. If anyone has anything to add, please do.
Completion status
Note: Located in the upper left section of the Request
• Failure – All of the requested items have failed to complete
• Incomplete – One or more of the requested items failed to complete, but there were one or more successes
• Success – Indicates all of the requested items have been completed
• Pending – The request process is still active
Execution status
Note: Located in the upper right section of the Request
• Completed - The request completed and was verified
• Completed Pending Verification – All approvals are complete and waiting to verify the changes have taken place.
• Executing – The request is executing, which indicates the workflow is still processing.
• Terminated – The request has been terminated before it was able to complete
• Verify – The request has finished the workflow and is waiting to be verified by the provisioning scanner.
Approval status
Note: Located in the “Request Items” section
• Cancelled – The work item was canceled with no user input
• Expired – The work item expired with no action taken
• Finished – The work item has finished normally
• Pending – The work item is created in the pending state and waiting to be actioned
• Rejected – The work item was rejected
• Returned – The owner decided not to accept this work item
Provisioning status
• Committed – The plan has been executed and successfully applied by an integration. We have yet to verify the object which will take it to the Finished state.
• Pending – The plan has been executed, but the changes have not been completed.
• Unverifiable – The plan has been executed but this item was not found in the app's schema and therefore can not be verified by the scanner.
• Failed – The plan has been executed and there was a failure indicated by the integration.
• Finished – The plan has been executed and the changes have been applied and verified.
You may fetch the ProvisioningResult of your ProvisioningPlan in your workflow and based on the content of your ProvisioningResult object, you can redirect them towards right email template.
The approach that I showed to you is via using LCM Provisioning only. There's no OOTB configuration to do what you're looking for (as far as I know). You want a Custom feature as part of your workflow, so you need to customize your workflow and add necessary steps to it.
Or, you build a copy of LCM Provisioning (say, call it LCM Provisioning for Access Requests) and use that as part of your Access Request process. And then, you customize this LCM Provisioning for Access Requests workflow to add all the custom features and capabilities.
You will also need to build custom email template to which you will pass necessary variables to make decision about what to display and what not to display. Or, you may build separate email templates, make which template to call as part of your logic in Workflow Step, and then call appropriate EmailTemplate.
