Business Process Flows

Business process flows define the guidelines for end users to perform their work. These guidelines are defined by the business. For instance, you might use a business process flow for a payment process or a member registration process where there are unique steps to perform the transaction. With business process flows, these user actions can be customized to give a different user experience based on each user’s role within the organization.

Business process flows are embodied as a custom entity, and when the user initiates a process, it is stored as a record within that entity. Each of these records is associated with the record it is processing. Business process flows can span more than one entity, and if you want to move the process flow from one entity to another with a related record, then there must be a 1:M relationship between the two entities. If no relationship exists between the entities, you can create a new record but not manipulate an existing record of the related child entity. Figure 4-1 illustrates the membership application process. When a new application comes in, the application details are entered, reviewed, and approved or rejected. In the event of approval, a new membership is created, and if rejected, an e-mail is generated with the reason for the rejection.

Let’s look how you can put this process into a business process flow. First, let’s create a new solution patch to hold the business process flows and include all the relevant entities and related components of the solution. In the left navigation pane, click Process, and click the New button of the Actions toolbar. In the Create Process dialog, fill in the required fields and set Category to Business Process Flow. See Figure 4-2.

After entering the required fields, you will be directed to the interactive business process flow designer. In the right pane of the design window, you can see the components required for designing the process flow. Simply drag and drop the required components and set the properties as required to configure the flow (see Figure 4-4).

Generally, when designing process flows, you will have to use stages, and inside each stage, you can define data fields to capture the information, as illustrated in Figure 4-5.

Also, you can configure conditions. In Figure 4-6, the condition checks whether the application stage is approved, and if approved, it will move to the next stage, which will create the membership record. On the right, you can enter the condition properties and combine multiple conditions as per the requirements.

As per the design, the membership will be created by triggering a workflow, which we will discuss in the next section. The workflow automatically picks up information from the prospect record and creates the membership record with the primary contact. If the application is rejected, another workflow will be triggered to generate an e-mail to the applicant informing them of the reason for rejection and the next steps (see Figure 4-7).

When calling a workflow from the stage, you can create the workflow by clicking the +New button in the right pane, or you can select a workflow that is already created. In any case, the workflow must be defined as an on-demand process, which we will be discussing in the next section. See Figure 4-8.

As you can see, you must set the Trigger property to either Stage Entry or Stage Exit, meaning that the workflow will be executed either when entering the stage or when exiting from it. Once the process is finalized, you must save and activate it from the toolbar on the top, as highlighted in Figure 4-9.

Once published, you can see the business process flow on the prospect record. See Figure 4-10.

Business process flows can be combined with other customizations, saving tons of user time and providing an end-to-end user experience. When the user is navigating through each stage of the flow, the data changes are applied to the fields so that any business logic or scripts wired up with fields can be triggered instantly. In your business process flows, there could be fields that are not presented in the entity forms, and these fields are added to the client object model to be used with scripts. If any of the fields is triggering a workflow, the changes will be visible as soon as the form is refreshed after a save. You can find out more about these at https://docs.microsoft.com/en-us/dynamics365/customer-engagement/customize/business-process-flows-overview .

Workflows

Workflows are useful in automating business processes that do not require any user interaction. When you create a workflow, it is associated with an entity. You can trigger the workflow when a record is created, a record status is changed, a record is assigned, a record field is changed, and a record is deleted. There are three options that can be used to determine how to execute the workflow: “Run as a background process (recommended)” will execute the workflow in the background, “As an on-demand process” is where the user can select one or more records and execute the workflow manually, and finally “Execute as a child process” means that it can be triggered from another workflow/parent workflow.

Let’s look at an example from the SBMA solution. In the SBMA solution, when a member applies for membership, the application will be created as a prospect, and the membership officer will review the information provided and accept or reject the application. This part of the process was implemented earlier in this Chapter as a business process flow. The workflow to create the membership and determine the membership category is done through the workflow.

If the application is accepted, then the workflow will trigger and create the membership record. The type of membership will be determined by the revenue of the member. At the end of the process, the workflow will trigger an e-mail to the member with the membership details. See Figure 4-11.

Let’s look at how to implement the workflow. In the solution, in the left navigation pane, click Process and click the New button in the Actions toolbar. The Create Process dialog will be displayed, and in this dialog, enter the process name, set the Process category to Workflow, and set the entity as Prospect. This is because the workflow will be triggered when the application status is set to Approved on the Prospect entity.

You must have this information before starting the implementation. For this example, you should know when the workflow should be executed, against which entity it should be triggered, and what the end result will be. If you can determine this information before starting any workflow implementation, then the implementation cycle will be extremely easy. See Figure 4-12.

After filling in the primary information in the Create Process dialog, click OK. Next you will see the pop-up to enter workflow properties. See Figure 4-13.

On this screen, you must make sure that you select “As an on-demand process” in the Available to Run section, making the workflow executed manually. As mentioned in the previous section, the workflow needs to be executed via a business process flow. The workflow will be implemented on this form, and you can add various steps and determine whether it is a before step or an after step.

To add steps to the workflow, click the Add Step drop-down in the workflow implementation area. A condition will be added to the panel. Click the “<condition> (click to configure)” link to open the condition configuration window. See Figure 4-14.

