Use the Search Logs field with audit logs

The Search Logs field (located at the top of the Audit Logs page) provides a way for you to perform a full-text search of most of the fields in your audit logs. We say “most” because there are two exceptions:

• Date. Similar to the address, the date and time that the event occurred is ignored when doing a full-text search. Fortunately, that’s not really a problem: after all, you can use the Filters section to limit the returned data to specific time interval.

• Activity. Typing in the UI label for an activity will not return the expected records; for example, typing in API Client Created will not return a list of all the events involving creation of a new API client:

  

But that’s because you typed in the activity label. If you enter the activity name (in this case, clientCreated) you’ll have better luck:

Alternatively, you can use the Filters section to limit the returned data to a specific activity.

📘

For a list of activity names and activity labels, see Audit log activity reference.

Other than those exceptions, however (two of which can be worked around by using the Filters section), you can do a full-text search across all the fields in all your audit events. For example, suppose you’re interested in any events involving a specific API client. That’s fine: just search for the client ID. How about a specific flow? Just search for the flow name. Curious whether a specific agent role has been assigned to (or unassigned from) a Console agent. Then search for that agent role. The sky is pretty much the limit.

For example, suppose your audit logs look like this:

Let’s further suppose that you’re only interested in a certain flow, a flow named testFlow. Have any of your agents modified this flow in any way? To find out, type flow in the Search Logs field and then click Search:

In turn, you’ll get back a collection of all the recorded actions that include the string value testFlow somewhere in the event record:

Just keep in mind that, when searching from the Search Logs field, you’re searching all the fields for all your events for any instance of the specified search term. That means that, on occasion, your search might return more than you bargained for. For example, suppose you have a flow named greg. To search for that flow, you type the following:

When you run your search, you’ll get back events for the greg flow. However, you might get back a number of non-flow events as well:

Why did we get back these invalid API Client Deleted events? As it turns out, those aren’t invalid events after all. If you look at the Console User Email field, you’ll see the string greg is in agent email address:

You asked for all the events that included the string value greg, and that’s what you got.

You might never run into this, and there are often ways to work around it. But it’s still good to know.

📘

As long as we’re on the subject, we should note that Search Log searches are not case-sensitive: you’ll get the same results regardless of whether you search for greg, Greg, or gREg.

There are also a few things you should know when it comes to searching for activities. To begin with, we should know that we are not searching for activities as they are listed in the Activity column. For example, suppose you only care about Flow Deleted events. With that in mind, you might expect this filter to return those activities:

As you can see, however, that search doesn’t return anything, even though we know that there’s at least *one *Flow Deleted activity in our audit logs:

Why did our search fail? Our search failed because Flow Deleted is just a user-friendly label employed in the Console UI; it’s not actually part of the event database. The actual name of the activity is flowDeleted, as you’ll see if you search for the string flowD:

The moral of the story? You need to search on the activity name rather than the Activity label, or use the filters to search by Activity. 

You should also know that typing a partial activity name (say, clientC) returns the same results as typing in the full activity name (e.g., clientCreated):

That’s cool. Now, suppose you want to return information about two different activities: clientCreated and flowCreated. Can you do that? You bet you can. Just type both activity names in the Search Logs field:

To search for three different activities, well:

The only catch here is that you must use the full activity**name when searching on more than one activity type. For example, searching for clientC and flowD will not return the expected results:

In this case, search looks only for the last item in the list (flowD) and ignores everything that came before it.  Use the complete activity name when searching for multiple activities.

In case you’re wondering, any time you enter multiple search criteria, that search is always conducted as an OR search; in other words, events are returned as long as they match at least one of the search terms (they don’t have to match all the criteria). In our previous example, you’ll get back all the events where the activity is equal to clientCreated or where the activity is equal flowDeleted. 

And, needless to say, this works for anything you might be searching for. For example, suppose you search for a flow named testFlow:

In turn, you might get back two events:

Now, search for flows named testFlow or audit:

This time you get back four events, two for the flow named testFlow and two more for a flow named audit:

Search by Activity (Category) Value

Another way to search for multiple activities at the same time is to search for an entire category of activities. For example, the activity agentCaptureClientAction includes such actions as creating or deleting an API client. To return all the API client-related events, enter agentCaptureClientAction in the Search Logs field. That brings back information similar to this:

To return both API client-related and flow-related actions, enter agentCaptureClientAction  and agentFlowAction in the Search Logs field:

All in all, pretty darn easy.