Installing the solution

Import the managed solution just like any other CRM solution. You need to make sure that the user importing the solution has the Deployment Administrator privilege (which you can grant via the Deployment Manager) and the System Administrator role. (Thanks to maatthias for pointing this out)

 

CRM Online Update: This solution is now available for CRM Online. Make sure you use version 2.0.2.0 or newer and download the solution file marked as Sandboxed for CRM Online.

 

 

Adding a custom step in a process

The custom workflow activities included in this project can be used in either dialogs or workflows and work with CRM OnPremises and CRM Online.

 

image

 

 

Delete primary entity:

If you want your process to delete the primary entity of the workflow you must select True for the first argument. The second argument will be ignored.

 

Delete related entity:

You can delete related entities if you specify False to the first argument. You will then need to provide the attribute that links the related entity. For example, if the workflow is defined on account, and you want the workflow to delete the parent account (instead of the primary entity) you provide the "parentaccountid" as the linking attribute in the step configuration:

 

Share Step:

A share step is used in order to share the primary entity of the workflow (or a related entity) with a user or team. You must specify which record you want to share (primary vs. related) and who you want to share the record with (user and/or team). Note that you can specify both a user and a team, in which case the record will be shared with both. When sharing a record, all the privileges that are available will be shared. For example, if the workflow user has create, update and assign privileges on the record, it will share all of them.

 

Share primary entity:

The following example shares the primary record with another user:

 

Share related entity:

The following example is for a workflow whose primary entity is account. This configuration will share the primary contact of the account with the account owner and the test team:

 

Sharing specific Privileges

When you insert a Share step, you have the option to select which privileges you want to share. These are the possible selections:

image

*Automatic workflows execute in the context of the workflow owner whereas on-demand workflows execute in the context of the user who executes the workflow on demand. More details here.

 

Unshare Step:

An unshare step is used in order to “unshare” or revoke shared privileges to the primary entity of the workflow (or a related entity) with a user or team. You must specify which record you want to unshare (primary vs. related). You can specify who you want to unshare the record with (user and/or team). Note that you can specify both a user and a team, in which case the record will be unshared with both. If you don’t specify any user/team then the record will be unshared with everyone with whom the record is currently shared. The configuration (input parameters) of the “unshare” step are similar to the share step (read above).

 

Create Hyperlink to CRM record:

You can create hyperlinks to the primary entity of the process or the related entities (N:1 relationships). You must specify the following properties in the step configuration:

Using the hyperlink in a dialog:

The custom workflow step has 2 outputs: The hyperlink generated for dialogs and the hyperlink generated for HTML fields. Make sure you select the "DialogHyperLink" output when using it in a dialog.

 

Using the hyperlink in an e-mail.

The custom workflow step has 2 outputs: The hyperlink generated for dialogs and the hyperlink generated for HTML fields. Make sure you select the "HtmlHyperLink" output when using it in an e-mail body or any other HTML field.

 

 

Qualify a lead:

When you insert the “Qualify” step in your process, you will be asked to select whether you want to qualify your lead to a contact, opportunity or account. You can select any combination of the three. If you are qualifying to an opportunity you must also provide the customer and currency for the opportunity.

qualifyStep

Once the lead has been qualified, the resulting entities can be used at a later step. For example, if you qualify your lead to an opportunity, you can insert an “update” step after to update the opportunity that was created by the “qualify” step:

qualifyStep2

 

 

Bulk Activate / Deactivate:

You can use this workflow step to bulk activate or de-activate multiple records in CRM (no record count limit). Insert the “Bulk Activate/Deactivate” step to your workflow. You will see the following options to configure:

image

The first parameter is used to define the query that defines which records you want to activate/deactivate. You can click on the lookup icon and then click “New”. In this example, I will create a query to deactivate all active accounts older than 1 year:

image

The second parameter (Target State) correspond to the state code to which I want to set my records. In this case I want the accounts to become inactive, so the corresponding statecode is 1. Most records in CRM have statecode 0 (for Active) and 1 (for Inactive). If you wanted to bulk activate (instead of deactivate) you would select 0 as your target state.

The third parameter corresponds to the target status. The default status is -1 which corresponds to the default status code for your selected statecode. If you want a different status than the default you can always browse the entity metadata to find the correct value. In this example, I want the status to become “Archived” so I look at the account “statuscode” field to find the corresponding value (100000000):

image

After configuring my custom step, it will look like this:

image

Note: There are special entities which you cannot activate/deactivate. For example, cases cannot simply be deactivated. They need to be resolved or cancelled, these special operations are not supported by this tool.

 

 

Cascade SetState:

Use this step in order to cascade the record status from parent to child records. For example, deactivate all contacts if you deactivate their parent account. This step requires 3 configuration parameters:

image

  1. Child Entity Name: The schema name of the child entity to which you wand to cascade the SetState operation
  2. Child Lookup Attribute To Parent: This is the schema name of the attribute (field) of the child entity that links to the parent entity via a lookup.
  3. Target Child State Code: The target state/status to cascade to the child entity. For most cases “1” is inactive and “0” is active.

You can cascade activate or deactivate operations by building your workflow with conditions. In the example below, the child contacts are deactivated if the parent account is deactivated, but also the child contacts are activated if the parent account is activated. You just need to use the correct value for the “Target Child State Code” argument of the custom workflow activity.

image