We're Moving ... Again
Yes, the Identity Cloud documentation is once more on the move. And this time we're headed to two different locations:
The REST API documentation is moving to here: https://developer.akamai.com/api/
And the remainder of the documentation is moving to here: https://learn.akamai.com/en-us/webhelp/identity-cloud/technical-library/GUID-76D7D02B-8C6F-4188-AF17-0711F9620B38.html
As for the Education Center, well, the Center itself will disappear on July 23rd. We apologize for any inconvenience, but we look forward to becoming a full-fledged member of the Akamai family.
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. In other words, you’ll see something similar to this:
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:
Note. 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 Exporting Audit Log Search Results.
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.