Capturing Admin Errors helps to highlight processing issues that require attention to administrative users without them having to drill down in to workflows.
RSA Field Example: To put this in to a real-life scenario, it’s a common requirement that Active Directory accounts have the password reset and are moved to a different OU when the associated user is flagged as a leaver.
This would be achieved using Provisioning Command nodes (1) within the fulfillment workflow. These Provisioning Command nodes then call the relevant AFX capability on the Business Source to perform the action and provide a status of 0 if successful or -1 if unsuccessful (2). Further details on the values and how they can be referenced as variables can be found here - https://community.rsa.com/docs/DOC-64651
A Decision node (3) then separates the successful from the unsuccessful allowing the Create Admin Error nodes (4) to return different errors depending on the result.
The Create Admin Error is then configured to capture the relevant details in a clear format that is easily understood by administrators.
Below is a format we typically use when configuring Admin Errors for the following reasons:
Highlighting the status (WARNING) at the start of the message helps focus attention
Including the associated process (LEAVER) helps sorting/filtering/reporting and can form part of daily checks
Including dynamic variables from the workflow makes the message more meaningful and easier to track
Inclusion of the Change Request ID enables easily linking to other tables/views for extended reporting options
Pipe separator simplifies report query
The Admin Errors are then visible within the UI from the Admin > Admin Errors screen
And can be easily extracted in to a report format which can be emailed on a scheduled basis or added to a dashboard to form part of the daily checks.
As mentioned, the inclusion of the CR ID in the Admin Errors provides a logical join to the CR views which provide useful additional detail such as user details, dates, times, days late, etc.
Within the above report, the join was achieved using the following query:
FROM avuser.PV_CHANGE_REQUEST_DETAIL pCRD
LEFT JOIN avuser.V_AVR_ADMIN_EXCEPTIONS vAAE
ON PCRD.CHANGE_REQUEST_ID = TRIM(REGEXP_SUBSTR(VAAE.Description, '[^|]+', 1, 5))
The REGEXP_SUBSTR function uses the pipe separator (|) as a way of determining the string to return. Once joined to the PV_CHANGE_REQUEST_DETAIL view, this can be easily extended, for example:
LEFT JOIN avuser.PV_CHANGE_REQUEST pCR
ON pCRD.CHANGE_REQUEST_ID = pCR.ID
LEFT JOIN avuser.PV_USERS pUSR
ON pCRD.Affected_User_ID = pUSR.ID
Reduce troubleshooting effort (no need to dig around in workflow)
Help create audit trail
Quickly and clearly highlight issues that require attention
Easy to configure
Very low data footprint so won’t impact performance
Ability to include variables in error messages provides huge flexibility
Populated to V_AVR_ADMIN_EXCEPTIONS view
Ease of reporting/dashboards
Admin Errors are not included in data purging although can be manually deleted from the UI if required
- We are using v7.1 P04 in the example below, however most versions of the older product also have milestones available.
Create Admin Error nodes are found under the "Modeler Toolbox", about halfway down, as shown in the image below. Just drag and drop them into your workflow.
Free text box
As mentioned above, within the Error Description box you can also use variables from within the workflow. The use of dynamic variables makes the message more meaningful and also provides greater flexibility when it comes to reporting.