Using Real-Time Workflows to Show Error Messages

In CRM 2013 we now have the option of setting a workflow to be run synchronously, also known as a real-time workflow. This opens up great new possibilities to leverage workflows in designing automated processes and providing immediate feedback to the end user when CRM data is created or updated. Having the workflow process executed in real-time also provides one additional capability that traditional, asynchronous workflows can’t handle: stopping the transaction from taking place.

Configuring Custom Error Messages

Similar to synchronous plug-ins, real-time workflows can present a Business Process Error dialog to the user when the operation being performed is breaking the rules of the configured business logic. As the real-time workflows execute in the current transaction, they have the power to roll back the changes that the user is trying to perform, whereas an asynchronous workflow could only observe what had already taken place.

How does this work in practice? Let’s explore the feature by setting up a very simple workflow rule to verify the owner of a record, in this case the Project Manager (owner) of a custom Project entity. When creating the workflow we’ve unchecked the “run this workflow in the background (recommended)” checkbox and thus defined it to run in real time. (If you forgot to do this, just reach for the “Convert to a real-time workflow” button on the toolbar, as the form checkbox can’t be edited directly). We’ll attach the workflow to the assign event of the entity.

In the workflow rule criteria we’ll perform a check that the Project Manager has the necessary qualifications for the job. If not, we will  stop the workflow and set its status to be Canceled. What’s new compared to CRM 2011 workflows is that we can set a Status Message for the workflow cancellation. Rather than just being a behind the scenes log entry, this text field’s contents will actually be presented to the user if the real-time workflow process is cancelled. This is therefore the place where you should provide instructions on why the cancellation took place and how the user can avoid it.

Let’s activate our workflow, go to an existing project record and attempt to assign it to a less competent CRM project manager, like Teppo:

After we click OK on the assign dialog, a Business Process Error dialog is presented, along with our status message text that explains why the operation cannot be allowed.

The transaction is rolled back, which means the assignment never takes place and our project remains in the hands of a certified professional. CRM workflows save the day!

Here’s a couple of considerations to keep in mind with the above example:

• If I had set the workflow to run Before the assign event, I wouldn’t have received an error. That’s because we would have had a pre-image of the record to work with, in which the change of ownership would not yet have taken place. Having these options available in the workflow editor UI gives more flexibility for defining the business logic, but you should know at least a bit about the underlying Dynamics CRM event execution pipeline to make the most of them.
• If I had simply clicked on the Project Manager (owner) lookup and changed the value, I wouldn’t have received an error in either case. That’s because from the platform’s perspective the assign event is different from the event of updating the owner lookup field. Also note that creating a new record for another user is not an assign event either, so you’ll want to expand the criteria of when the workflow rule is triggered to catch these.

Stopping Unwanted Data Updates

What kind of real life scenarios would then require the system to throw a Business Process Error at the user? Let’s think about a typical CRM implementation where the customer data is integrated with an ERP system. As long as you’re working with prospects that haven’t placed an order yet, there shouldn’t be too many limitations in place in CRM on how you can update the data. Once the account information is transferred to the ERP system for the purpose of order and invoice processing, the need for restricting certain operations on the account records will likely arise.

Let’s assume that we’re identifying the ERP integrated accounts through the Account Number field on the CRM account entity. If the field contains data, then this is a record where updates need to be restricted. By leveraging the new CRM 2013 Business Rules we can configure the fields on the form to be disabled if an account number exist. But what about updates that are not performed as changes of form field values? This is an area the Business Rules can’t touch, but with real-time workflows we may be able to add custom business logic into CRM that would have traditionally required a .NET developer to write plug-ins for us.

As an example, we’d like to ensure that no account records can be deactivated in CRM if they exist in the ERP system. The deactivation might take place through a data management operation like merging duplicate records, in which the master record is left in active status and the child record gets deactivated. We can’t directly trigger the workflow process from the clicking of the Merge button on the account view Command Bar, but we can set our business logic to be run on the status change event. Let us therefore build a new “Stop account merge” real-time workflow rule with the following criteria:

