Configure entities and attributes for auditing
There are three levels where auditing can be configured: organization, entity, and attribute. The organization level is the highest level, followed by the entity level, and finally the attribute level. For attribute auditing to take place, auditing must be enabled at the attribute, entity, and organization levels. For entity auditing to take place, auditing must be enabled at the entity and organization levels.
There is a slight difference in how auditing is enabled or disable for an organization compared to an entity or attribute. You enable or disable auditing at the organization level by setting a particular attribute value of the organization record. However, for entities and attributes, you set a property value of the entity or attribute metadata.
A user must be assigned the System Administrator or System Customizer role to enable or disable auditing.
Enabling auditing
By setting the IsAuditEnabled property of an entity’s metadata and the IsAuditEnabled property of each desired attribute’s metadata to true, data changes to records of those entities can be logged by the platform. However, when enabling auditing on an entity, all of the entity’s attributes are enabled for auditing by default. Of course you can explicitly disable auditing on any or all of the attributes as needed. The IsAuditEnabled property can be set when entity or attribute metadata is created or updated through the following requests: CreateEntityRequest, UpdateEntityRequest, CreateAttributeRequest, UpdateAttributeRequest.
After changing the entity attribute metadata, you must publish the entity by using PublishXmlRequest. Changing the IsAuditEnabled property at the entity level does not require publishing. Typically, customization and publishing is performed by the same user. However, if these tasks are performed by different users, auditing will record the publish action, the user that initiated the publish operation, and not the update action.
In addition, auditing is enabled at the organization level by setting the IsAuditEnabled attribute value of the target organization record to true.
Disabling auditing
To disable auditing, just set IsAuditEnabled, as described previously, to false. Publish the entity customizations if you have disabled auditing on any attributes. You can disable auditing for a whole organization by setting the IsAuditEnabled attribute to false in the target organization’s record.
Entities that can be audited
All custom and most customizable entities can be audited. For a list of customizable entities, see Which Entities are Customizable?.
The following table lists the non-customizable entities that cannot be audited. This table was obtained by testing for a CanModifyAuditSettings attribute value of false on each entity’s metadata.
- ActivityPointer
- Annotation
- BulkOperation
- Calendar
- CalendarRule
- CustomerOpportunityRole
- Discount
- DiscountType
- IncidentResolution
- KbArticle
- KbArticleComment
- KbArticleTemplate
- Notification
- OpportunityClose
- OrderClose
- ProductPriceLevel
- QuoteClose
- RecurrenceRule
- Resource
- ResourceGroup
- ResourceGroupExpansion
- ResourceSpec
- SalesLiteratureItem
- SalesProcessInstance
- Service
- Subject
- Template
- UoM
- UoMSchedule
- Workflow
- WorkflowLog
See also
Data Management in Dynamics 365 Customer Engagement (on-premises)
Audit entity data changes
Retrieve and delete the history of audited data changes
Sample: Audit Entity Data Changes
Auditing Data Changes in Dynamics 365 Customer Engagement (on-premises)