So in a scenario where business units across the enterprise have differing hierarchies, I was wondering what your thoughts would be on handling the following.
What is the best way to do this?
I know that this is a reasonably simple use case, but I was reading through the attestation documentation but I didn't get a good bead on how to run a specific scenario with an example.
Just wondering if I am asking the wrong question or if this should be one of those RTFM situations. Any insights with regards to the best way to approach the scenario above?
Even links to the correct details would be helpful.
You need to change the used approval workflow for the new use attestation. How you implement the workflow is up to you. The option with a multi-step approval workflow has the charm of being easy to understand if someone else looks at the workflow. but you have to you use some CD steps in between so that it might take more team between the insert event of the person and the approval step being available.
The solution with the custom approval step is faster but harder to maintain and self-explanatory.
Hope all is well.
Ok so I implemented a custom attestation flow as you recommended and in my testing I can see that the approval flow follows the path.
The flow is as follows:
So on attestation runs, I can see that the flow is appropriate, and based on whether the person meets the criteria in the calculated decisions traverses the next positive/negative hop.
For whatever reason however the attestation email does not get sent.
Example of one of the approval steps:
Before I customized the approval workflow I do beleive I was getting emails (more because I was configured as the default in the base config I think. What am I missing here?
Do you see any errors in the Job Service logs? Is the same custom mail template working if you assign it to the default workflow?
No errors in the job log, but when I assign the default attestation procedure back to the event with my custom approval policy/workflow it seems to work ok.
I guess I can figure it out from here for this one thanks!
One more question, in my case, I am triggering the new person from the API. While the attestation runs fine, I am noticing that all of the entitlements associated with the persons ProfitCenter, PrimaryDepartment, and PrimaryBusinessRole apply irrespective of whether the attestor approves of the access.
Is this expected? The certification state is set to "New" as defined by the base config params, but I am not 100% certain that I fully understand all of the requirements to ensure the expected behavior is executed.
You have to set the necessary flags at the new person during creation. The self-service web portal sets IsInactive=True and IsNoInherite=1.
So if I am understanding you correctly, if I set those two parameters at insert, and the Attestor certifies the new person, the resulting process would reverse the “isInactive” & “noInherit” flags?
I will test this when I get in.
I have postponed my demo until every use case is perfect and this is one that has been holding me up.
Yes, the flags IsInactive and IsNoInherite flags will change if the user is certified. Assuming you are using the default AttestationPolicy object.
I am close but not quite there.
So the behavior associated with the insert is functioning as expected.
What should I be looking at to ascertain the appropriate behavior after the approval is issued? I have verified that the DB Queue is in good shape and that there are no pending compilation requirements.
The fags will be reversed by the process VI_Attestation_AttestationCase_Person_Approval_Granted. But as I said, only if you use the ootb attestation policies User recertification or New user certification (UID_AttestationPolicy = 'ATT-BA221F0DA9894EF6B40D03B615EB5077'Or UID_AttestationPolicy = 'ATT-5800B88C704B415BBF79A305298DAA23').