Microsoft Dynamics CRM Workflow Execution

Posted By
BDO

Avoid playing ‘Guess Who’ with Microsoft Dynamics CRM 2011 Workflow Execution

There are many instances, when dealing with workflows, where we want to leverage things like email templates and merge fields to make automatic messages look personal. Like they have been considerately hand crafted by an individual, for an individual – rather than having been created by a process designed to imitate personal interaction.

“Thank you for your email – someone will review your enquiry and get back to you soon”

Versus

“Thank you for contacting us {Mr} {O’Reilly} – I will personally look in to your enquiry and get back to you soon. Kind regards, {Benn} {Wood}”

I recently ran into a scenario, where loosely allowing a Workflow to “Run as…whoever” caused me problems. I didn’t require making use of the CRM user’s personal details to conditionally differentiate workflow behavior. Nor did I need to produce some form of personal output that needed me to consider just “Who” was running the process.

Let me rewind a bit to bring up what left me hitting a wall.

Field Level Security and Workflow Execution Permission

The Process:

One of my most favorite of the new features in Microsoft Dynamics CRM 2011 is the Field Level Security model. It was implemented on a custom Expense Claim entity, which provides the base in this example, which I am running workflows against.

A CRM user completes a claim form in CRM, listing multiple expense line items, and submits the form for approval. While the line items are being added, each are assessed against the clients rules as to whether the Expense form will require Approval, based upon the values or types being added to the claim. The “Expense Approval change” WF executes after each line entry or update and makes a change to a FLS field denoting the approval status of the Expense form.

 

 

 

When the User is done building out their claim – the “Submit Expense for approval” workflow would react to a user status field denoting submission for approval. This queues up the Expense for approval based on the User chosen readiness, and on the FLS field value as to whether approval is required or not.

 

The Problem

The problem then arose when a user wanted to change an Expense claim while awaiting or after receiving approval. Any change to the form cancelled any approved status – and regardless of the requirement for approval previously, would need to be reassessed due to the interruption. Estimates and Actuals, by thresholds – there is a lot more detail to the business logic than this blog post really needs to be overloaded with.

Workflow allowed me to set it to react to updates, but also be an On Demand workflow in the configuration screen:

 

 

 

 

 

 

 

This enabled the user to ad-hoc run the workflow to re-submit for approval – and hit permission problems.

“You do not have update permissions for the secured fields”

The error message in the Workflow execution screen was short and simple, but left me feeling (6ft) tall and simple. How could I have permission on other records, where the process succeeds, but not this one?

Gonzalo Ruiz had the answer : http://gonzaloruizcrm.blogspot.ca/2011/05/processesworkflow-ownership-faqs.html. I am very grateful for his post – thank you Gonzalo!

Automatically triggered workflows, when “Record fields change” for example, are executed as the security context of the CRM user that published the workflow. User triggered workflows, “As an on demand process”, are executed as the security context of the CRM User that clicks to run from the “Run Workflows” menu in CRM.

Back to my FLS model – as the system admin I had built an FLS audience for the Executive Approval field and as such, I was a member with full write access. The Auto triggered update ran as my service account and therefore could modify the FLS field.

The general CRM Users were not allowed to update the Approval status to illegitimately bump expenses through for payment.

This feature is by design and although my lack of awareness allowed it to kick me in the shins slightly – lesson learned, and I wholly agree with the design. If something is going to happen in my name – I approve it by making a workflow published to react automatically to conditions I agree with. If other people can decide when to shoot from the hip at the push of a button…then let their prints be on the trigger!

 

The Correction (Workaround)

Firstly, I added a field to the Expense form. Its sole purpose is to denote when an Expense is ready to be submitted for approval, as opposed to holding the summary approval status. As such, it’s a Boolean field in a hidden section so that only workflow can manipulate it – not manually by the users.

My Workflow to process for approval was removed from being callable On Demand:

 

 

 

 

 

 

 

I created another workflow, so the users could keep their “Submit for approval” button on the ribbon:

 

 

 

 

Now when the User runs the workflow, a field is updated on the record in their name.

My approval workflow runs due to the update and manages the details of the record based on all the previous rules, and calls child workflows which aren’t discussed here – all as the higher privileged context. The permission errors have left the building – and all is good with the Expense approval process.

I know, I know…I’m still pulling the trigger, at the request of the CRM User and going against my backing of “The Design”. That’s what we do as Consultants though right? All of the dirty work to keep our clients happy and squeaky clean  🙂

By Benn Wood, CRM Consultant, BDO Solutions

BDO eBook - The Cloud Changes the Game

There are times in the course of your business when you have the opportunity to dramatically accelerate growth and improve day-to-day efficiencies. Recognizing

Download