Audit in MS CRM

Below are the some of the interesting points about auditing:

Below are the some of the interesting points about auditing:

1. Auditing is supported on all custom and most customizable entities and attributes

2. Auditing is not supported on metadata changes, retrieve operations, export operations, or during authentication

3. Supported for auditing

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 Dynamics 365 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

4. Non supported for auditing

Audit of read operations

Audit of metadata changes

Audit of text blobs, notes, and attachments

5. 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.
6. For Microsoft Dynamics 365 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 365 web application. Partitions are not supported, and therefore, not used, on a Microsoft Dynamics 365 server that is running Microsoft SQL Server, Standard edition.
7. 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.
8. Audited data changes are stored in records of the audit entity.
9. Data 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 365 data, for how long, and from what client.
10. Enabling or disabling of field level security by setting the IsSecured attribute cannot be audited
11. For attribute auditing to take place, auditing must be enabled at the attribute, entity, and organization levels
12. A user must be assigned the System Administrator or System Customizer role to enable or disable auditing
13. 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
14. Fully Customizable entities:

Account	Campaign	CampaignActivity	CampaignResponse	Competitor	Connection
Contact	Contract	Email	Fax	Goal	Incident
Invoice	InvoiceDetail	Lead	Letter	List	Opportunity
OpportunityProduct	PhoneCall	Product	QueueItem	Quote	QuoteDetail
SalesLiterature	SalesOrder	SalesOrderDetail	ServiceAppointment	SystemUser	Task
Territory

15. Entities we cannnot audit:

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

16. If your Microsoft Dynamics 365 server uses Microsoft SQL Server standard edition, which does not support the database partitioning feature, the DeleteAuditDataRequest request deletes all audit records created up to the end date specified in the EndDate property.
17. If your Microsoft Dynamics 365 server uses an Enterprise edition of Microsoft SQL Server that does support partitioning, the DeleteAuditDataRequest request will delete all audit data in those partitions where the end date is before the date specified in the EndDate property. Any empty partitions are also deleted. However, neither the current (active) partition nor the audit records in that active partition can be deleted by using this request or any other request.
18. New partitions are automatically created by the Microsoft Dynamics 365 platform on a quarterly basis each year. This functionality is non-configurable and cannot be changed
19. Microsoft Dynamics 365 (online & on-premises) support the ability to audit user access. The information that is recorded includes when the user started accessing Microsoft Dynamics 365 and if access originated from the Microsoft Dynamics 365 web application, Dynamics 365 for Outlook, or SDK calls to the web services.
20. To enable or disable user access auditing, you must retrieve the target organization’s record, and update the Organization.IsUserAccessAuditEnabled attribute value for the organization. Global auditing on the organization must also be enabled by setting the Organization.IsAuditEnabled attribute to true in the organization record. To audit the origin of user access, for example: web application, Dynamics 365 for Outlook or SDK, you must enable auditing on the entities being accessed.