This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

New user attestation approval flow advice OIM 8.0.1

Hey all,

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.

  1. New person is inserted

    1. Person has direct manager
      1. New user attestation sent to the manager.

    2. Person does NOT have a direct manager
      1. Check for primary business role, and if exists check for manager of role
        1. New user attestation sent to this person

    3. Person does NOT have a primary business role assigned
      1. Check department manager
        1. New user attestation sent to this person

What is the best way to do this?

  • Customize an attestation approval workflow and just add the various approval methods?
    • Would the lack of a condition trigger a deny?
  • Do a calculated decision that captures all of the conditions above with a fall back to a role?

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.

Thanks!

  • 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.

    Thanks!

  • 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.

  • Hey Markus,

    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?

    Thanks!

  • 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?

  • Hey Markus,

    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.

    Thanks!

  • You have to set the necessary flags at the new person during creation. The self-service web portal sets IsInactive=True and IsNoInherite=1.

  • Hey Markus,

    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.

    much appreciated..

  • Yes, the flags IsInactive and IsNoInherite flags will change if the user is certified. Assuming you are using the default AttestationPolicy object.

  • Thanks Markus,

    I am close but not quite there.

    So the behavior associated with the insert is functioning as expected.

    • The person record is created in an inactive state without inheritance.
    • No entitlements are provisioned. NICE.
    • The attestation flow has found the appropriate attestor
      • When approved however, no subsequent event occurs to kick off the change toggling the two settings back to false/1, etc.

    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').