When you have an ASP.NET Core application, that publishes content often and has different users, it’s a good idea to keep track of what is happening in the app: What changes? What content gets deleted or published by who? Who logged in, and when, did somebody fail to log in repeatedly using a wrong password? Who changed the settings?For example: Imagine you're managing a news portal where multiple articles are being written and published daily. One day, an article titled "Breaking News: Major Policy Change Announced" was accidentally deleted. It was a high-traffic piece, and its sudden disappearance created confusion among readers and the team. As an administrator or perhaps an owner, you want to restore the article, then find out what happened and who made this change. The answer is: Orchard Core and its Audit Trail module.Are you new to Orchard Core? It's a great open-source framework and CMS built on ASP.NET Core. Check out the official getting started docs.The Audit Trail module logs key changes and events in the system, such as content creation, deletion, and login failures. It also allows tracking changes to content, restoring previous versions, and recovering deleted items. It’s all extensible too, so you can add more features with some coding. Let’s see how to use it!First, go to Configuration → Features and make sure the Audit Trail feature is enabled. Optionally, if you also want to track user events (like somebody logging in etc.) you can enable the Users Audit Trail feature too. Please note that enabling the Users Audit Trail feature will automatically enable the base Audit Trail feature, as it is a dependency of the Users Audit Trail. After this, you can access the audit trail settings under Configuration → Settings → Audit Trail. You can see three tabs on the top: Events, Trimming, and Content. Let’s start with Events. Here you can see the events that will trigger an audit trail record, and by default, all of them are enabled. The first set of events is tied to content, so content item creation, removal, etc. You can disable any of those if you want. The second set of events is for the user. This set of events only appears if you enable the Users Audit Trail feature too. These are for user activities, so login, failed login, etc. You can also select to record the client's IP address. We recommend erring on side of caution, and starting with everything enabled, and only disable certain events if it turns out that they’re just noise for your site.Now take a look at the other tab, Trimming. If a site has a lot of activity, perhaps it’s good to delete audit trail logs after a year or so, since the records can eat up a lot of space in the database (it won’t really get slower, but depending on your hosting provider, you may need to pay more). The trimming setting allows you to do that. The default trimming option is 90 days. So any audit trail event that is logged and older than 90 days will be deleted from the database. To avoid trimming you can select the Disable trimming task option. In the Last run field, you can see the most recent time the trimming task was executed.Now, check the content tab. Here you can see the types of content for which events are logged. You can freely disable or enable any of them. In our example, some are enabled, but some are disabled. This is because we configured the audit trail settings in the startup recipe. For example, see this startup recipe in our open-source Lombiq Walkthroughs module. Of course, if you have different content types than our example site, you will see them on this screen. But remember, if a content type is disabled here, its events won’t be recorded (like deletion). Not all content types may be important for you to track. For example, if you're not actively using a particular content type, you might want to disable the logging of it to reduce unnecessary noise. Only track what’s necessary to balance performance and insight. For instance, in the image, just to name one, the tracking of the Layout Injection content type is disabled. This is because it’s a widget that is only used in one place, and it won’t be updated ever likely.Additionally turning on the Audit Trail feature will add a content part called Audit Trail part. This part as the description says: “Allows editors to enter a comment to be saved into the Audit Trail event when saving a content item.” If you add this part to the content type, you will see a new field for a comment, what you can use to add some explanation about the current content change. Staying with the news portal example, each time an editor revises, they can leave a comment in the audit trail explaining what was changed and why. For example, "I reworked the intro paragraph for clarity." This is all good, but how one can see the actual logs? Well, it’s pretty simple, now there is a new tab in the admin menu called Audit Trail. In this example, we had a page content type and audit trail turned on from the beginning. When I set up the site I created an admin user and I logged in. After that, I created a page content item, published it, and deleted it. You can restore deleted content items from the audit trail, so that’s what I did next. Then I renamed the title of the page. You can see all that from the logs: Returning to the example at the beginning:One day, an article titled "Breaking News: Major Policy Change Announced" was accidentally deleted.If the audit trail was turned on for that content type, now there is a solution! Go to the audit trail logs, you will see who deleted it and you can also restore it, correcting all the mistakes.For more audit trail features check out our open-source Orchard Core extension for the Audit Trail module: Lombiq Audit Trail Extensions. Did you like this post? It's part of our Orchard Core Nuggets series where we answer common Orchard questions, be it about user-facing features or developer-level issues. Check out the other posts for more such bite-sized Orchard Core tips and let us know if you have another question!