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:

Access Permissions

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 ....