In the Console, the new Audit Logs feature is accessed exactly the way you might expect it to be accessed: by clicking the Audit Logs link in the Console navigation pane. In other words:

Like other Console features, Audit Logs is available only if you have a role that has been assigned the proper permissions (for Audit Logs, those permissions are Allows you to read audit logs for Console user actions for an entire application and Allows you to read audit logs for Console user actions for a specific user). The following roles have access to the Console Audit Logs:

• Application Admin
• Console Access Manager

These two roles also have access to the Audit Logs, albeit only from the Manage Agents section of the Console:

• Console Access Viewer
• Customer Care Portal Agent Manager

If you don’t hold one of those roles, you simply won’t see the Audit Logs link:

Audit Log terminology

Before diving into the nuts-and-bolts discussion of the Console Audit Logs, we need to take a moment to explain some of the audit log terminology. To begin with, the name Audit Logs might conjure visions of multiple audit files: a user profile audit log, an application audit log, a Registration Builder audit log, etc. However, that’s not really how the Console Audit logs work. Instead, when you go to the Audit Logs page, you’ll see a long listing of all your audited events, regardless of whether those are user profile events, application events, Registration Builder events, etc.

You don’t need to choose between, say, the user profile audit log and the application audit log, because those things don’t exist: for all intents and purposes, there’s just one audit log.

Each item in that audit log is a record of an event that took place in the Console: a flow was created, the settings for an API client were updated, a user profile was updated. These records provide detailed information about the event. For example, creating a flow produces an event record similar to the following:

📘

