Like
Share
ReportAuditing was added to CRM in version CRM 2011, it was a good move from Microsoft because this was a much requested feature and in CRM 4 it was mainly done using a auditing plugin.
Auditing is one of the straight forward features in Microsoft which does a good job of just working, doing what you need and rarely going wrong.
Auditing is set at various levels
Global settings – do you want to audit
Entity level – what entities do you want to audit
Field Level – what fields on the enabled entities to Audit
You can also audit users, when they log into CRM, when security roles are assigned to the user.
The auditing functionality can be found by going to
Settings – Auditing
Then you can click Global Audit settings
This allows you to start auditing, notice there is also a section for user auditing.
User auditing can be turned on or off, you can change what is audited.
Enabling auditing in the common areas is a way to turn auditing on for groups of entities and fields.
Once you have turned on auditing you can then choose to audit individual fields
Auditing Table
After you have enabled auditing all the auditing changes will be held in the audit tale in CRM Database. It will store the user who triggered the event, what type of event and the date of time.
Auditing Key Features:
Any entity can be audited
if auditing is not enabled at organisational level, it doesn’t matter if auditing is turned on at an entity level, nothing will be audited.
audit logs are partioned every 3 months. These can be deleted in the audit log management screen
User has to have the View Audit History privilege
when you turn on auditing for an entity, all the available fields are enabled for auditing
Some System fields are not applicable for auditing
- CreatedOn
- CreatedBy
- ModifiedOn
- ModifiedBy
- Owning Business Unit
- Owning User
- Customer AddressId
This page shows a good review of what can be audited
http://msdn.microsoft.com/en-us/library/gg309664.aspx
Supported for auditing
The following table lists what can be audited for Microsoft Dynamics CRM 2013 and Microsoft Dynamics CRM Online:
| Audit of customizable entities |
| Audit of custom entities |
| Configure entities for audit |
| Configure attributes for audit |
| Privilege-based audit trail viewing |
| Privilege-based audit summary viewing |
| Audit log deletion for a partitioned SQL database |
| Audit log deletion for a non-partitioned SQL database |
| Microsoft Dynamics CRM SDK programming support |
| Audit of record create, update, and delete operations |
| Audit of relationships (1:N, N:N) |
| Audit of audit events |
| Audit of user access |
| Adherence to regulatory standards |
Not supported for auditing
The following table lists what cannot be audited for Microsoft Dynamics CRM 2013 and Microsoft Dynamics CRM Online:
| Audit of read operations |
| Audit of metadata changes |
| Audit of text blobs, notes, and attachments |
Key concepts
The following bullets identify some key auditing concepts:
- You can enable or disable auditing at the organization, entity, and attribute levels. If auditing is not enabled at the organization level, auditing of entities and attributes, even if it is enabled, does not occur. By default, auditing is enabled on all auditable entity attributes, but is disabled at the entity and organization level.
- For Microsoft Dynamics CRM servers that use Microsoft SQL Server Enterprise editions, auditing data is recorded over time (quarterly) in partitions. A partition is called an audit log in the Microsoft Dynamics CRM Web application. Partitions are not supported, and therefore, not used, on a Microsoft Dynamics CRM 2011 server that is running Microsoft SQL Server Standard edition.
- The ability to retrieve and display the audit history is restricted to users who have certain security privileges: View Audit History, and View Audit Summary. There are also privileges specific to partitions: View Audit Partitions, and Delete Audit Partitions. See the specific message request documentation for information about the required privileges for each message.
- Audited data changes are stored in records of the audit entity.
Data that can be audited
The following list identifies the data and operations that can be audited:
- Create, update, and delete operations on records.
- Changes to the shared privileges of a record.
- N:N association or disassociation of records.
- Changes to security roles.
- Audit changes at the entity, attribute, and organization level. For example, enabling audit on an entity.
- Deletion of audit logs.
- When (date/time) a user accesses Microsoft Dynamics CRM data, for how long, and from what client.
Filed under: CRM 2011, CRM 2013, Hosk’s Microsoft Dynamic CRM Development, MB2-703
*This post is locked for comments