Do you ever wonder which audit trail to use? Or how to run them for the higher risk areas? Or do you wonder how to read them? If so, you are not alone.
Workday customers rely on audit trails to review configuration changes in their tenant; however, the vast majority of them still struggle with how to use the audit trails.
The good news is that this multi-part blog will unveil many of the unknown facts about how to appropriately mitigate risk of inappropriate configuration changes. In this particular blog, I will start by explaining the various audit trails to use, when to use them, as well as their pitfalls. In future blogs, I will provide helpful tips on scoping what to include when running the audit trails, pointers on how to read the output, and also the very important topic of completeness and accuracy with reporting in this area.
First, let’s talk about what an audit trail contains. In addition to showing who made the configuration change and when, the configuration changes are shown as added or removed relationships, or previous vs new attribute values.
Attributes are the easiest to understand as they are just a value; for example, the name a user gave to something, such as a report or a calculated field.
Relationships are a little more complicated as those are references between two instances: Think of a business process workflow instance, such as the Expense Event (Default Definition).
Attributes are the easiest to understand as they are just a value; for example, the name a user gave to something, such as a report or a calculated field.
Relationships are a little more complicated as those are references between two instances: Think of a business process workflow instance, such as the Expense Event (Default Definition).
As you can see, some of these complex object types, such as business process workflows, have instances that refer to other nested instances, and branch out very quickly.
Now, let’s talk about the different audit trails.
I will break them down into three different categories.
1. The first category is the audit trail off of the related action (those 3 little dots) off of the instance. That audit trail will show changes immediately related to the instance you are on, but it will not show changes that are nested.
For example, running the audit trail from the related action off of the Expense Event (Default Definition) workflow will not show whether you added or removed a condition rule to/from the step, nor will it show whether you added or removed a calculated field in a condition rule used in step. It will show that a step (step ‘f’ in this case) was added to the workflow, because that is immediately related.
The changes to attributes will only be shown related to the instance itself.
For example, if a new workflow was created and given a name ‘Expense Event (North America)’, it would show up as an attribute when running the audit trail off of the related action of that new workflow.
While this way of running the audit trail may seem convenient because it’s right there on the related action as you are viewing the workflow definition, users must be careful to understand the limitations of this particular audit trail.
2. The second audit trail category is Workday’s newer ‘Audit Trail Report.’ This audit trail allows you very easily to see the nested changes, such as those mentioned above, in one view. Furthermore, it utilizes tags as parameters so that users can run the audit trail using a risk-based approach: tag the instance you want to audit and run the report for that tag.
For example, assume we create a tag named ‘SOX Audit’, using the ‘Create Audit Tag’ task. After assigning that tag to the ‘Expense Event (Default Definition)’ via the ‘Maintain Audit Tag Assignments’ task, the tag can now be used as a parameter in the ‘Audit Trail Report’ to show nested changes to the ‘Expense Event (Default Definition)’.
If the calculated field mentioned in the example above changed, a line will show up in the audit trail as affecting the workflow, along with the lineage showing how it is related (via the condition rule up to the step ‘f’).
This feature is only enabled for business process workflows, custom reports, integrations, domain security policies, and user-based security groups.
3. The third category of audit trail can be used to catch everything else not auditable in the ‘Audit Trail Report’ above. You can create a custom report based on the data source: ‘Processed Transactions for Range, System Account, Task, and Business Object’ and select changes based on task.
Technically, a standard/delivered report similar to this already exists in Workday named ‘View User or Task or Object Audit Trail,’ but that report doesn’t allow customization. However, that standard report can be helpful when addressing completeness and accuracy, which we will cover in the third blog for this Audit Trail series.
In the next blog, I will cover how to perform a risk-assessment to determine which instance to tag for use in the ‘Audit Trail Report’, and also how to determine which tasks to include for the custom report in the third audit trail category above.
Author: Jen from Idaho
