A macros system for Dynamics CRM - part one
Workflows in Dynamics CRM can do a lot, but a significant limitation is that they're asynchronous. If you need to automate server-side code execution and interact with the user at the same time, you're out of luck. This is where you can use something that I call a macros system.This is the first of a three-post series in which I will:
- outline a business problem that a macros system can solve
- give an overview of the structure of our CRM macros system
- share some sample code for how to implement a basic set of macros for a CRM business entity.
The problem
My company manages insurance policies in CRM. An account (in our system, what we call "account" is a custom entity, but that's not important right now) has one or more policies. A simplified representation of a policy would have the following attributes:
- account
- carrier
- policy number
- premium $
- commission $
- effective date
- renewal date
- status reason - active/terminated/expired/etc.
- status date
- owner
As part of the normal policy life-cycle, an agent will attempt to renew an active policy prior to its renewal date. If a policy renews, it should have its status reason set to "expired," and a new policy record will be created that's a clone of the expired policy, except the effective date and renewal date will each be advanced by one year, and the premium and commission fields will be blank. The agent should then immediately supply the new premium and commission values.
The workflow solution
If we attempted to automate this solution with workflows the user would:
- Select the correct policy status reason.
- Save and close the policy record.
- Wait for a workflow to execute to:
- clone the original policy record with a plugin and advance the dates accordingly
- update the original policy record
- Manually refresh the list of policies associated with an account to see the new one.
- Open the new policy record and update the premium and commission values.
This approach would meet our needs at a basic level, but there's a lot of clicking required, and the asynchronous policy creation disrupts the process flow. Another potential problem is that changing the process requires unpublishing the workflow, modifying it and then publishing it again.
The macros solution
Whenever I'm talk about process automation with our users and we're trying to determine whether we should use a workflow or a macro, I explain macros as "allowing you to click one thing and have a whole bunch of other things happen."
Our policy form in CRM has a macros tab with that loads a page from another an intranet website via an iframe. This page displays a list of hyperlinks, and each hyperlink calls a specific macros. The renew policy macro does the following:
- updates the original policy using the CRM Web services
- creates the new policy using the CRM Web services
- closes the original policy form
- opens the new policy form for the user to complete the missing fields
This approach has three advantages over the workflow method:
- Only one click was required to get the agent to the point to complete the new policy record.
- The agent doesn't have to go looking for the new policy record.
- Updating the process, which happens more often than I'd like, can be done during business hours by pushing out an updated macros website instead of unpublishing/modifying/republishing a workflow.
The main disadvantage of the macros approach is that it requires someone who can write custom code, unlike workflows that can be created by relatively non-technical users.
In the next two parts of this series, I'll go into more detail on the structure of the macros system and show some sample code that enables the basic functionality.