We’re actually performing this after the deactivation has already taken place, but that doesn’t matter, because we’ll still be able to cancel the whole operation. We’ll look for any accounts that have gone through a status change event and are now in an Inactive state. If the account record has an account number, we’ll stop the workflow with status of Canceled and provide a message to the user explaining what are the proper steps to take in getting everything updated correctly both in the CRM and ERP systems.

Let’s try this first on a single account record. When we click on the Deactivate button on the account form’s Command Bar, the Business Process Error dialog is presented to us, along with the message we defined in the workflow. No deactivation can take place, so the account is returned back to active status. More precisely, the account record status never changes, as can be verified from the audit history log (if enabled).

Great, now let’s move on to the Merge scenario and try to combine two active accounts with account numbers into a single account. We’ll select the accounts, click Merge, go through the Merge Records dialog, defy all the instructions given to us by the CRM key user of our organization and attempt to merge two separate ERP accounts in CRM. Once we hit the OK button for the merge to be performed, the Business Process Error dialog jumps to the rescue and stops the operation.

Hey, wait a second, why’s the text in the Business Process Error window different now? “ISV code aborted the operation”, what does that mean? Well, it seems that because we’re not actually performing the status change action directly on the record but rather leverage the built-in Merge Records dialog and its associated business logic for record deactivation, our status message text doesn’t  reach that screen. The event itself does “bubble up”, though, so stopping the status change also rolls back the entire transaction and none of the fields on the records being the targets of the merge operation change. That’s the important part, after all.

Complementing Business Rules

Let’s have a look at one more use case for the real-time workflow error messages before I let you get on with your browsing. The previous example covered an event that Business Rules weren’t able to control, due to the fact that they execute only on the entity form. In a CRM & ERP integration scenario you may however need to have the account record fields locked on more places than just the form. Remember that any updates the user would perform through other means, such as Excel export/re-import or a custom client app would not trigger the Business Rules that are essentially just client side scripts on the form. If you build this logic onto the server side as plug-ins or workflows, though, no one can perform an operation that would violate the rules (just ensure there’s always some supported way for performing the necessary updates & don’t block you integrations while creating these gatekeeper workflows).

One built-in form where the Business Rules don’t run is the mobile form. Utilized in both the Mobile Express browser version as well as the mobile apps for Windows Phone, iPhone and Android, these forms offer a limited set of capabilities for reading, creating and updating records. While you can set a field on the mobile forms to be read-only, you can’t build any conditional logic to determine when the field should be locked.

Let’s assume you want to allow people to quickly create and edit accounts through their mobile device, but you also want to lock down the account names on records that have been synchronized to the ERP system. To meet the first requirement you’ll need to leave the field on the form in an editable mode. To stop someone from accidentally overwriting the name of your biggest customer account with “Aasd,abhoignldfiiiiii” or other gibberish when fumbling around with CRM on their tiny little iPhone screens, you could create a real-time workflow to guard these fields from unwanted input. Have it run on the field change events, check whether it’s an ERP account with an account number and then cancel the event if necessary.

Opening up the Mobile Express UI (just append the CRM organization URL with /m/ to access this version) and trying to edit the account name field now gives the same kind of notification as the full browser client. The Business Process Error dialog window doesn’t seem to have any mobile optimized version, but again it gets the basic job done by stopping the update. I didn’t test this on the Dynamics CRM mobile apps, but seeing how at least on Android the app is almost identical to the Mobile Express browser version I’d imagine the experience is similar there as well.

OK, that’s the end of my experiments with real-time workflow process error messages for now. I’m sure that there will continue to be a need for more advanced solutions for controlling user data input that will involve hiding UI components through scripts or enforcing business logic through plug-ins, especially if the transaction volumes are expected to be high. The new workflow capabilities do however provide a quick way to configure custom error prompts and stop unwanted events when experimenting with the design options of your solutions and iterating your way towards the final production system.