CRM 2013 Beta: Business Process Flows Part 3

The third part of this post is about extending the business process flow for a single entity, which was discussed in this post, to a multi-entity flow. If you are not sure what a business process flow is in Dynamics CRM 2013, take a look at another post here.


Note: CRM 2013 is not due to be released until October 2013. The information provided in this blog might different from the final product.

Often a business might have a process which spans multiple entities in CRM. For example, using the “Project” and “Statement Of Works” scenario covered in this post, there might be an additional requirement to create an email and send a completed statement of works to the customer, before closing down the SOW section of the project. This type of scenario is often referred to as a “close-loop” business flow.

We can update the previous flow diagram by adding two extra “stages” to the right


Building A Multi-Entity Business Process Flow

It is straight-forward to create a new stage that involves a different entity record than the original entity, here “Project”, that the business process flow was built on. One key thing to remember is that you can only add related entities (in this example, “Email” activity) of the primary entity (here “Project”) to the business process flow. This means that the related entity must have an existing relationship to the primary entity already built in Dynamics CRM. Hence if you would like to use business process flows to help an end-user for instance create an account and related contact, and to create sales literature for new products (where sales literature have no direct relationship with account and contact entities), it’s best to split the requirements up into two separate business process flows.

Going back to the “Project” business process flow described in the earlier post here, we first deactivate the flow, and add a new stage for “Email” by clicking on the “Options” button in the business process flow editor and select “Email (Regarding)” in the drop down.


Set the relevant steps in this “Email” stage to help the end-user complete the email activity.


To ensure the end-user goes back to the “Project” record after email is sent and completes the status of “SOW Submission”, we add another stage after “Email” to close the process flow. Do this by selecting the “Project” from the “Options” dropdown menu, and adding the relevant “Project” fields as steps for this stage. When finished, save the business process flow and activate it.



When we open a “Project” record, we see 2 extra stages called “Created Email” and “Submit Sow” not seen before (in the last post). The “lock” icon represents what Microsoft calls “Stage-gating” in a business process flow. Stage-gating essentially blocks a user from moving to work on the next entity in the process e.g. “Create Email” until all steps in the previous stages are completed. Notice I can click on the “Create Email” stage but I am unable to fill in any of the steps for this stage. The “flag” on the left hand corner of “Project Creation” step denotes I have not completed all of the fields in the “Project” entity yet.


When I have completed all steps in the first 5 stages for the “Project” entity and saved the record, the right hand “Next Stage” button will be activated to enable me to move onto the next stage “Create Email”. Clicking on “Create” will show a new email screen for me to complete the email in this stage.


Notice the “flag” icon is now at the “Create Email” stage signalling that the screen I am on is now the Email activity with several steps to complete. I can still navigate back to the previous 5 stages but I can’t edit the steps as they belong to the “Project” entity. (Not entirely sure if this is what Microsoft intended but at least that seems to be the behaviour in the Dynamics CRM 2013 beta release).


Overall, business process flow seems to be a nice functionality in CRM 2013 not seen in older releases. It allows a non-developer to create processes that guide an end-user through many common business tasks. It requires no coding and as long as the user building the business process flows has a clear understanding of how a business process maps to different fields of an entities and how it spans multiple entities in CRM, business process flows have the potential to become a powerful tool for the end-user.

That’s it for now. What are your experiences with business process flow so far?


3 thoughts on “CRM 2013 Beta: Business Process Flows Part 3

    1. Hi Weipeng,

      Thanks for your interest in Dynamics CRM 2013.

      Regarding your query I’d imagine javascript and business process flows can be combined in the usual ways – you write your javascript to trigger on form load or from save or attribute change as usual, while business process flow works as I outlined in the blog post. When you fill in a field that is included in a business process flow, the same field will be populated on the form. If you have javascript triggering onchange of this field, the javascript will fire.

      One thing to keep in mind is that both forms and business process flow can be configured to only show for certain “Security Roles”. If you have a form that is set to be shown for security role “A” and a business process flow to be shown for security role “B”, a user with only security role “A” might not see the business process flow on his form, however any javascript on that form will still work.

      Hope that helps.

      1. With regards to JavaScript, is there any code available so that the business process flow is automatically collapsed when the form loads?

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s