Use Workflow to Configure Business Data Auditing in Microsoft Dynamics CRM 4.0

Microsoft Dynamics CRM 4.0 has delivered a powerful workflow platform built on Windows Workflow Foundation. This workflow platform is highly configurable and means many processes can be built without the need to write a single line of code.

Auditing is a common requirement with business applications including CRM. This article will talk you through the basics of creating comprehensive auditing for your Microsoft Dynamics CRM 4.0 deployment. This example allows you to record changes to any field in your solution on any record. If you have simpler auditing requirements then consider just creating a work note on specific events within your CRM system. Either way, Microsoft Dynamics CRM 4.0 workflow is perfect for this requirement and easy to configure!

Essentially how this solution works is as follows:

- For each CRM entity we want to perform auditing on, we will create a linked custom entity to hold a snapshot of the record at the time a change is made to the CRM record. For example, if we wanted to conduct auditing on Contacts we would create an entity called Contact Audit. This entity will have all of the attributes of the Contact entity that we want to track via auditing.

  • We then design the form of our audit entity so that it has all the fields we want to set during an audit action and publish this form.
  • We will also edit the Associated view that shows in one line all of the attributes being audited.
  • We then build a workflow which runs on create as well as update of the specific attributes we are interested in auditing. This workflow will create a new audit record and set the attribute values to be the newly created or updated attributes from our parent record.
  • As each record is created or updated we get a snapshot of the record at that time and through the view we can see the full history of changes made to this record.
  • You could then build your own reports to print out audit logs and/or secure the audit records to prevent them from being updated or deleted.

We will work through these steps using a specific example to create an audit system for Contact records in Dynamics CRM. You can then use this technique for any record types that you want to audit.

Step 1: Create the custom audit entity as follows:


Step 2: Create the attributes of the Contact Audit entity.


Add as many attributes as you like but only add the attributes you want to create an audit copy of. If you don’t use yomifirstname then don’t create this attribute in your Contact Audit entity.

Step 3: Create an N:1 relationship between Contact and Contact Audit.


Set the relationship behavior setting to Referential, Restrict Delete so that if the record is deleted then the audit records won’t be.

Step 4: Design the form of the Contact Audit entity, ensure that all audit attributes appear on this form.


Step 5: Configure the Associated View of this Contact Audit entity to display all attributes you are interested in viewing in a list grid.


Step 6: Publish your schema changes.


Step 7: Set security on the Contact Audit entity in your security roles.


Step 8: Create a new workflow called Contact Business Data Auditing.


Ensure that you click the Record is created and the Record attributes change start events.

Step 9: Click the Select button next to the Record attributes change checkbox and tick every attribute that you want to track changes on.


Remember you don’t have to select every attribute, only the ones that you’re interested in auditing and you can always change your mind later and either include or exclude attributes from auditing.

Step 10: Add a create record step into the workflow. Select Contact Audit from the Create drop down list and then click the Set Properties button.


Step 11: Add a check condition step to the workflow. We will determine if this is a create or update transaction.


If the Created On date equals the Modified On date then this is a create transaction. If they are different then this must be an update. Click Save and Close.

Step 12: If this is a create transaction then we will add an Update Record workflow step and update the Name attribute to reflect that it is a create transaction.


Step 13: Add an Otherwise clause to handle the update transactions. We will add an Update Record workflow step and update the Name attribute to reflect that it is an update transaction.


Publish your workflow and you have enabled business data auditing on Contacts – repeat the entire process for any other entities that you want to conduct auditing on!

Other things you could do to enrich your auditing solution:

  • Create SQL Server Reporting services reports that display audit logs.
  • Add other events to your workflow which audit actions such as assign or delete.

As you can see Microsoft Dynamics CRM 4.0 workflow is very powerful! You can achieve a lot of things without needing .NET development skills. Hopefully this has given you insight into some of the great things you can achieve through workflow configuration!

Best wishes,

Reuben Krippner

Comments (16)

  1. Derek H says:

    Using a relationship of referential, restrict delete will not leave the audit records there when the contact is deleted, in fact, the contact will not be able to be deleted until your audit record(s) have been deleted, and assuming this is a proper audit, users will not have access to do that, having said that, my standard practice is not to allow users delete anyway (they can de-activate all they like, but delete, being physical is too risky).

  2. SDevlin says:

    Thank you for this idea, it is frequently asked for with MS CRM.

    Would the audit capture the data if the record is saved/changed the same day it was created?

    When training new users, I always train them to fill in the required fields, save and  then continue to fill out the remaining fields, saving when ever they have done a significant amount of work.

    Thank you.


  3. Reuben Krippner says:

    Thanks for your comments folks!

    Derek, thanks for pointing out the referential limitations – I agree that turning off delete privileges for users is a best practise, particularly around customer records.

    As far as the update question if the update is performed on the same day the answer is it will create this as an update record because the create and modified dates are held as date/timestamps so it will see that the 2 values are different and set it as an update audit.

    Thanks for the feedback, frequently I get comments around this that it is such a simple solution but one that many people don’t consider for workflows. Looking forward to sharing further tips with the field in future blog posts!

    Kind regards,


  4. Simon Jackson says:

    Hi Reuben,

    This is a nice example of workflow and I can see this approach working for some simple audit requirements.  

    However the process of change, ie adding/removing a field is likely to prove cumbersome.  For example, add a new field to the contact, also add it to the audit record. Update the workflow, remove existing workflow from the contacts and then re-apply the workflow to all existing contacts (please correct me if I’ve got this wrong).  There a few steps to remember and over time, IMHO something will get skipped in someone’s deployment.

    Any ideas of how an audit solution could be implemented that requires less administration, maybe a little more dynamic.

    Kind regards


  5. Scott@Develop1 says:

    Hi Reuben,

    This is a great demonstration of how flexible CRM 4.0 workflow is, but IMO there does seem to be quite a serious drawback with this audit approach compared to registering a plug-in. There does not seem to be a post image stored on the async events used by workflows, so if someone updates a record before the workflow for a previous update has had time to run then it will look as though the first user entered the values that the second user entered. I would assume that a similar case would happen when workflows are triggered due to events being played back when a user goes back on line after disconnected edits.



  6. mehul mehta says:

    Many Thanks, it is very useful

  7. One of the most frequently requested features for Microsoft Dynamics CRM deployments is the ability to audit changes to records. A good example of using the workflow capabilities of CRM 4.0 to se …

  8. Jacki says:

    Many thanks, this is very useful. However, I cannot seem to use this process to create audit logs of phone calls. Is there a workaround for this?

  9. John Thibodeau says:

    No dynamic options for setting picklist values between entities? You’re kidding me, right?

  10. Ian says:

    When tracking delete events the auditing record cannot be created as the primary record has already been deleted by the time the async process runs and execute the work flow. Do you know how to get around this?

  11. Ian says:

    This method is not possible on the address entity either, as you cannot retrieve the parent or the addresses id. Another MS CRM "gotcha", these are starting to pile up now, especially in CRM  online.

  12. Mark Allen says:

    HI again Reuben

    I attempted to configure this in a DEV environemnt, but I’m not able to get it to work.

    I think I’m missing something on step 10, where you have all of the highlighted fields in yellow.  did you populate those manually?  or were you able to click something on that form to populate them automatically?  



  13. Giovanni says:

    Is there a way to audit the sharing of entities? The users want to be able to know WHO shared WHAT to WHOM. A lot of questions I dont seem to be able to answer with simple workflows.

  14. John says:

    Just want to understand. For update, how does it view the old data being change in certain fields.

Skip to main content