The Microsoft Dynamics CRM Team Blog
News and views from the Microsoft Dynamics CRM Team
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 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:
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!
PingBack from http://www.travel-hilarity.com/airline_travel/?p=5188
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).
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.
Very nice & useful post, thanks!
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!
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.
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.
Many Thanks, it is very useful
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 ...
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?
No dynamic options for setting picklist values between entities? You're kidding me, right?
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?
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.
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?
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.