The data returned for individual events will differ slightly depending on the event type; for example, if you change a user’s street address that won’t populate the New Flow Version field. Why not? That’s right: because a new flow isn’t created when you update a user’s street address. For more information about event fields, what they’re for, and when they might be used, see [Audit log activity reference.

For the most part, this is pretty straightforward: you have one audit log (i.e., one source for all your audit events), and that log is composed of records for each auditable event that took place in the Console.  The only time where things might get a little confusing is when you export your audit data. Do that, and the resulting comma-separated values file will include three columns with the names Event Type, action, and Activity:

What’s the difference between an Event Type, an action, and an Activity? Well:

• An Event Type refers to a general category of Console tasks. For example, the agentFlowAction category (event type) includes such tasks as creating a flow, deleting a flow, and promoting a flow. Each event type is a collection of related actions. If you’re interested in all flow-related events, you can search for the agentFlowAction event type instead of having to search for each of the different flow actions.

• An action is an individual task that can be carried out (and audited) in the Console: creating a user profile, updating a user profile, deleting a user profile are all examples of actions.

• An Activity is the user-friendly label given to an action in the Console UI. For example, the action recordUpdated has the label User Updated; that’s the value you’ll see when working with Console filters:

  

  Unless otherwise specified, whenever you see the word “activity” in this documentation we’re referring to one of these user-friendly labels.

Console user audit logs and profile change audit data permissions

As noted in the previous section, you won’t see the Audit Logs link unless you hold either (or both) of the two Audit Log permissions (Allows you to read audit logs for Console user actions for an entire application and Allows you to read audit logs for Console user actions for a specific user). Why are there two different Audit Log permissions? That’s because there are two different places that you can access audit log data:

• From the main Audit Logs page (controlled by the Allows you to read audit logs for Console user actions for an entire application permission).

• From the Audit Data tab located in the Manage Agents section (controlled by the Allows you to read audit logs for Console user actions for a specific user permission).

In addition, you can also access profile change data from the Audit Data tab in the Manage Profiles section. The ability to access that data is controlled by the Allows you to read audit logs for a specific profile permission. In other words:

As always, the permissions you hold are derived from the agent roles that have been assigned to you. Here’s a quick summary of who can access what when it comes to audit information:

Why are there so many ways to access the same information? For the most part, that’s to help safeguard users’ personally-identifiable information (PII). If you access profile change audit data (that is, if you access the Audit Data Tab while viewing a user profile), you’ll see plenty of PII. For example, if a user has added their cell phone number to their profile then that new cell phone number will be included as part of the event record:

However, personally-identifiable information such as this (with the exception of the user’s UUID) is not included as part of the Console user audit log data:

From the Console user audit log data, we only know that a user profile has changed. We don’t know who the user is (other than the fact that they have the UUID 2ca0ee4c-f1b6-4375-a317-b86035c264a1), we don’t know which attributes in the user profile have been changed, and we don’t know the values of any of those attributes. As a general rule, that’s because the audit logs are designed for administrators who typically don’t work with user accounts; instead, these admins are concerned more with keeping track of the activities that Console agents are carrying out and in making changes to the application and to API clients. As such, these agents do not need (and should not have) access to PII.

By comparison, the profile change audit logs are aimed at agents who are already tasked with managing user profiles. These agents already have access to personally-identifiable information; consequently, no additional exposure is generated if they have access to the before-and-after values found in the profile change audit data. And, of course, they typically need this access in order to do their jobs,

Of course, there are some agents (such as Application Admins)who have access to both the Console user audit logs and to profile change audit data. In that case, does it matter where a user like this accesses audit data from? Well, it might: there are a couple of differences between the audit data available from a user profile page and the audit data available on the Audit Logs page. Yes, you can retrieve user profile audit information from either location. However:

From the Audit Logs page, you can only retrieve data recorded in the last 30 days. In other words, if a user profile was changed 32 days ago, that data will no longer be available, at least not from the Audit Logs page. However, that same profile change can be retrieved from the user’s Audit Data tab. That’s because that data is stored for 90 days rather than 30 days.

You will get a slightly “richer” set of data from the Audit Data tab than you will from the Audit Logs page. When you access user profile changes from the user’s Audit Data tab you’ll see the  new value assigned to an attribute as well as the value that was previously-assigned to the attribute. For example, here you can see that the primaryAddress.zip attribute, previously set to 97206, was changed to 98101:

New/previous values are not recorded in the Console user audit logs. If you look at a user profile change from the Audit Logs page you’ll see only that a change was made; what you won’t see are the exact changes (i.e., the old and new attribute values) that were made:

The main takeaway is this: any time a user profile is updated, that change is recorded twice. The data available to you (and how long that data will be available) varies depending on how you access it, but the data still refers to the same event.

But at least that’s it when it comes to all the different places where you can access audit data, right? Funny you should mention that.

The Audit Logs tab in the Manage Agents section

You can also access audit data from the Manage Agents section. To do that, click Manage Agents and then, from Manage Agents page, click an agent name:

You’ll then see an Audit Logs tab that looks a lot like the Audit Logs page:

From here, you can return any type of audit data: client setting changes, flow promotions, agent role updates, user profile modifications. However, the data returned only reflects the actions carried out by the specified agent. For example, suppose you go to the Manage Agents page, click on Greg Stemp’s agent account, and then click Audit Logs. Any audit data you return at that point will represent actions carried out by Greg Stemp, and only by Greg Stemp:

If you want to see actions carried out by Terrance O’Reilly then you’ll have to access Terrance’s agent account and go from there.

Which brings us back to the Audit Logs page. From the Audit Logs page, you can search for anything; in fact, you can even search for everything. That’s because, on this page, there are no preset filters. You can filter by action type or agent name or the date that an event took place, but you don’t have to. Among other things, that means that you can look for audit data regarding any user profile, and for actions carried out by any Console agent.

In other words:

• If you’re only interested in user profile changes that have been made to a specific user account, a quick and easy way to do that is to access the appropriate user profile and then click the Audit Data tab. This is also the go-to place if you’re interested in audit data that includes before and after values for user profile changes.

• If you’re only interested in actions (of any kind) carried out by a specific Console agent, a quick and easy way to do that is to access the appropriate agent account and then click the Audit Logs tab.

• For other Console user audit logs searches, access the Audit Logs page. (And if you want to, you can do either of the first two tasks from that page as well.)