Hi Sailors,
I have a requirement where I have to introduce an auto-generated form in IdentityNow after change on identity attributes from authoritative system.
So, once work Item gets created we would need it to go through 5 levels of approval.
Can anyone please provide their thoughts that how can we achieve it in IdentityNow.
Thanks in advance!
Is the intention to prevent the attribute changes if one of these approvals is rejected?
You can definitely have a workflow generate forms assigned to specific identities:
You can use the identity attribute change as a trigger for the workflow. But I’m not clear what it is these forms would be ‘approving’ and what action would be expected if they approve or reject.
Hi @dopstrick ,
Thanks for your response!
Yes so I need a custom approval form tagged with workflow. So, post identity attribute change I need an auto-generated form in IDN with the changed attributes. After that form should be going to governance group member approval and post decision as “Approve” it should go to the next level of approval. So, likewise it should follow 5 levels of approval and once final approval gets completed, then IDN should created a ticket with the all information in it.
Could you please let me know is that achievable , if so could you also please your thoughts on it.
You can generate forms (see the link I attached earlier) from a workflow, that you con configure. It can include the attribute changes you detected, and the workflow can be made to pause, wait for a response from the generated form, evaluate the response in the workflow, and either proceed to the next form, or go down a different path.
Now there are some questions: is this work item you generate at the end a provisioning item, in that it should come from a provisioning plan and and tracked as such?
If so, you would need to build a disconnected application, and in your workflow, create an access request for that system, and that will produce a provisioning plan and work item.
If not, then you can either send an email to team from the workflow, or generate a final form and assign that to your downstream team, and include the information you want included in the form.
Please note, none of these forms are ‘approvals’ in the sense of the SailPoint specific approval objects. They can be made to function as an approval step on whether to proceed with the workflow to the next step. You are not using SailPoint’s approval/ provisioning process. You are effectively creating your own for this specific workflow, which will not affect any behavior outside the workflow.
What would you expect to happen if one of the five ‘approvals’ is rejected. Would the workflow just stop? or are you expecting IDN to be able to unwind the attribute change it detected?
Thanks @dopstrick for the detailed description.
In case of approvals, we are routing the form to the different levels of approval to provide the approver signoff. But, if any of the approver deny/reject it should go back to the 1st level of approval.
Is that something which we can do in IDN?
Once final approval gets completed we need to create a ticket with all the information tagged in it.
For ‘creating a ticket’ you mean a workitem in sailpoint, correct? not an external system like ServiceNow.
You have two options for a “work item” in IDN:
The downside of option 1 is similar to using workflow forms as ‘approvals’. They will not be tracked by IDN as actual work items. There will be no record of provisioning, nor of an action being ‘approved’. If you have audit requirements around providing evidence for these steps within the tool, you can’t use these options.
In terms of having the workflow loop back to the first approver, you could try doing that using workflow steps. I’m not sure if IDN allows for that. From a design perspective, it’s not great because it creates a scenario where the workflow never gets completed.
Hi @dopstrick, were you able to have work items created when triggering provisioning through disconnected apps via the workflow? I was noticing behavior where work items were only being created for ‘disable’ if it was specified on the identity profile. However if identity profile was set to maintain, and the workflow set to disable operation, there were no work items created for disconnected (delimited) application accounts.
Hi Levi,
The question Prashant asked about in this thread was very different than what you’re describing.
You might want to create a separate thread in the discussion forum for this.
That said, is your workflow triggering at all? Does it get to the ‘Manage Accounts’ step? Are you seeing any errors?