Looking for PowerObjects? Don’t worry, you’re in the right place! We’ve been part of HCL for several years, and we’ve now taken the final step in our acquisition journey: moving our website to the HCL domain. Nothing else is changing – we are still fanatically focused on Microsoft Business Applications!

PowerObjects Blog 

for Microsoft Business Applications


Using Milestones in Dynamics CRM as a Field Change Tracker

Post Author: Joe D365 |

Sometimes users of Dynamics CRM want to track changes to selected fields in order to produce timeline reports intended for business analytics rather than forensic research. Milestones provide that functionality and in certain cases, may serve as helpers for the conditional processing of the data. In today's blog, we'll give you the foundation to get started with Milestones in CRM. Let's begin!

Does this dialog sound familiar?

Business Owner: We want to track any changes to a client's name.

Consultant: There is an Audit functionality in CRM. We can turn it on and record any change to any field of any entity.

Business Owner: Great! Can we have a report printed out showing all of the name changes?

Consultant: Well, you can see the report but you will not be able to print it or copy.

Business Owner: Why not?

Consultant: Because the Audit imposes certain restrictions on the report, disabling the possibility to modify it. When a report is printed or copied from CRM it may be modified which compromises the purpose of the Audit.

Business Owner: What can we do instead?

Consultant: We can build a child table that will store the history of this field. Then it will be possible to build any report you like.

Business Owner: All right, we want to track all fields on all of our entities!

Consultant: (Thinks to themselves.) Wait, they have about 50 business entities with 50 business fields in each. That means 2,500 extra entities. There must be a better way!

The ideal scenario here would be to have a generic entity which would collect change events from all configured entities and fields, just as an Audit would, but be available for reporting. Even better yet would be if it would have a relationship with the source entity.

So, what if we created this generic entity and had it instantly connected to all entities in the system when we choose for our new entity to be an Activity? Let's call it a "Milestone."

Milestones

Now, every entity that has the Activities flag turned on in the Collaboration section: will get related to our Milestones.

In essence, a Milestone is an activity, just a closed one. A chain of automatically closed Milestones will be our timeline where we can see what was changed on the entity, when and by whom. All we need to do is create a workflow that will fire on a tracked field change, create the Milestone activity, record the field name, record the new value (don't forget to fire this workflow on creation – to record the baseline value of the field), and close the activity. 

Implementation Details

To plugin or not to plugin? Some CRM engineers prefer extending workflows with custom activities while others deliver to the client a solution encapsulated into a plugin permitting minimal configuration and variability. One influencing factor we've seen is the ability to control the sequence of event processing. When plugins are bound to an entity, sometimes the results aren't as predictable with an interfering workflow that may depend on the changing values. In general, Milestones can be generated asynchronously, however, some CRM users want to see the Milestone report embedded into the entity form and updated in real-time. Every instance will be different.

The last step in the implementation is to create a configuration entity that will enlist all entities and the fields that require tracking. We can have a plugin that fires on any create and update message in CRM on any entity and field, however, only those that are configured will call a workflow generating a Milestone.

Further Development

Milestones can have a number of applications. Besides possibly replacing an audit, it can serve as a powerful driver for business processes. Imagine that instead of closing an activity automatically, it gets assigned to a user or added to a queue for further review of the change. Or what if instead of reviewing we want to have someone to sign-off on changes, thereby triggering further record processing down the business chain. Milestones can be used for those scenarios, too!

Rolling up changes in the related or child entities to the parent's Milestone log can also be extremely useful. Suppose a user self-manages addresses via the Portal. Instead of creating the snapshot of the old address or several Milestones on the address changes, they could just wrap the new address into a single text field and post it as a single client's Milestone.

Milestone activity implemented in CRM creates a new dimension of possibilities for businesses and can be presented as consultative suggestion when discussing your CRM needs. Now that you've digested today's blog, head over to PO TV to catch up on the latest CRM videos!

Happy CRM'ing!

Joe CRM
By Joe D365
Joe D365 is a Microsoft Dynamics 365 superhero who runs on pure Dynamics adrenaline. As the face of PowerObjects, Joe D365’s mission is to reveal innovative ways to use Dynamics 365 and bring the application to more businesses and organizations around the world.

One comment on “Using Milestones in Dynamics CRM as a Field Change Tracker”

  1. Fantastic Article . Exactly what I wanted as audit for Dynamics is not very flexible.

    Can you please expand on this ?
    "All we need to do is create a workflow that will fire on a tracked field change, create the Milestone activity, record the field name, record the new value (don’t forget to fire this workflow on creation – to record the baseline value of the field), and close the activity."

PowerObjects Recommends