I want to use this post to show the configuration for a basic account attestation/expiration process. Account attestation can quickly become a very complex undertaking. Especially if you rely on complex role engines (like BHOLD) to manage the attestation campaigns. As usual, your mileage may vary, but I’ve found that a basic attestation process will meet the needs of most clients.
The first step is to create the attestation attributes and bind them to the user object. I created three attributes for this:
- AttestationDate – DateTime – The date that the actual attestation is due
- AttestationRequest – Boolean – A checkbox for the account owner to attest to the account
- AttestationHistory – Multi-valued indexed string – A history of when the account was attested to and who completed the attestation.
The next step is to update the user edit RCDC and add the attestation tab. I created a new grouping called “Attestation”, added the three new attributes and some additional text to explain the process.
Next, you need to create the workflow activities to manage the attestation process and the attestation expiration process. I used the MIMWAL: Update Resources activity for this.
Do the following when an attestation is requested:
- Move the new attestation date to 180 days in the future
- Expression: DateTimeAdd(DateTimeNow(), “180.00:00:00.0”)
- Target: [//Target/AttestationDate]
- Keep track of the attesting account in the attestation history
- Expression: InsertValues(Concatenate(DateTimeFormat(DateTimeNow(), “yyyy-MM-dd”), ” – “, [//Requestor/AccountName]))
- Target: [//Target/AttestationHistory]
- Un-check the attestation box so it’s ready for the next time
- Expression: false
- Target: [//Target/AttestationRequest]
- Set the account status to “Active”, just in case it had previously expired
- Expression: “Active”
- Target: [//Target/EmployeeStatus]
- Remove the system expiration time, just in case it was previously set
- Expression: Null()
- Target: [//Target/ExpirationTime]
The next workflow will handle when an account expires because it has not been attested to.
Do the following when an account passes its attestation date:
- Set the account status to inactive
- Expression: “Inactive”
- Target: [//Target/EmployeeStatus]
- Set the system expiration time to 60 days in the future
- Expression: DateTimeAdd(DateTimeNow(), “60.00:00:00.0”)
- Setting this to a future date will give the responsible party a chance to change their mind before the account is actually deleted.
Next, create the transition sets for an attestation request and attestation expiration.
The attestation request set is just a set of all accounts with the AttestationRequest attribute selected.
The attestation expiration set is a set of all accounts that have passed the attestation date.
Next, you’ll need to create the set transition MPRs to kick off the required workflow.
This transition in MPR will run the account attestation workflow when the AttestationRequest attribute is selected.
This transition in MPR will run the inactive account workflow when the accounts attestation date has passed. Remember, since the workflow sets the system expiration date to 60 days in the future, the account owner has an additional 60 days to complete the attestation process. Disabling the account is sometimes the gentle reminder that the account owner needs to complete the attestation process.
Another important item that goes hand in hand with any attestation process is the account owner notification. I like to remind the account owners that an account is due for attestation multiple times before the actual due date. Maybe at 14 days, then 7,6,5,4,3,2,1? that gives them plenty of notice before the account gets disabled and flagged for deletion. Once the attestation due date has passed, let them know that the account has been disabled and start reminding them of the upcoming deletion date.
In a future post I’ll talk about what to do if you require a way to attest to multiple accounts at the same time.