The solution is to create and nurture a data centric company. This 14-page eBook will explain how your organization can harness the power of data by defining and following through on sound data-centric practices.
Using Real-Time Workflows for Data Validation
In this article we are going to explore how we can use a real-time workflow to enforce a CRM data restriction. If you have a situation where you would like to conditionally prevent certain types of updates, CRM’s Business Rules engine won’t quite get you there, and you’re not all that interested in developing a custom plugin assembly then this just might be the grease you need.
Adding a Cancel workflow action to a real-time workflow will cause that transaction to fail. In these situations the user will be presented with a custom error message of your choosing. Because a real-time workflow runs server-side it will be in play regardless of where the change is coming from. This may include from CRM forms, in bulk update, or through Outlook. All of this can be achieved without writing a single line of custom code.
Let’s get to the details…
To walk us through the setup for this we’re going to use an example scenario where we would like to not allow changes to the Account Name or Status in cases where that Account is considered a “Preferred Customer.”
To get started you’ll need to navigate to the Process module of CRM and create a new Workflow process. There are a few critical items to note when setting up a data validation style workflow as shown below:
- The workflow should target the entity where our data validation rules will be enforced.
- The workflow must be configured as a real-time (synchronous) workflow.
- Make sure to Scope your workflow appropriately.
- Organization scope will enforce our rules on all records.
- The workflow must be set to execute Before the changes are committed.
- Configure the events that will cause our data validation to run.
- For our example scenario we have enabled both status changes and when the Account Name is changed.
These settings will allow the workflow to intercept your changes before they are saved and decide if those changes should be allowed or rejected.
The second part of configuring your workflow will be to include the conditions that should be checked before the change is allowed. This may take some creative thinking as it relates to your specific implementation but you may well find the workflow engine robust enough to meet your needs.
For our example scenario we will disallow two types of updates to an Account.
- Do not allow changing an Account Name when the account is a “Preferred Customer”
- Do not allow changing the Status when the account is a “Preferred Customer”
As shown below, our workflow logic is setup according to these rules. The workflow will first check if the Account Category is set to “Preferred Customer.” In cases that it is, we will stop the workflow with a status of Canceled. This will cause an error to be shown to the user. You may add your own custom error message by setting the properties of the workflow cancel step. Once you’re satisfied with your conditional logic don’t forget to publish your workflow which makes it active and immediately available.
The User Experience
Now that our validation is in play let’s take a look at what our users should expect as they go about their day.
From the Account Form…
Attempting to change the Account Name or status of a Preferred Customer throws our custom error message:
What about Bulk Edit?
When you attempt to update a set of records which contains a mix of valid and invalid items (in our case, some are “Preferred Customers” and some are not) then all of the valid changes are made without incident while the invalid changes are rejected. In this scenario, a more generic error message is shown to the user indicating that only some of the records had failed.
So far so good, but what about from the Outlook Client?
The Outlook forms (and Outlook Bulk Edit) are going to behave the same as above with only minor cosmetic differences due to the different rendering engines. We see below our custom error message as it appears from an Outlook form.
Ok, but what about from the Outlook Client when you Go Offline?
Let’s not forget about our folks who occasionally take CRM data offline. In this case your validation will still hold strong but will not be presented to the user until they attempt to come back online at which time they will see the below error window and will be asked to fix their mistakes or trash their invalid updates.
Even on Tablets?
Yes, indeed, even from the tablet app we will be keeping our data clean. You’ll notice that in the tablet app our custom error message persists and is shown across the tablet screen.
We’ve done a very powerful thing here. With one simple workflow we have added a proper data validation rule to our solution… One that works regardless of how a user is trying to update data. It is worth emphasizing that we did not have to specifically write, test, and enable rules for the Web, for Outlook, for Bulk Edit, and for the Tablet individually to get coverage in all of these areas. Our workflow operates one level closer to the database and doesn’t care where the change came from. As with all things CRM this is just one more tool at your disposal. It will not always be the best option for enforcing your data rules but it should be a handy (and easy) one to keep in mind.