In the same way, you can add other steps, and there are many options available for you, as shown in Figure 4-15. You can create steps, update them, assign them, change their status, etc., with workflows. You can even call custom workflow activities, which we will be discussing in the next chapter.

One thing to keep in mind is that different types of steps will have different type of settings. For instance, the next step is to create the membership record, so you need to set the properties (i.e., set the fields of the membership record). See Figure 4-16.

Just as you did earlier, add the other steps. As shown in Figure 4-17, there are several steps added with check conditions. To add the “else-if” part of a condition, you simply click the check condition, click Add Step, and select the Conditional Branch option from the list.

Also, you can combine the condition of each check condition with AND and OR gates, as shown in Figure 4-18. Just click the drop-drop arrow next to the condition and click the Select Row option. Continue this process for the other conditions as well. Click the Group AND or Group OR option to combine the conditions.

Actions

Actions are another way of implementing business processes. Prior to actions, the most popular way of implementing custom business logic was using plugins or custom workflow activities. But with the introduction of actions, you can reduce the amount of code in the implementation significantly. Even power users can configure actions to implement business logic. Actions can be configured to accomplish create, update, delete, and perform action operations. When configured, internally actions create messages that are based on the actions performed against the entity record.

The nice thing about actions is that unlike workflows or plugins, an action does not have to be associated with an entity. That is, actions can be defined as global to be called on their own. When compared to workflows, another distinct fact about actions is that they do not trigger when a record is created or updated, a field is changed, etc. They can be called by workflows, plugins, or JavaScript web API calls. Also, you can call an action from an action step in business process flows. To do this, you should define the action as a business process flow action step.

Let’s look at creating an action coupled with the SMBA requirements. In their system, the event management module has a requirement to define event programs while creating the event. There are events that consist of one program, and there could be events where there is more than one program. Here you will be implementing an action that can be called through JavaScript when creating the event.

To begin with, in the left navigation pane of your solution, select Process and click New in the Actions toolbar. On this screen, provide the name and select Action as the category. For Entity, select Event Program. As mentioned earlier, you can define the action as a global action by setting the Entity drop-down to None (global). See Figure 4-19.

Next, you will be directed to a form that is similar to the workflow properties form that you looked at in the previous section. In this form, under Available to Run, check the “As a Business Process Flow action step” option to make it available for business process flows. The significant difference that you can see on this form is that you can define in and out arguments, as shown in Figure 4-20. To add new arguments, click the + sign in the Hide Process Arguments section. As per Figure 4-20, there are five input arguments and one output parameter. The output argument will return the event program created.

Next, you will learn how to define the steps. Similar to defining steps in workflows, you can easily define steps for the actions. The objective here is to create a new program and add the relevant step to create a new action step. See Figure 4-21.

For the Event Program entity, you have to map the input arguments to the fields of the Event Program entity. Click the Set Properties button, and the window shown in Figure 4-22 will display so you can set the properties. When mapping the arguments, you can find all the arguments defined from the Form Assistant in the Look For drop-down box. In this drop-down, scroll down to the Argument option, and the next drop-down will list all the arguments defined. Hit Save and Close to exit to the main window.

There is one more step, which is to return to the created program. Click Add Step and select the Assign Value option. See Figure 4-23.

Like setting the in arguments, click the Set Properties button to set the properties, as shown in Figure 4-24. Basically, you will have to select Event Program in the Form Editor.

Now that the action is completed, the next step is to consume the action created. Save the action, and you must activate it like the other process types discussed in this chapter. As mentioned earlier in this chapter, these actions can be consumed by workflows, JavaScript, and plugins, or by using Dynamics 365 web services. We will discuss how the actions can be consumed by JavaScript in Chapter 5.

Microsoft Flow

Microsoft Flow is a powerful and a robust platform that can be used to automate business processes across a variety of web-based services. You can develop flows that collaborate with SharePoint, OneDrive, Twitter, Google Drive, Dropbox, Salesforce, and many more. Similar to Dynamics 365 workflows, Microsoft Flow can be triggered from almost any Dynamics 365 event.

The flow designer can be accessed from Settings, as shown in Figure 4-25.

To create a flow, you could either use a template or start from scratch. When you open the flow designer and click +New, you will be directed to the screen to select the triggers and connectors. As shown in Figure 4-26, click “Search hundreds of connectors and triggers” at the bottom of the page.

You can now see the list of triggers and connectors, which opens a whole new domain of automating business processes. See Figure 4-27.

On the canvas, you can start adding components. The flow is triggered when an applicant record is created, and if you want to send an SMS to notify the membership officer, you can simply connect to the Twilio service and send the SMS. See Figure 4-28.

Please note that Twilio connectivity is associated with a cost. The standard pricing per SMS is $0.0075. Another scenario would be if a record is deleted and you want to archive the deleted records for later references, then you could use a flow, as shown in Figure 4-29.

As you can see, these types of tasks cannot be performed with Dynamics 365 classical workflows. The examples given are just two simple scenarios. You can extend them and add complexity based on the requirements. For further reading, please refer to https://docs.microsoft.com/en-us/flow/connection-dynamics365 .

Summary

This chapter discussed the out-of-the-box features available in Dynamics 365 for automating business processes. We have looked mainly into creating business process flows, workflows, and actions. Although dialogs are another means of implementing business processes, they were not covered in this chapter because they have been deprecated. In the next chapter, you will learn about writing plugins, custom workflows, and consuming actions.