Sitemap

Thursday, November 30, 2017

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
  1. Auditing is not supported on metadata changes, retrieve operations, export operations, or during authentication

  1. 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

  1. Non supported for auditing
Audit of read operations
Audit of metadata changes
Audit of text blobs, notes, and attachments

  1. 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.
  2. 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.
  3. 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.
  4. Audited data changes are stored in records of the audit entity.
  5. 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.
  6. Enabling or disabling of field level security by setting the IsSecured attribute cannot be audited
  7. For attribute auditing to take place, auditing must be enabled at the attribute, entity, and organization levels
  8. A user must be assigned the System Administrator or System Customizer role to enable or disable auditing
  9. 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
  10. 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






  1. 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


  1. 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.
  2. 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.
  3. 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
  4. 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.
  5. 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.

    1 comment:

    1. I am glad that I noticed this site , just the right information that I was looking for! . crm software hong kong, malaysia, singapore

      ReplyDelete