Audit, Audit, Read All About It: Simplify Workday Compliance with Audit Tags
In the 2 years since I joined the Workday world, I’ve seen an increased need for auditing changes within Workday for compliance and SOX purposes. From client to client, every use case is slightly different so it’s not always the easiest to report on the details of who, what, or when something was changed.
Whenever I hear the word “audit”, my mind first jumps to the sometimes-painful Audit Trail process of taking a related action on an instance and attempting to dig through multiple rows of data to determine what was changed. It can sometimes be hit or miss whether the information is digestible, or if you need to continue digging into the layers of the audit trail to truly find what you’re looking for. Let’s complicate things further and try to audit multiple items regularly over time! It would be great if there was a more straightforward way to show these changes, right?!
You Have Options!
One option a company may take is creating custom reports to audit specific areas in Workday. The issue with this is that it may involve numerous reports and sometimes they don’t even provide the exact information you need. Finalizing your audit with these reports could involve additional steps of extracting and shaping the data further within a spreadsheet. Unfortunately, SOX reporting tends to be extremely complicated in Workday. To try to create a custom report that reports on all the touchpoints can sometimes be impossible.
If you need to track changes to custom reports, business processes, security groups, domain security policies, or integrations, Workday’s Audit Tags may soon become your new best friend! Audit tags are a much simpler and digestible method for repeatable tracking of changes in your tenants. The main premise behind audit tags is that you can assign tags to specific instances within Workday (i.e. custom reports, business processes, security groups, domain security policies, or integrations) and run a Workday-delivered report that displays the following:
- A trail of changes to the tagged instance(s)
- Who made the change
- How the change was made
- What changed
- When the change was made
- A trail from the tagged instance(s) to the change that occurred
Creating the Tags
Create audit tags via the “Create Audit Tag” task. You can select one or more security segments if you’d like to restrict the tag to certain people. We can go into more detail on audit tag segments another day, but the idea is that you can provide a more simplified experience if you have different auditors by limiting the tags they can see. For example, if your company has both Payroll and Human Resources auditors, you can restrict your HR Audit and Payroll Audit tags to the respective users.
NOTE: There are some prerequisites for creating and maintaining your audit tags. Ensure you configure domain security appropriately or you’ll be unable to perform the setup and usage. In your tenant, search “domain: audit tag” and you’ll find at least three to review. Workday Community Documentation includes more information on these and others, but the information in this blog will be your starting point!
After creating tag(s), you have two ways of tagging your desired instances to audit:
Option 1: Navigate directly to the instance (i.e. your custom report) and take a Related Action: Audit > Add Audit Tag. This allows you to add your tag(s). Alternatively, you could use Maintain Audit Tag to manage adding/removing tags in the same task. You must have an existing audit tag to assign a tag!
Option 2: Run the task Maintain Audit Tag Assignments. In this task, you have the ability to select your desired audit tag and add or remove multiple instances (multiple reports, business processes, etc.) all at once.
Once you have your audit tags assigned to your instances, you can then run the Workday-delivered report Audit Trail Report in which you’ll now be able to easily audit changes on these tagged instances. When running the delivered report, you’ll be prompted for which tag(s), instances to include, start/end moments, tasks to exclude, whether to hide sibling relationships, whether to hide unrelated data and/or to show the instance’s lineage. Workday displays the instructions for each field on-screen so there should be no guessing what you need and why.
Making Connections
Audit tags surface sibling instance changes that impact parent instances being audited. An example of a sibling relationship is a Business Process (BP) definition: there is a relationship indicating that a BP definition has a BP step. Conversely, there’s another relationship showing that a BP step is used by a BP definition. The latter is considered a sibling relationship when generating the Audit Trail Report from the perspective of the BP definition.
Hiding sibling relationships can help reduce redundant information on the Audit Trail report. For instance, if your primary focus is the relationship from the BP definition to the BP step, you may not need to see the reverse entries showing the relationship from the BP step back to the BP definition.
This is a key benefit that audit tags provide when compared to the Audit Trail Report, which only identifies changes that directly impact the audited instance.
Leveling Up
After that, take your audit game to the next level by copying the standard Audit Trail Report and prepopulating the various prompts for your different needs. This allows you to run it when needed using dynamically populated time periods such as from First Day of Last Month to Last Day of This Month. You could even schedule the custom Audit Trail Report to have it run on a desired cadence (i.e. weekly, monthly, etc.) using whichever tags, instances, start/end moments, etc. that makes sense for your business needs.
You will find quickly that audit tags will speed up your auditing and make for a simpler experience to track the changes for your compliance needs. Cheers to audit tags! If you need assistance setting yours up, don’t hesitate to get in touch with Kognitiv!
