Chapter 26. Process Development

With Microsoft Dynamics CRM 2016, organizations can define and implement business processes. These processes help employees focus on their work rather than do manual steps. Dynamics CRM 2016 has business process flows (BPFs), actions, workflows (asynchronous and synchronous), and dialogs. In addition, tasks flows are a preview feature available in Dynamics CRM 2016 Online only. Business process flows and real-time (synchronous) workflows are processes specifically designed to be used by people who are not developers. However, it is important to understand how and why to use each type of process.

Table 26.1 summarizes the various options available in actions, dialogs, and workflows.

The steps for creating any of these processes are similar. You start by going to Settings > Processes and clicking the New button. A new pop-up window opens, and in it you select one of the objects from the Category drop-down (see Figure 26.1).

You can save actions as a template and then use the template to create new actions. Developers can then invoke the actions via code, using a plug-in, JavaScript, or a custom button on the command bar. Actions can be imported and exported as part of a solution.

Basically, you can think of an action as a wrapper for multiple server-side operations. It boosts performance because instead of sending multiple requests for software development kit (SDK) operations, those calls are bundled into one action, and you need to send only one request to the server. In addition, consider the following:

Actions are called (run as) under security context of calling the user.

Actions are available through organization.svc or organization.svc/web endpoints.

Actions can be invoked using C# code or JavaScript. You cannot invoke actions using OData.

Actions are not supported with offline clients.

Wait and Parallel Wait Branch steps are not available in actions.

Actions support both input and output arguments.

Behind the scenes, the business logic in actions is implemented using a real-time workflow. When you create an action, it is automatically registered as a real-time workflow to execute at stage 30 (core operation) in the execution pipeline.

The following data types are supported for arguments (see Figure 26.2):

Boolean

DateTime

Decimal

Entity

EntityCollection

EntityReference

Float

Integer

Money

Picklist

String

You can specify whether an action is part of a database transaction or not. To do so, find the Enable Rollback check box, shown in Figure 26.2. If this is checked, the actions will be part of the main database transaction, and if there is an error, the whole transaction will roll back.

Actions are request and response classes that can be used in the Execute method of the CRM Organization service. You can generate these classes to use in your code by using the CrmSvcUtil.exe utility in the SDK, found under the Bin directory. To include request response classes for activated actions in that organization, you have to pass an additional parameter, /generateActions, at the end, as shown in Listing 26.1.

LISTING 26.1 Request Response Classes

Click here to view code image

CrmSvcUtil.exe /url:http://serverName/organizationName/XRMServices/2011/
Organization.svc
/out:outputFilename.cs /username:username /password:password /
domain:domainName
/namespace:outputNamespace /serviceContextName:serviceContextName
/generateActions

You can implement business logic depending on the number of days the case was open, and then it can be executed from within that case record. You can send email to a senior service manager, change priority, and assign the case to a queue in a single action named Escalate—and all these steps can be performed in a single process. In earlier versions of CRM, you implemented this sort of functionality using workflows.

1. Go to Settings > Processes and click the New button.

2. In the dialog that appears, enter Escalate as the process name and choose Action as the category and Case as the entity. Then click OK.

3. In the dialog that appears, set the Process Name field and the Unique Name field (used in invoking actions using SDK or JavaScript). Ensure that the Enable Rollback check box is selected. You can save actions as process templates, which you can use to create new actions, and you can keep the check box Keep Logs for Workflow Jobs That Encountered Any Errors checked.

4. Create an output argument of data type String, named Priority. Also create an argument for a user who is escalating the case. To do this, click the + icon to add a process argument, select EntityReference as the type, and select User as the entity for the EscalatedBy argument. Check the Required check box to make it a required field, as shown in Figure 26.3.

5. Enter business logic to check whether the case has been created before 30 days from the current date and then send an escalation email to the senior service manager from the user escalating the case. Figure 26.4 shows the escalation email, Figure 26.5 shows the case priority being changed to high, and Figure 26.6 assigns the case to the high-priority queue. Figure 26.7 sets the output variable Set Case Priority = High. Finally, if the case created is less than 15 days from the current date, send an email to the service manager, set the case to medium priority, assign the case to a medium-priority queue, and the set output variable Set Case Priority = Medium (see Figure 26.8).

