CRM 2013 New Features: Using Real-time Workflow for Validation 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:

image

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:

  image

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:

image

Note I have configured this as a real time workflow:

image

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

image

Here’s the conditions and actions:

image

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:

image

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: 

image

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:

image

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:

image 

I click through a couple of standard CRM warnings:

image

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

image

And my record remains:

image

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:

image

And I adjust the error message:

image

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:

image

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:

image

Clicking on that will reveal the error:

image

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.

Advertisements

10 thoughts on “CRM 2013 New Features: Using Real-time Workflow for Validation Rules

  1. Jukka Niiranen

    Cancelling the transaction really is a great new capability in the real-time workflows that hasn’t received too much attention yet. I’ve also blogged about how you could stop things like record merge with workflows in CRM 2013: http://niiranen.eu/crm/2013/11/using-real-time-workflows-to-show-error-messages/

    As an addition to the last example, since the Account Source field is a property of the same record, it might be a good idea to complement the workflow with a Business Rule that makes the account name field read-only in case it’s been integrated to another system. That way the users couldn’t even run into the Business Process Error message in the first place. If on the other hand this was a contact record we were dealing with and the value to check would be available only on the parent account, then real-time workflows would be the only no-code way to implement this, as Business Rules are still limited to only the current record’s attributes.

    Reply
  2. ukcrmguru

    Asynch workflows always run in the same context they used to: on-demand run as the the calling user; triggered run as owner of workflow. Only new real-time ones give you the option to choose the user context.

    Reply
  3. xrmdynamics

    Realtime workflows are brilliant. I’ve just created another link to an Opportunity from User as Previous Owner. You can use a realtime workflow to copy the current owner to previous owner before the record is assigned. even better the screen(form) updates almost immediately

    Reply
  4. BC

    I love the feature. But I don’t quite understand why they didn’t include an “On Save” option. IE: Validation that certain fields have values or checkboxes have been selected. Those scenarios are outside the scope of updates, so it’s a pretty big hole to me. I guess I still have to work with scripting to validate those items.

    Reply
  5. Pingback: Hello CRM World | Barry's Beginners' Blog

  6. Yogesh

    The problem with real time workflows – If your workfflow triggers on Assign, then Modified By is updated as SYSTEM instead of the current logged in user. Has anybody else experienced this? Seems like an issue to me.

    Reply
  7. Brian Bishop

    Having trouble with a realtime workflow based on the Connection entity (deletion). It won’t run… it is never triggered. If I convert it to a background workflow, the deletion event triggers the workflow. But that workaround isn’t working because (I think) two of the steps need to refer to the deleted Connection’s attributes. Thinking that the realtime workflow could run before deletion (triggered on deletion) and then it would have access to the soon-to-be-deleted Connection’s attributes. Thoughts? Here’s an image so you can see a little more info: http://postimg.org/image/smmg2rh2p/

    Reply
  8. Todd Zedak

    I have a run on demand workflow, owned by a System Admin level system account, set to run as the owner….. I can run the workflow just fine…. but others cannot. The error says that they don’t have permissions to edit the field. The field is locked, but system admins can edit it…. It appears that even though the Owner has the rights, and the user does not, and the owner of the workflow is System Admin, those rights are NOT being granted when the workflow runs… any thoughts? Am I “getting it”?

    Reply
  9. DC

    Hi Gareth
    Useful article, but can I suggest that you proof read it and update it as there are a couple of typos, one cosmetic and one misleading.

    The cosmetic one is “than the workflow” should be “then the workflow”.

    The misleading one is the statement “But with workflows not able to run synchronously” which should, I think, say “now”, not “not”.

    Finally, you might clarify “Note I have configured this as a real time workflow:” as “Note I have configured this as a real time workflow by not ticking the first checkbox below”.

    Cheers

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s