Gareth Tucker: CRM 2013 New Features: Using Real-time Workflow for Validation Rules

[Blog bot]

Источник: http://garethtuckercrm.com/2013/12/0...idation-rules/
==============

Real-time workflows are a new feature in CRM 2013.  When I train on these the learning curve tends to be a gentle slope, the simple message is “you can now configure your workflows to run synchronously”.   Those 9 words comprise 90% of what you need to know.  That’s not to say this isn’t an awesome feature, its just easy to understand.   Here are a few other things you should know and cool new usage scenario that you should consider…

 

Execution Context

Workflows (both asynchronous and real-time types) can now execute either in the context of the User or in the context of the Owner of the Workflow:



If you define the workflow to execute as the owner of the workflow than the workflow can potentially perform actions the user does not have permission to – e.g. create certain records, or delete a record.   The workflow will have the permissions of the Owner of the workflow rule which you can set higher than the permissions of the end users.

If you define the workflow to execute in the context of the user then any records created or updated will reflect the user as the CreatedBy / ModifiedBy.

 

Validation Rules

I’ve had scenarios in the past where I have needed to perform a validation when a user attempts to update or delete a record.  If the record in question has certain properties I would need to reject the user action.  A common example is where you have external data that is synchronized with CRM and you need to prevent updates to those synchronized records, but not other records that are user-created – and these records reside in the same entity.

In CRM 2011 I either did this via JavaScript or a pre-update/pre-delete Plug-in.   A plug-in is more robust solution as it would fire regardless of how the update/delete was initiated.    No, we can do this via a real-time workflow!   Here’s how…

In my system I have Account records that are either user-created or created externally from CRM and synchronized with CRM via an integration.  I have an “Account Source” field which distinguishes between these two:

 

My users should be able to delete Accounts that are flagged as “User-entered” but not those flagged as “Integration”.   I can’t achieve this via the CRM Security Model as it does not support data-based access rules.   I need to grant my users delete permissions and then overwrite their delete attempts when I need to block that action.  I can do this with a Workflow process.

Here’s the properties of my Workflow rule:



Note I have configured this as a real time workflow:



And I am triggering the Workflow to run Before the record is deleted:



Here’s the conditions and actions:



A simple condition that checks the value of the Account Source field.  If the value is “Integration” then the proceeding Action fires.   The Action is to Stop the Workflow with a status of Canceled.   Stopping the Workflow has always been an available Action:



But with workflows not able to run synchronously we can use this feature to block the user action that triggered the Workflow in the first place.

When you add this Action to a Workflow there are 2 options to pick from.  You either stop the Workflow as Succeeded or as Canceled: 



We need to stop the Workflow as Canceled in this scenario as that will block the delete from completing.

Next to this dropdown box is a Set Properties button.  If you click that you can add an Exception message that will pop to the user to explain why you have blocked their action:



You can embed fields from the record or from related records just like you can when you are using workflow to create a record.   In my case I just include some static text. 

Here’s the workflow in action.   I select an Account with an Account Source value of “Integration” and click Delete:

 

I click through a couple of standard CRM warnings:



And then the workflow kicks in and throws the exception that I configured:



And my record remains:



Let’s look now and how this type of validation approach works in an Update scenario.   I tweak my workflow to run on Update instead:



And I adjust the error message:



Let’s test this out…

I set the workflow to fire when the Account name changes.   Let’s change that and a couple of other fields too:



</p> </p> </p> </p> </p> </p> </p> </p> And then wait for the auto-save to fire.   What you will see is a Business Process Error notification down in the Save section of the form:



Clicking on that will reveal the error:



Trying to force the save or navigating away from the record also results in the error popping.

The nice thing here is you don’t lose your changes when you hit this error.  You can’t save until you address the issue and none of the updated fields get updated.   But if I remove the change from the Account Name I can then save successfully and the other fields that I was also editing get updated successfully.

Hope this helps someone.




Источник: http://garethtuckercrm.com/2013/12/0...idation-rules/