Audit Log
What the Audit Log is and how it works, including best practices and examples.
- The Audit Log notes changes made to a record. The Audit Log exists on every Page in MinistryPlatform.
- To access the Audit Log, open a record and click the Audit Log panel. When the panel opens, you can click By Date or By Field to sort the Audit Log accordingly. You can further expand each Audit Log entry to see the Previous Value and New Value.
- Dates are in the User's local time, determined by the User Timezone or the Domain Timezone if the User does not have one.
- Audit Log reports are available to those with the Administrator Security Role.
- If you created or updated something while impersonating another User, the Audit Log notes the actual User and the impersonated User. This occurs when an API client (for example, BMT) acts on behalf of a User (for example, to create a Donation record using the BMT) or if an administrator impersonates a User (for example, using the Impersonate User feature).
- If you receive the "no records found" message when you create the Audit Log, the record was part of the software at implementation or added directly to the database through the back end.
- An API User without an "on Behalf of" specified in the Audit Log means that a person created or edited the record without logging in and therefore didn't automatically match to an existing User. For example, when a person that isn't in the Platform registers for an Event, the related Event Participant record displays Created by: API User.
- SYSTEM in the Audit Log means that the Sign-in/Sign-up flow that several Widgets and external providers use created new Contact and User records.
- As a best practice, we recommend you create a NEW company contact and a NEW user per integration. Then, add the NEW API Client record and name it something other than _apiClient. When you do this, the Audit Log displays exactly which integration made the change. Review Giving Developers Access for more information.
- Context is important when looking for Audit Log entries. The Audit Log tracks changes made to any field on a single record, but it can't see related changes beyond that record. For example, if you add a Participant to a Group, this does not affect the fields on either the Participant or Group record, so the changes don't display in either record's Audit Log. However, the changes display in the new Group Participant record's Audit Log.
Audit Log Retention Policies
To optimize your system's performance and storage efficiency, we implemented policies around audit log retention. These can be found under . (You may need to change the view to All Records to view the policies.)
- For high-volume areas of MinistryPlatform, the Audit Log will keep changes for 90 days.
- For other areas that don't impact system performance, the Audit Log will keep 15 years of changes.
These policies do not delete any of your data, just the fact that the data was changed.
If you have concerns about the retention policy for a specific table, feel free to reach out to Support.
Why is this important?
Audit Log records build up over time and take up the majority of storage space on your system. Clearing out old audit logs frees up valuable space and makes the system run faster.
What are the high-volume areas?
The Audit Log keeps changes made to the following high-volume areas for 90 days: Messages, Recipients, Message Templates, Page Views, System Tasks, and Webhook Invocations.
What is the current impact?
To help you see the impact that large tables have on your system, you can take a look at two views:
- In the navigation menu, click . Select the Large Audit Tables view to see row counts and approximate storage space in the Audit Log. Use this information to gain insight into what's stored in your Audit Log. There may be opportunities to reduce this by cleaning up the records in those tables.
- In the navigation menu, click . Select the Large Tables view to see the percentage of space your Audit Log and Audit Details are taking up. Use this information to understand why the Retention Policies are necessary. The lower the percentage, the better your system's performance will be.