I had a problem at a customer last week where a workflow wasn't triggering after I set the trigger field with a script. Very annoying troubleshooting of that one which lead to trying to set the field in pre execution plugin, post execution plugin and changing the field manually. Finally I found that the plugin was the culprit.
To begin with, it's not my code to begin with, and I'm not saying that to put blame on anyone more that I didn't fully see what was happeing. The problem looks as follows. There's a button in the ribbon of a CRM 2011 implementation that will create a printout and that button changes two fields, a optionset and a bool field. This is done in a plugin which reads the optionset and acts on the input value, then resets the optionset by doing a post execution update of the object with the optionset nulled.
Originally the workflow was triggering and checking the state of the optionset, however that field is changed in the entity plugin before the workflow is reading it so the logic didn't work. I chose to add the bool field and change that with the same script, now when I was looking in the audit the field obviously changed but the workflow didn't trigger.
Right, I toggled the bool field manually, which showed in the audit log, and this triggered the workflow. That bit did not do miracles to my mental healt I might add, but it got worse.
Next step in my troubleshooting was to add the bool field to the pre execution state plugin, that didn't help either so I did a final shot at doing it in the same step that was nulling the optionset and then updating the object,
Now the workflow was triggered, twice (back to mental health issues). At this time my colleague and boss Gustaf was back from vacation and we started talking about this. His advise was to turn off the plugins and see what happened, this did indeed work for the workflow triggering so now we had the culprit under the glass.
The code that did the nulling of the optionset looked something like this: which
target[optionset] = null;
which I changed to
Entity ent = new Entity(target.logicalname);
ent.Id = target.Id;
ent[optionset] = null;
this helped with the workflow triggering but I didn't like to save the object twice so I reworked it and reset the optionset in the pre execution step and moved the value that was interesting to the shared variables instead.
Now to the fun and games with workflows part. Can this be used? It might, but I'm not entirely sure of the application.
I had to try this at home with a very simple plugin, I had done some setting up of a entity in our lab environment to see if there was a problem with changing field with scripts to trigger workflows, it wasn't.
I set up a workflow triggering on a bool field
I had the following code that I played around with a bit, this is the final incarnation.
public void Execute(IServiceProvider serviceProvider)
if (context.InputParameters.Contains("Target") && context.InputParameters["Target"] is Entity)
Entity entity = (Entity)context.InputParameters["Target"];
if (context.Stage == 20)
else if (context.Stage == 40)
private void RunPre(Entity entity, IOrganizationService service)
private void RunPost(Entity entity, IOrganizationService service)
With this code I reproduced the behaviour that the workflow isn't
triggered, triggered once and triggered twice with the update of the
bool field "crmk_testar_chkb". The rationale being the
"entity.Attributes.Clear()" totally blocking the workflow, if clearing
the attributes and then adding the field again giving one workflow
triggered. Updaging the object with the field in the attributes giving
Finally, when you're adding the field to the post execution step property bag funny stuff happens. The workflow gets triggered without any field change being entered into the database.
As you can see in the audits of 9.45 pm and onward, only the string field testar_strng is updated.
And here are the workflows triggered. The 9.45 one is triggered from a bool toggle at 9.45 in the audit but the following three are triggered by adding the field to the property bag in the post execution step plugin.
This may not be any news for some of you out there that know youre plugin execution pipeline chart on your five fingers, but it's not something I have run into earlier.
I have been thinking about if this is something that might be useful in some situation, I haven't found one yet since you probably can trigger the workflow anyway, byt there might be times when it's useful. It's also good to know that emptying the property bag will stop your workflows from triggering since that is done in the post execution step.
NB, this is verified in CRM 2011, but will probably behave the same in 2013.
Developer at CRM-Konsulterna