An exciting part of the Orion release is the concept of a Business Process Flow. A Business Process Flow (BPF) allows you to represent your business processes in CRM. In this post, we’ll look at using the designer to create your own business processes.
There are two places that you can invoke the designer from. You can navigate to Settings-> Processes and find all OOB and custom BPFs that are present in your org. You can filter the list using views, just as you do in other grids. The same grid is used to display workflows and other processes. The category column will tell you which one you’re looking at. You can click on an existing BPF or click new and select BPF as the category. Doing so invokes the designer, which you can then use to model your process.
The second place is directly from an entity form’s command bar. For example, you could navigate to Sales -> Lead -> <any record that has a process>. Click on the ellipsis at the top and then click on Edit Process.
Screenshot 1: New Process Dialog
When you create a new process, you’re greeted with a dialog as in Screenshot 1. Once you chose BPF as the category, and since BPF does not use templates, the radio button and grid at the bottom is disabled.
Screenshot 2: Designer with the new process
The designer screen is roughly divided in 3 parts – the commandbar and statusbar, the description area and the process definition area. The description area is collapsable to make more room for the definition of the process. Once you fill the description, the area auto-collapses on each load, until then it is expanded by default. A swift animation on load tells you that it is collapsed.
The included entities section displays a list of participating entities in this process. When you create a new BPF, there will be only one participating entity, viz., the one that you chose on the create new dialog. This entity cannot be changed or removed. You will have to create a new process if your primary entity needs to change.
You can divide a process in to stages and steps. A block representation is shown in diagram 1.
Diagram 1: BPF Entity, Stages and steps nesting
You can add a new entity to the existing process by clicking on options. You’re greeted with a flyout that looks like Screenshot 3.
Screenshot 3: Add remove entity flyout
The list of this entity is populated based on the relationships that the first entity has. If an entity is related to the first entity by an 1:N relationship and has the IsBusinessProcessEnabled flag set, it is included in this list. The text in brackets is the referencing attribute of the entity relationship. Since two entities can have multiple relationships, this provides a way to differentiate between them.
Clicking on the entity name will add this entity to the process and change the view to the newly added entity. You can go back to the first entity by clicking on the entity name in the Included Entities list.
To delete an entity, you can click on Options again and select DELETE LAST ENTITY. The last entity in the process will be deleted. Given the relationship requirements of participating entities in a process, only the last entity may be deleted. It is not possible to delete the primary entity or an entity that is not the last one.
At times, you may find the need to cycle back to an older entity to mark it as complete. For example, if your process begins with an account and proceeds to a lead and then to an opportunity, you can wish to go back to account and leave some notes about the entire process for the next time.
You can do this by invoking the add-remove entities flyout and clicking on the entity name in the CLOSE PROCESS CYCLE section at the bottom of the list. Once you close a process flow by doing this, more entities cannot be added to this process. It makes logical sense that a close loop entity should be the last one in the process. A process can be closed when there are at least 2 entities in the current process. The loop can also not end with the current last entity in the process. For example, if you have an Account - > Lead - > Opportunity process, Account and Lead can be used to close the process cycle. If your process consits of only Account and Lead, only Account may be eligible for closing the process cycle.
Adding, Removing and Moving Stages
The stages column header has an orange plus icon which allows you to add a new stage. The new stage automatically adds a new step in it. A new stage is always added at the bottom of the stage list for that particular entity. You can add stages to each participating entity by clicking on the entity name and then clicking on the plus icon for stages.
Stages can be moved by using the up and down arrow keys at the bottom of the designer, right above the status bar. You may also use up and down arrow keys. Moving a stage will cause all of it’s child steps to move along with it. Their properties, labels and associated data moves with them.
Stages can be selected by clicking on the chevrons on the left. You can delete a selected stage by clicking on the ‘X’ on the right of the stage row. You can also use the ctrl+Del shortcut to achieve the same result. When a stage is deleted, all associated steps and their labels are deleted. If you save after deleting a stage, the stage data is lost permanently.
There may be a maximum of 30 stages per process. Delete icon is shown when there is more than one stage in the current entity view. It follows than a process may not have an empty entity with no stages in it.
Each stage can have multiple steps. Each step corresponds to one and only one attribute or control of the particular entity in the current view. You can add a new step by clicking on the plus icon in the steps grid header column. A new step is added in the selected stage.
Just like stages, steps are also added at the bottom of the list. You can move them up or down using the same keys as stages. The same up and down arrow shortcut keys work here as well. Steps can be moved within the same stage. To move them to a different stage, you’ll have to delete it from the first stage and then add it to a new stage.
You can map a step to an attribute or control by clicking on the textbox in the fields column. An auto complete drop down is displayed when you do so. You may scroll and select a field or you can type in the textbox to filter the results as is shown in screenshot 4.
Screenshot 4: Auto complete for step fields
This list is populated from the attributes for the current entity. Note that not all attributes may be valid to participate in a process. Following is a list of attribute or attribute types that may not be part of the process:
This list may be updated in the future.
When you select a field, the field label is copied over to the step label if it hasn’t been changed. You may change it to any text that suits the scenario.
There may be a scenario in your process that requires users to perform a given task before proceeding to a new one. For example, requiring approval of a manager before proceeding to the next stage. This can be achieved in BPF by marking a given step as required. Click on the empty square in the required column to mark a step as such. This will cause users to not proceed to the next stage until this step has been completed (there is some value in the field). You can mark multiple steps within a stage as required. To proceed, a user has to finish all the steps within that stage.
By triggering a workflow tied to a field in a process, complex tasks such as creating an approval request can be achieved. You can set permissions such that a particular field can only be changed by a certain group of people. If you mark this step as required, a user cannot proceed to the next stage without someone from this special group doing it for them.
A number of operations are possible that affect the state of the current process. Depending on user permissions, these are visible in the commandbar at the top. Save (ctrl+S), Save As, Delete and Activate behave like you’d expect with a couple of different notable behaviors.
A user cannot save a process that is ‘incomplete’. If your process has steps that do not have a field, an error is shown. If there are multiple such cases, they are marked with a red X icon next to their field names. So that you don’t have to search for all such instances, when you save a process, the view will scroll to show you the first such instance.
Save as creates as exact replica of the current process. ‘- Copy’ is added to the new process name, which can be changed by the user. Note that updating either of the process does not automatically update the other.
Activating a process without saving will cause the save logic to be triggered first. After a process is marked active, it participates in the process selection algorithm for when new records are created. A process in the draft state will not be rendered on any record form. It is also not possible to delete a process that is active. To delete it, the process should first be deactivated.
The order in which a process is preferred over another can be set using the Order Process Flow dialog, which can be invoked from the command bar. The logic here is similar to the form ordering logic that exists currently in CRM.
Besides ordering, an administrator can control who has access to a particular process by setting the relevant permissions by using the Security Roles dialog. When a new BPF is created, only the System Administrator and System Customizer roles have access. Before activating, it is recommended that you visit the security roles and select the right security roles for your need.
As with everything in CRM, it is possible to localize the text used in the process. Stage names, step names and description may be localized. Look for information about this and solution import-export in a separate blog post.
For End Users:
For Customizers (Customization Guide):
For Developers (SDK):
Aniket Naravanekar | Software Development Engineer | firstname.lastname@example.org