This is a follow-up post to my recent post on User Attestation. Some large clients might have account sponsors that are responsible for a lot of accounts and individually attesting to all of these accounts would be way too time consuming for them. To make this easier, you could implement a way to attest to multiple accounts at the same time. I do have some issues with making it so easy that they aren’t really considering the individual accounts anymore, but I’ll leave that up to the compliance team to work out. 🙂
The first step is to create some additional attestation attributes and bind them to the user object. I created two additional attributes for this:
- AttestedIDs – Multi-valued reference – Temporarily stores the accounts to be attested
- DisabledIDs – Multi-valued reference – Temporarily stores the accounts to be disabled
The next step is to update the user edit RCDC and add the sponsored accounts tab. I created a new grouping called “Sponsored Accounts” for this.
Download the Sponsored Accounts grouping here… *The search filters use Sponsor and not Manager because the client required both.
The key to getting the sponsored accounts to display like this is to use a UocListView that allows multi selection and has a ListFilter set to “/Person[Sponsor=’%ObjectID%’]”. Once the accounts are selected they get stored in the new AttestedIDs reference attribute. You could even do a select all by checking the box next to Display Name. I added the additional accounts to disable UocIdentityPicker as an easy way to clean up multiple accounts at once. This stores and accounts that are no longer needed in the DisabledIDs reference attribute.
That’s pretty easy so far. Now you just have to read the attributes and parse through a potential long list of accounts. In the past, this would have been a task for PowerShell, but now we have the MIMWAL Update Resources activity. 🙂
Do the following when attestation is requested for multiple users:
Enable advanced features to have the ability to set the Request Actor to “Requestor”. This will cause the workflow to execute as the original requestor and any updates will be no different than if the requestor did them manually.
Since all of the logic is already in place to do an attestation for an individual account, why would we recreate it?
- Set the AttestationRequest boolean attribute to true on all of the AttestedIDs. This will kick-off the existing attestation logic.
- Expression: true
- Target: [//Delta/AttestedIDs/Added/AttestationRequest]
- Clear out the AttestedIDs attribute to be used at a later date
- Expression: Null()
- Target: [//Target/AttestedIDs]
- Allow Null: true
- Set the employee status to “Inactive” on all of the DisabledIDs. This will kick-off the existing inactive logic.
- Expression: “Inactive”
- Target: [//Delta/DisabledIDs/Added/EmployeeStatus]
- Clear out the DisabledIDs attribute to be used at a later date
- Expression: Null()
- Target: [//Target/DisabledIDs]
- Allow Null: true
Next create the MPR to kick-off the workflow whenever an account is added to one of the new multi-valued reference attributes.
Chose “All People” as the Requestors (or a Sponsor set if you have additional policies just for them) and select “Add a value to a multi-valued attribute” as the operation. Remember, we are not granting permission with this MPR.
Choose “All People” as the before and after request set and set the AttestedIDs and DisabledIDs attributes as the Resource Attributes.
Choose the action workflow that we created earlier.
The request MPR will execute the MIMWAL workflow whenever an account is added to either one of those attributes. The workflow will act as the requestor to request attestation individually on all of the accounts and / or set the accounts to Inactive. Then the accounts will execute the existing attestation or inactive logic.
That’s even easier than doing it with PowerShell. The MIMWAL Delta function is very powerful since it allows you to follow multi-valued references.
That’s it for today. I’ll be adding more blog entries soon.
Thanks,
Mark