Just the other day, I received an inquiry from a colleague in regard to running Microsoft Dynamics CRM custom workflows against all the child records of an entity. The entity in question was the opportunity and its children, product records. Another example might be automatically flagging all the contacts underneath an account as “sign up for newsletter” or “do not bulk email”.
My colleague suggested a plugin. I immediately thought of actions. Why actions instead of a plugin? I wanted to use her logic without having to place the logic into a plugin. Utilizing the business logic created and adjusted by a Microsoft Dynamics CRM administrator would save time and money, when the user wants or needs a change.
But while actions can use the logic created by end users, it will not call the workflow for each opportunity product. I could create a plugin to fire a workflow on each opportunity product, but if the business logic (Fire on Opportunity Close) were to change, we’re still updating the plugin.
How about a custom workflow activity? A custom workflow activity is a step created and used within the workflow engine. I will not get into the detail of the code to create a custom workflow activity as examples may be found here.
I created a custom workflow activity with three inputs:
All input parameters are required and are “Child Entity Schema Name”, “Child Entity Parent Id Schema Name” and “Workflow to run”. As shown in the image the schema names are text fields while the “Workflow to run” is a lookup to all workflows. The schema names must match the defined names in the database.
These parameters will help keep the Workflow Activity independent of record types. The schema names text are used directly in the queryexpression to retrieve all the associated child records. The workflow is called with the ExecuteWorkflowRequest passing the workflow ID (guid) and the record id returned with the query expression.
Keeping the code as general as possible, we’ve allowed this custom workflow activity to be reused for any parent/child record association and process. This should allow administrators to create and customize their own business logic as needed.
For example, let’s say we wanted to make certain all the website URLs for each contact matches the parent company’s website URL when a change is made to the account website URL. Yes, I know the Website URL doesn’t often change, but it’s late and I’m watching the Cardinals lose to the Rockies.
Here are the steps for this scenario:
1. Create the contact update workflow. Set it as an on-demand workflow:
2. Save and activate the workflow. If the workflow isn’t activated, the custom workflow activity step will throw an error.
3. Create the workflow to run against the account entity. Add the Custom Workflow Step from the menu:
4. Insert the correct information in the Custom Workflow Activity parameters:
5. Save and activate the Account workflow:
When the workflow fires based on the trigger event (Update of Website URL) the associated contact records will be updated.
In this example, Test Account 1 has two associated contact records. Robert Smith and Bob Smithe. When I update the website URL of Test Account 1, the “Update Accounts Contacts when…” workflow fires and calls the Update Contact Record workflow for each associated contact record:
For this example and during the initial testing, I did not delete the workflows. I would suggest deleting the workflows on successful completion. Otherwise this could load up your database with system job records. This isn’t expected to be utilized on a massive scale but you could. This could run with any parent child relationship.
If you are interested in a customized solution like the one described above,
By Sanford Mosby,