6. Add a custom button named Escalate to the command bar of the Case entity and invoke the Escalate() function of the Action.js script when that button is clicked (see Figure 26.9).

The Escalate() function passes the current case ID and current user ID parameters to the EscalateRequest function. This method executes SOAP message to execute the new_Escalate actions. The action is executed, and in response, you have the priority value that you have assigned in the action business logic. You can parse the response by using the ShowResponse() function of Action.js and use it in an alert message to a customer care representative (see Listing 26.2 and Figure 26.10).

LISTING 26.2 Action.js

Click here to view code image

var requestXML = new XMLHttpRequest();
requestXML.onreadystatechange = ShowResponse;
function Escalate() {//function for the command bar
    var recordId = Xrm.Page.data.entity.getId().replace("{","").replace("}","");
    var userId = Xrm.Page.context.getUserId().replace("{", "").replace("}", "");
        EscalateRequest(userId, recordId);
}
function EscalateRequest(EscalatedById, CaseId) {


    var postUrl = Xrm.Page.context.getClientUrl() + "/XRMServices/2011/Organization
    .svc/web";//WebService Url
    var requestText = "";
    requestText += "<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/
    envelope/">";
    requestText += "    <s:Body>";
    requestText += "        <Execute xmlns="http://schemas.microsoft.com/xrm/2011/
    Contracts/Services"
xmlns:i="http://www.w3.org/2001/XMLSchema-instance">";
    requestText += "            <request  xmlns:a="http://schemas.microsoft.com/
    xrm/2011/Contracts">";
    requestText += "                <a:Parameters xmlns:c="http://schemas
    .datacontract.org/2004/07/System.Collections.Generic">";
    requestText += "                    <a:KeyValuePairOfstringanyType>"
    requestText += "                        <c:key>EscalatedBy</c:key>"
    requestText += "                        <c:value i:type="a:EntityReference">"
    requestText += "                            <a:Id>" + EscalatedById + "</a:Id>"
    requestText += "                            <a:LogicalName>systemuser
</a:LogicalName>"
    requestText += "                            <a:Name i:nil="true" />"
    requestText += "                         </c:value>"
    requestText += "                    </a:KeyValuePairOfstringanyType>"
    requestText += "                    <a:KeyValuePairOfstringanyType>"
    requestText += "                        <c:key>Target</c:key>"
    requestText += "                        <c:value i:type="a:EntityReference">"
    requestText += "                            <a:Id>" + CaseId + "</a:Id>"
    requestText += "                            <a:LogicalName>incident
</a:LogicalName>"
    requestText += "                            <a:Name i:nil="true" />"
    requestText += "                        </c:value>"
    requestText += "                    </a:KeyValuePairOfstringanyType>"
    requestText += "                </a:Parameters>"
    requestText += "                <a:RequestId i:nil="true" />"
    requestText += "                <a:RequestName>new_Escalate</a:RequestName>"
    requestText += "            </request>"
    requestText += "        </Execute>"
    requestText += "    </s:Body>"
    requestText += "</s:Envelope>"
    requestXML.open("POST", postUrl, true);//true is for async
    requestXML.setRequestHeader("Accept", "application/xml, text/xml, */*");
    requestXML.setRequestHeader("Content-Type", "text/xml; charset=utf-8");
    requestXML.setRequestHeader("SOAPAction", "http://schemas.microsoft.com/
xrm/2011/Contracts/Services/IOrganizationService/Execute");
    requestXML.send(requestText);
}
function ShowResponse() {
    var x = requestXML.responseXML.getElementsByTagName("a:KeyValuePairOfstringany
Type");
    for (i = 0; i < x.length; i++) {
        if (x[i].childNodes[0].textContent == "Priority") {
            alert("The case has been assigned to " + x[i].childNodes[1].textContent
+ " priority queue.");
        }
    }
}

7. Write plug-ins on pre- and post-stages of the Escalate message (see Listing 26.3). In some scenarios you need to do some data validation before the Escalate message executes, and you can write this business logic in a plug-in and register it on pre-operation of the Escalate message. The plug-in code should validate the business logic and abort the Escalate message if conditions are not met. When you register your plug-in, you see new_Escalate available under Messages.

You have to make sure the action is activated; otherwise, you will get a runtime error. The input parameters of the plug-in context should receive the input arguments defined, and post-operation should have both input and output arguments defined in the actions (see Figure 26.11).

LISTING 26.3 Plug-in Code

Click here to view code image

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.Xrm.Sdk;
namespace ActionsPlugin
{
    public class ActionsSample :IPlugin
    {
        string priority = string.Empty;
        public void Execute(IServiceProvider serviceProvider)
        {
            IPluginExecutionContext context =
(IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecution
Context));
            EntityReference caseRecord = context.InputParameters["Target"] as
EntityReference;
            EntityReference EscalatedBy = context.InputParameters["EscalatedBy"] as
EntityReference;
            priority = context.OutputParameters["Priority"].ToString();
        }
    }
}

For more information about registering and debugging plug-ins, SEE CHAPTER 25.

Account

Contact

Campaign

Case

Marketing List

Opportunity

The BPF guides users from various stages in sales, service, and other business processes from start to finish. BPFs have predefined stages, and each stage has steps. You can mark steps as required, but even if you do this, you cannot force users to complete that step before moving to the next stage. BPFs can be designed for a single entity, or they can span multiple entities. For example, you can start from a Lead entity and then move on to Opportunity, Account, Quote, Sales Order, Invoice, and then come back to Opportunity to close it as won. You can also have multiple process flows for a single entity. For example, you can have a process flow for low-priority cases and another one for high-priority cases.

Next, the Business Process Flow Designer screen opens. It is divided into three main parts: a command bar at top, a description area, and a process definition area. The process definition area is divided into stages, and each stage has Stage Name and Entity as mandatory fields (see Figure 26.13).

One entity is shown in the Business Process Flow Designer initially, and you cannot change the primary entity (the one selected on the previous screen). You can add other entities to the process in later stages, and the Business Process Flow Designer lists all the entities that have the BPF enabled for. The next step is to click Relationships to select the relationship between the entities; keep in mind that there can be multiple relationships between two entities. This way you can differentiate between them.

When you click the entity name, it is added to the process. You can delete a stage in the process by clicking the X button in the top-right corner of the stage. You can delete any stage in the process, but there is no way to delete the primary entity in the process. A multi-entity process can have a maximum of five entities.

If you have a process flow that moves from case to phone call to task, you might want to update the case record after the task. To do this, you can close the process cycle by selecting the Case entity under Close Process Cycle, and you cannot add any new entities after that.

You can click Insert Stage at the bottom of the Business Process Flow Designer (refer to Figure 26.13) to add a new stage in the process definition. You can select an entity in the process definition and add a stage for that and give them the following properties:

A stage will always be added at the end.

There can be a maximum of 30 stages per entity in a process.

If you have at least three stages, you can move stages up and down by using the arrow keys at the bottom of the Business Process Flow Designer. When you move a stage, all the child steps move along with it. You can select a stage by clicking it; when an X appears on the right side of the selected stage, you can click it to delete the selected stage. When a stage is deleted, its child steps and their labels are also deleted.

When you add a stage, you provide a name to that stage and select the stage category. This stage category is populated from a global option set named Stage Category, which you can customize to your requirements.

To enhance a business process flow with branching, you can create a BPF with multiple branches by using If-Else logic. To add the first branch for a stage, choose Add Branch below the stage and specify the If condition, as shown in Figure 26.14.

Click the + button under the branching rule to add another condition to the rule.

To add a second branch for the same stage, choose Add Branch again, below the same stage. The Else clause is displayed. You can choose Else to convert it to Else-If if you have more than two branches from the same stage or if you want to enter a branch only when certain conditions are satisfied.

The branching condition can be formed of multiple logical expressions that use a combination of AND or OR operators. The branch selection is done automatically, in real time, based on rules defined during the process definition. Each branch can be maximum of five levels deep. All peer branches should always merge to a single stage or must end the process.

A stage can have multiple steps, and whenever a new stage is added, a new step is also added. You can add a new step by clicking the + icon. When a step is added, it is added at the end of the selected stage. You can move steps up and down by using same arrow keys that you use for stages. You cannot move a step from one stage to another stage; if you want to do this, you have to delete the step from the stage and then add a new step to the other stage. You can have a maximum of 30 steps for each stage.

You can map a step to an attribute by clicking the text box under the Field column, and you can provide a step label of your own choice, or it will get copied from the selected Fields Display value. If your process requires some steps to complete any mandatory fields before moving to the next stage, you can select the Required column in front of that step. You can have multiple required steps in a stage.

BPFs can also be associated with security roles. Users who have the appropriate security roles can see or use them, and you can have multiple BPFs for an entity. All of them can be associated with a single security role.

In addition, you can set the order of BPFs for each entity. To do so, open a BPF and then click the Order Process Flow button on the command bar. The entity at the top of the dialog that appears will be set as the default (see Figure 26.15).

When a user creates a new record, the list of activated BPFs for that entity is compared with business processes for the security role of that user. The first activated BPF is set by default. Once the record is created, users can switch BPFs via the command bar.

A pop-up window opens after a user selects to switch BPFs from the command bar, with a list of active BPFs for that entity. You can select the process from there, and that process will be activated for that record.

Table 26.2 shows the main differences between dialogs and workflows.

To create a new dialog, follow these steps:

1. From the main interface, navigate to Settings > Processes and then click New.

2. Enter the name Customer Satisfaction Survey for the process. Select Account from the Entity drop-down. Then select Dialog from the Category drop-down (see Figure 26.16).

3. Click OK, and you see the Dialog Designer (see Figure 26.17).

The following sections explain some of the items in the Dialog Designer.

When you try to add a new input argument, you are alerted about the need to change the runtime to run as a child process if you didn’t do it before.

To create a welcome page, follow these steps:

1. Start a new workflow and click Add Step and Select Add Step Page. A red error icon appears.

2. Correct the error (shown with the red X icon) by clicking Add Step and selecting Prompt and Response (see Figure 26.19). After you add the prompt and response on the page, you will see also another red error icon.

3. As indicated by the error, complete the step by clicking Set Properties. Then you can enter the question, the response type, and the tip for the page.

4. Click Save and Close and add another page with another prompt and response step inside. On this page, set Response Type to Option Set (Radio Buttons), as shown in Figure 26.20. Fill out the other options as shown in Figure 26.20 to ask whether the client is very satisfied, a little satisfied, or not satisfied with your services.

5. Click Save and Close and add a check condition step, as shown in Figure 26.21.

6. To ask a different question of customers who are not satisfied, click the <Condition> (Click Here to Configure) link to validate the previous page’s response. It is recommended to use Response Value instead of Response Label because it is likely that you can change the labels but not the values of the option set.

7. Click Save and Close and add another page with another prompt and response step to ask why the customer is not satisfied. For this question, allow the user to enter a free-text description of the problem. You could add more questions with fixed options on a real process.

8. To record the selections to a field on the entity (even though you can see the user response on the dialog sessions, discussed later in this chapter), select the entire last step, click Add Step, and then click Update Record (see Figure 26.22).

9. Click Set Properties, and in the Description field under the Details section, set a dynamic value from the dissatisfaction response text (see Figure 26.23). You can update any field on the account form with values from the dialog session. This is an important piece to consider when using dialogs and processes: Because you’re updating the record, you can easily launch a workflow process on the field values set by the dialogs.

10. Click Save and Close to close the Update Account page, and click Save and Close to close the Dialog Designer.

The first screen shows the welcome text. Even though you didn’t add any questions on this page, the user can enter a comment here. You will be able to see the comments and the dialog responses in the Dialog Sessions link that is related to the record you are running in the dialog.

Click Next. You now see the customer survey question you configured; select this option and click Next.

On the next page, you see that the user can answer a question in a free-text form to explain why he or she is dissatisfied.

Click Next. The final page asks you for confirmation. If you are okay with all the dialog responses, click Finish. If not, you can move backward and then forward again and click Finish on the last page when you’re ready.

A workflow is an excellent tool for managing both data and processes. With workflow rules, you can easily ensure that certain steps are followed and that required business processes are executed.

In CRM 2016, workflows are divided into two categories:

Asynchronous workflows

Real-time (synchronous) workflows

Another consideration is that asynchronous workflows might not run immediately; depending on the server overhead, they might take some seconds or minutes to complete (or even start). If you need a process to run immediately, you should consider creating real-time workflows, which are executed synchronously, or plug-ins, which can be set to be executed synchronously. Another factor in favor of workflows is that they are treated as entities in CRM, so you can use the Advanced Find tool to look up workflows, and you can also create reports based on them.

Refer to CHAPTER 25 for detailed instructions about creating and using plug-ins.

By default, any valid CRM user can create processes; however, the permissions to create processes can be configured by roles to prevent users from creating new processes that might burden the system. The security privilege Activate Real-Time Processes is required to activate real-time processes, and Execute Workflow Job is required to start a workflow.

Refer to CHAPTER 17, “Settings,” for more information about setting permission levels.

Workflows can be started by the particular triggering events and run settings. These are the triggering events:

Record Is Created

Record Status Changes

Record Is Assigned

Record Fields Change

Record Is Deleted

These are the run settings:

Run This Workflow in the Background

As an On-Demand Process

As a Child Process

If you need to perform a series of steps that are common to other entities or to the organization, using a child workflow makes sense.

A good example of a child workflow is a child workflow created for the Contact entity that could be called from another workflow associated with the Contact entity, which would be fired when an account is created using the Primary Contact relationship. The same child workflow could also be fired from another workflow created for the Phone Call entity that would fire the related Regarding contact.

If neither As On-Demand nor As a Child Process is selected, the workflow still runs automatically if the triggering event is fired.

To create a new workflow, follow these steps:

To access the Workflow Manager, follow these steps:

1. From the main interface, navigate to Settings > Processes.

2. To create a new process of type Workflow, click New, and the Create Process dialog appears.

3. Enter a name for the new process, select an entity record type, select Workflow from the Category drop-down, select New Blank Process, and then click OK.

Now you are ready to start adding any of the following steps:

Stage

Check Condition

Wait Condition

Create Record

Update Record

Assign Record

Send Email

Start Child Workflow

Perform Action

Change Status

Stop Workflow

These steps are explained as:

Stage—Although stages are used for grouping purposes, they are also stored in the database. They enable you to report on the different stages and various stage metrics, such as the number of records affected for each stage. If you have a complex workflow with several steps in it, grouping steps makes the workflow easier to read and understand. You can collapse or expand the stages to fit the screen.

Check Condition—A check condition is a Boolean evaluation similar to the If-Then conditional in programming. A check condition can be either true or false.

Wait Condition—The wait condition can put a workflow to sleep until a condition changes, such as the property of the associated entity, or after a period of time has elapsed.

Create Record—Use this activity to create a new instance of any entity. The user can hard-code the properties or retrieve them from the associated entity.

Update Record—This activity updates an existing instance of an entity.

Assign Record—This activity assigns the associated entity to a user or a team.

Send Email—This activity sends an email by creating a new message or using a template. You can create a new email message or use a predefined template (which is recommended).

For additional information about how to create email templates, refer to CHAPTER 17.

Start Child Workflow—This activity calls a child workflow. As described earlier, a child workflow needs to be created with the As a Child Workflow setting.

Perform Action—This activity calls an action process, as explained earlier in this chapter, in actions. It asks you to select an action from list of available active actions and then select the entity. Then you need to provide values for input parameters, if any.

Change Status—This action changes the associated entity status. The status type varies by entity.

Stop Workflow—This action stops the execution of the current workflow. You can change the result status of the workflow from Succeed to Canceled. Use this activity step inside a conditional to prevent the workflow from continuing if a property doesn’t meet the criteria you expect.

While most of these are self-explanatory, the check condition can be a little tricky.

To add a check condition, follow these steps:

1. Click Add Step and select Check Condition.

2. Enter an optional description in the Type a Step Description Here box. The condition you’re going to add says that if the account is equal to some value, perform some action. To add this condition, click the <Condition> (Click to Configure) link (see Figure 26.29).

3. Select Account, Account Name, and Equals to enter a fixed-value condition in the Specify Workflow Condition dialog that appears.

For more information about working with the Specify Workflow Condition dialog, refer to CHAPTER 8, “Working with Marketing.”

4. To set a dynamic value, select an entity from the Entity drop-down and then click the desired field in the list box to set the condition.

5. Click Save and Close to continue.

6. Click Select This Row and then click Add Step. Then click Send Email.

7. Click Set Properties.

8. Enter a subject and body message for the new email (see Figure 26.30).

9. Click Save and Close.

When a workflow is activated, it is unavailable for further editing. To make additional modifications, you must deactivate the workflow, perform the changes, and reactivate the workflow.

When working with this screen, you have the option to select from the drop-downs at the top to filter the view. By default, they are set to All System Jobs and All Entities.

Note that the workflow engine is asynchronous and that the workflow might not be immediately trigged when an account is created. When the process finishes, the new email activity is created, and when you go to your activities, you can see the email in the email activities area.

Depending on your email router configurations, the email may be sent directly to the destination, or it may be queued as an activity (see Figure 26.32).

You have to change the drop-down to All Emails to see the email activities because they are not shown by default if your email router is configured to send the emails automatically.

For more details about setting up emails and about using the email router, refer to CHAPTER 20, “Email Configuration.”

Record Is Created—This event is triggered when a new record of the associated entity is created.

Record Status Changes—This event is triggered when a record of the associated entity status changes, such as when a record of an account is activated or deactivated, or when a record of an Opportunity entity’s status changes to Won.

Record Is Assigned—This event triggers when an instance of the associated entity is assigned to a user.

Record Fields Change—This event is very useful because you can use it to trigger a workflow when the selected field of a record from the associated entity changes.

Record Is Deleted—This event is triggered when a record of the associated entity is deleted.

Real-time workflows cancel and roll back the core platform operation if they are executing during database transaction and any exception is thrown. Plug-ins and workflows that were triggered by the same event and queued up after execution of the workflow don’t execute at all.

All activities and child workflows are part of a single transaction in real-time workflows. On the other hand, asynchronous child workflows are queued and execute in a separate transaction.

In the following steps, you’re going to create a real-time workflow with a business requirement that if business users change an opportunity stage, you need to update the probability. Whereas this would have been done using JavaScript in previous versions of CRM, you can do this using a real-time workflow in CRM 2016, as follows:

1. Go to Settings > Processes and click the New button. Select the category Workflow and uncheck the Run This Workflow in the Background (Recommended) check box. (If this check box is checked, the workflow will run as an asynchronous workflow.)

2. In the window that appears, define workflow properties, including the process name, and save the workflow as a template or process. Select whether you want this workflow to run as a child process or on-demand. Finally, opt to retain workflow logs for workflows that encounter any errors (see Figure 26.33).

3. In the Options for Automatic Processes section, define the scope of the workflow. You can select at what event this workflow should execute. As indicated previously, you cannot run real-time workflows before record creation or after record deletion; you can select Record Is Created and Record Is Deleted options, but you cannot change the start when the drop-down option is in front of them. For this example, select only Record Fields Change. Click Select Properties and select the Sales Stage option.

Notice that you can also select whether the workflow should run under either owner of workflow or user modifying the record context. In this example, select the user who made the changes to the record.

4. Put your business logic in the last section and update the Probability field on the opportunity record when the sales stage changes, as shown in Figure 26.34.

5. Click the Activate button on the command bar to activate this process.

6. To test the workflow, go to an opportunity record, change its process code, and save the record. The real-time workflow executes, and the probability changes according to the business logic defined in the workflow.

Users

Business Units

Parent: Child Business Units

Organization

These items are the various scope options that the workflow will apply to across the system. If you select User, the workflow will work for only the user who owns the workflow. If you want the workflow to work on the entire business unit or on the organizational level, you should select the appropriate option for that. Note that only the user who owns the workflow can see the tracking history.

Task flows operate at the user level. This means if two users are working on the same record and then both launch their task flows, the two users have separate experiences, working on different pages at same time. In a BPF there is only one active flow per record for all users, but in a task flow, different users can work on different task flows for the same record.

Task flows are not enabled by default. You have to enable them by following these steps:

1. Go to Settings > Administration and click System Settings.

2. Click the Preview tab and select the I’ve Read and Agree to the License Terms check box.

3. Select Yes for Enable Task Flows for Mobile Preview and click OK.

Microsoft provides three task flows out of the box:

Update Contact

Make Contact on Opportunity

After Meeting

You can use them as templates to create your own task flows, or you can create new ones from scratch.

Follow these steps to create a task flow:

1. Go to Settings > Processes and click New.

2. Enter a name for the task flow in the Process Name field.

3. Select Business Process Flow from the Category drop-down.

4. Select Run Process as a Task Flow (Mobile Only).

5. Select the type of entity from the drop-down list and click OK.

6. Click Details to expand the panel and then click Set Image to set an image to use as the task flow’s launch icon and background image. In the pop-up window, either upload a picture or select the default image and click OK.

7. In Business Process Flow (Classic), type a name for the page. For each field you want to display on the page, enter a label and select the source and field. Source can be Base Entity and all the lookup fields (N:1) for base entity record.

8. Click Insert Page to add another page to the task flow.

9. To add a branch in the task flow, click Add Branch, set the conditions for when you want the branch to appear, and click the checkmark. Then click Insert Page to add a page in the branch.

10. Set business rules for the task flow by clicking Business Rules and setting the scope to this specific task flow. (You cannot set the scope to be Entity.)

11. When you are done editing the task flow, click Save.

12. Click Activate to make your task flow available for use.

Click that icon, and you see the first page of your task flow (see Figure 26.36).

Click the Next button to go to the next page of your task flow. You can update data here and click the Done button to close the task flow or go back by using the Back button.

The task flow is enabled for the Manager, Vice President, CEO-Business Manager, System Administrator, and System Customizer security roles by default.

To learn more about how to create, export, and import solutions, refer to CHAPTER 22, “Customizing Entities.”

To start developing workflows with WWF, you must install the following components on a development machine:

.NET Framework 4.5.2

Visual Studio 2013/2015

The advantages of no-code workflows include the following:

Can be deployed without compiling

Easier to develop

Can be deployed on CRM On-Premises servers

Can share WWF activities if you add parallel tasks or Loop-While conditions

Before you can create a no-code workflow, you should first create the workflow with the CRM Workflow Designer interface, as explained earlier in this chapter, and then create a new solution, include the workflow in the solution, and then export it and extract the zip file.

To create a no-code workflow, follow these steps:

1. Open the solution file with Visual Studio 2015 and create a new project based on the Activity Library template (see Figure 26.37).

2. Add to the project references to Microsoft.Xrm.Sdk.dll and Microsoft.Xrm.Sdk.Workflow.dll. These files are located in the SDKBin folder.

3. Add to this project the existing XAML file you located in the unzipped solution file under the Workflow folder.

4. Add the CRM workflow controls to the toolbox by adding the Microsoft.Xrm.Sdk.Workflow.dll file. Right-click the General tab and click Choose Items. Then browse and add the file Microsoft.Xrm.Sdk.Workflow.dll, which is located in the SDKBin folder (see Figure 26.38).

After you export the solution, you can unzip the solution file and locate the XAML file, which is included inside the Workflow folder.

When you add the controls to the toolbox, you see a new group of activities that are specially designed to be used with CRM (see Figure 26.39).

The following sections describe how to build a workflow that will create a Phone Call activity for every new contact added to CRM.

To continue with the workflow development, follow these steps:

1. Add an Assign activity from the Primitives group in the toolbox before the CreateEntity activity.

2. Click the To property and enter CreatedEntities (“CreateStep1_localParameter”) (see Figure 26.40).

3. Click the Value property and enter New Entity (“phonecall”).

4. Add a SetEntityProperty activity after the Assign activity (see Figure 26.41).

5. Enter “subject” in the Attribute property, CreatedEntities (“CreateStep1_localParameter”) in the Entity property, “phonecall” in the EntityName property, and “Call this new Contact” in the Value property.

6. Click the last activity you added (the CreateEntity activity) and enter CreatedEntities (“CreateStep1_localParameter”) in the Entity property and “phonecall” in the EntityName property.

7. Click Save.

8. Copy the XAML file to the original solution you unzipped.

9. Compress the solution and import it back into the CRM 2016 web interface.

Unlike the no-code workflows illustrated previously in this chapter, custom workflow activities are compiled in dynamic link libraries (DLLs), and you can use them from the workflow interface found in either the web or Outlook client applications as new steps.

To create a custom workflow activity, you need to open Visual Studio 2013 or 2015 and create a new project, using the Class Library template that is inside the Visual C# > Windows Project Templates.

After you create the project, you must add the references for Microsoft.Xrm.Sdk.dll and Microsoft.Xrm.Sdk.Workflow.dll. You can find these files in the CRM 2016 SDKBin folder.

To use CRM entities’ classes in code, you use early-binding entities. You need to generate the CRM classes by using the CrmSvcUtil.exe tool (also in the SDKBin folder). If you run this utility on the server with the minimum parameters, as follows, you get an output file generated with all the classes needed on GeneratedCode.cs:

Click here to view code image

crmsvcutil.exe /url:http://localhost/Organization1/XRMServices/2011/
Organization.svc /out:GeneratedCode.cs

You need to include this file in your solution.

Next you are going to use sample code to repeat the same example you used for the no-code workflow but this time using a custom activity. You need to delete the Activity1.xaml file created by the Activity Library project template. Then create a new class file named CustomActivityLibrary.cs that contains the code shown in Listing 26.4.

LISTING 26.4 CustomActivityLibrary.cs

Click here to view code image

using System;
using System.Activities;
using Microsoft.Xrm.Sdk;
using Microsoft.Xrm.Sdk.Workflow;
namespace CustomActivityLibrary
{
    public class CustomActityLibrary : CodeActivity
    {
        [Input("My contact")]
        [ReferenceTarget("contact")]
        [Default("{575A8B41-F8D7-4DCE-B2EA-3FFDE936AB1B}", "contact")]
        public InArgument<EntityReference> inContact { get; set; }
        protected override void Execute(CodeActivityContext context)
        {
            // Get the tracing service
            ITracingService tracingService =
              context.GetExtension<ITracingService>();
            // Get the context service.
            IWorkflowContext mycontext =
               context.GetExtension<IWorkflowContext>();
            IOrganizationServiceFactory serviceFactory =
          context.GetExtension<IOrganizationServiceFactory>();
            // Use the context service to create an instance of CrmService.
            IOrganizationService crmService =
    serviceFactory.CreateOrganizationService(mycontext.UserId);
            // Get the Contact
            Contact myContact = new Contact();
            myContact.ContactId = inContact.Get(context).Id;
            // Creates the Phone Call activity for this contact
            PhoneCall myPhoneCall =
                new PhoneCall();
            myPhoneCall.Subject = "Call this new contact";
            myPhoneCall.RegardingObjectId = new
                  EntityReference(Contact.EntityLogicalName,
                 (Guid) myContact.ContactId);
            crmService.Create(myPhoneCall);
            tracingService.Trace("PhoneCall created.");
        }
    }
}

Build the solution in debug mode to create the assembly.

To deploy the custom workflow activities, you need to register the compiled assembly as a plug-in, using the Plug-in Registration Tool, which is explained in Chapter 25 and available in the SDKBin folder.

After deploying the custom workflow activity, you can use it on any workflow. To do this, go to Settings > Processes and click New. Enter a name for the process. In the Entity field, select Contact, and in the Category field, select Workflow. Click OK to move to the next step. Then click Add Step, and you see a new group called Custom Activities Library with the custom activity inside (see Figure 26.42).

Click Add Step, select the custom activity, and click Set Properties.

You can set any custom property you added on the code. This example uses the My Contact property used to send the current contact where the workflow will be running.

Click Save and Close to close the Set Custom Step Input Properties and then click Save to save the workflow. Click Activate to test this solution.

You can install custom workflow activities on CRM Online also—but in sandbox mode only.

Actions can solve some tricky problems by allowing the creation of custom fields (flags) that fire plug-ins from a command bar button. Previously, the only way to fire plug-in code was by creating a custom field that, when updated, would save the record and fire the plug-in attached to a Create or Update event.

In addition, actions allow you to move logic previously managed by JavaScript to plug-ins so that the intellectual property can be protected.

Task flows are the next big thing, allowing business users to create task flows as per their own requirements, with no developer required.

Process development is limitless; in fact, most organizations barely begin to scratch the surface with take process development. It is possible to use it for sales force automation tasks and for alerting of almost anything.