Hi @rebekah_reveile!
Good to hear from you as well, Thank you for picking this up!
This would roughly be the process that an auditor would currently do to find all events generated by a given identity (let’s say all events generated by me):
- Check this documentation, see the second level field
actor for events. Here it says it has first level field name with description “The name of the identity, source or system that generated this event” with example actor.name:“Andrew Beck”.
- Determine that the query should be: actor.name:“Angelo Mekenkamp”, or to be more exact and filter events caused by my colleague “Michael Angelo Mekenkamp”, search on actor.name.exact:“Angelo Mekenkamp”
- Auditor searches on this query and find no events regarding configuration of attribute sync, so concludes I did not do anything on this topic.
However, I have made configuration on attribute sync, but it is just not visible when using this query.
The documentation needs to improve such that the auditor knows they should refine their query.
You can try this out yourself on a test tenant by changing attribute sync logic (turn something on and then off again) and trying to find the event using the suggested query in documentation.
@angelo_mekenkamp I’ve done a bit of digging, and it looks like we might have a bug in the product. I was able to reproduce this using your steps, and the attribute sync events didn’t show up in the results list as expected. However, they did show up in the Provisioning Activity audit report (type:provisioning).
It looks like the attribute sync events (as well as a few other event types) are using the technical ID of the identity in the name field rather than the identity’s actual name.
This is a bug, and I’ve brought it up with the engineering team so we can get it resolved.
In the meantime, you can get the technical ID of the identity from the identity list, right at the top of the details for that particular identity. It’s called ID, and it’s a 32-character string of random numbers and letters. With that, you can enter another query:
actor.name:"Angelo Mekenkamp" OR actor.name:"<Angelo's ID here>", and that should return a more complete list of results, including attribute sync events.
Thanks again for your feedback and for helping to improve the product. If you see anything else that seems out of place, feel free to report a bug or let us know!
Hi @rebekah_reveile, thank you for agreeing with me that this is a bug! It indeed does not make sense that the actor.name field contains a value resembling the id. I think this should be populated in the field actor.id, which currently does not seem to exist. And that actor.name should actually contain the name in a clear and consistent manner.
Please note that I already tried to submit this as a bug by creating a support ticket (CS0387543). Do you have access to this ticket (as SailPoint employee)? If so, please check the ticket and the responses I (unfortunately) get from SailPoint Support.
Kind regards,
Angelo
@angelo_mekenkamp Looks like I can see that ticket. I’m getting in contact with some engineering folks to see whether there’s anything I can do to get this rolling. 
In the meantime, I’ll make a brief update to the Search doc to indicate that the actor.name field is the name of the actor or the ID of the actor.
You can reach out to your CSM if you’d like to escalate further. Thanks again for all of your feedback!
Hi @rebekah_reveile,
Thank you for making this change. To be fully transparent. Are you able to document the list of all event types that exists (which can definitely be useful to auditors), and perhaps for each one specify which format is used?
And in particular can you help me with the format used for events of type Update Entitlement Updated Passed, and of type Close Identity Requests Started.
@angelo_mekenkamp We actually have a ticket right now to work through a partial list of audit events and list them out (SAASDOCS-8461), but Identity Security Cloud has many thousands of audit events, so a complete list isn’t something we can support or maintain.
I don’t have both of those events in the demo tenant I use, but if you search on the names of each of those events in quotation marks, and go to the Events tab, you should see the data used for the actor in one of the default columns in the search results. I’m seeing something strange for the Update Entitlement Updated Passed event, where it looks like the actor.name field contains both the ID and the name. I’ve brought that up with the engineering team, as well, but I understand this makes things a lot more complicated in terms of auditing.
If you’d like more specific help, I’ll have you reach out to the Identity Security Cloud Discussions and Questions category, or to your CSM.
As always, Angelo, thank you for your feedback and insightful questions. You help us improve both the docs and the product itself.