Wednesday, June 22, 2011

Inserting a static hyperlink into an e-mail or dialog via workflow can be simple since the hyperlink is known at the time you design your workflow (such as http://www.bing.com). However, you might need to insert a hyperlink to other CRM records that are not known at the time you design your workflow (e.g. link to the owner of the primary entity or link to the primary contact of the account).

Quite often I have heard the need to insert dynamic hyperlinks to CRM records via workflow. Typical requirements I have seen include:

Workflow should send an email with a link to the primary entity of the workflow.

A dialog prompt page should provide a link to a CRM record that is related to the context of the dialog (for example a hyperlink to the primary customer of the account for which the dialog is executing).

I have shared a utility that allows you to easily generate dynamic hyperlinks to CRM records and be able to use them in both dialogs and e-mails.

Attribute name to related entity. If you are creating a hyperlink to a related entity, you must provide the attribute name that relates the two entities. For example, if the primary entity is account and you are creating a hyperlink to the primary contact, specify the "primarycontactid" attribute.

HyperLink text. This is the text that the user will click in order to follow the hyperlink. For example, the text in the following hyperlink would be "Bing": Bing. If the hyperlink text is not provded (you leave it empty) then the text used will be the value of the primary field of the entity. For example if you create a hyperlink to an account named "ABC" then the text in the hyperlink will be "ABC".

4. Use your hyperlink in a dialog. When designing a prompt/response step for a dialog, you can insert a dynamic expression that uses the "DialogHyperLink" output from the previous step.

5. Use your hyperlink in an e-mail. When configurin the "Send E-mail" workflow step, you can insert a dynamic expression that uses the "HtmlHyperLink" output from the previous step.

For more documentation on how to use the CRM 2011 Workflow Utilities visit the CodePlex project here. You can also download the source code if you need to achieve similar functionality but want to build your own solution.

Tuesday, June 14, 2011

This post is inspired by a popular article by my ex coworker Humberto Lezama G. regarding when to use plugins or workflows for implementing custom logic in CRM. I have expanded the matrix to add additional criteria and more details about how each plugin vs. workflow handle different types of requirements. Additionally, I have added the new “dialogs” as an alternative in the chart.

Criteria

Use Plugin

Use Workflow

Use Dialog

Needs custom logic to execute synchronously.

Plugins support synchronous execution.

Dialogs always execute synchronously.

The logic needs to be executed while offline

Only plugins are supported offline.

Needs elevation of privileges (impersonation)

In the plugin step, you can select the user under which the plugin will execute by setting the impersonating user id in the plugin step.

In some cases you can control under which user the workflow will execute by assigning the workflow to that user. See more details here.

Needs to execute on events other than assign, create, update and set state

The process/logic may take a long time to complete or will be a persistent process (multiple long running steps)

Workflows have no limit on the length of time they can take to complete execution. They can also persist (pause) and resume at a later date. Plugins have a time limit of a couple of minutes to complete (even asynchronous plugins).

Needs to execute asynchronously

Plugins support asynchronous execution

Workflows support asynchronous execution

End users will need to modify the process logic

Processes can be modified using the CRM process designer in the application and does not require IT administrators to re-compile and deploy a plugin assembly.

Child sub processes will be triggered

CRM processes support executing child processes

Needs to read configuration parameters for execution

You can make use of the configuration and secure configuration settings in the plugin step. These values will be passed to the plugin constructor and can be easily updated.

Dialogs cannot be configured with configuration parameters but they can retrieve configuration information from user responses / interactions.

Need to execute logic on-demand

Workflows and dialogs can be executed on-demand. Plugins can only be triggered as a result of a specified action to which the plugin step is configured.

Needs to roll back transaction in case of error (useful for validation)

Plugins can be registered in-transaction so they are able to roll-back the main operation if the plugin fails. Workflows are executed post-transaction so they cannot roll back the main operation.

The plugin/workflow logic is not possible to implement by using the CRM process designer

Plugins are written in .NET and this supports any action that can be achieved using the CRM SDK.

You can extend workflows/dialogs by creating a custom workflow activity which is also written in .NET calling any method from the CRM SDK. However, this is not supported in CRM Online yet.

Interaction with user is required to execute the custom logic

CRM dialogs support the execution of a process which dynamically takes input from question asked to the user.

Need custom logic to execute before the main operation

Only plugins can be registered to execute pre- main operation.

Need to gather data from the entity pre-image (image of the entity before the main operation)

Need to gather data from the entity post-image (image of the entity after the main operation)

You can register post-images for plugin steps.

Post image is available from the process designer in the CRM application.

Needs to be packaged into a solution

Plugins and processes are solution aware

Need to use variables to store temporary data

Use the SharedVariables collection to store variables that can be passed to other plugins.

Use the SharedVariables collection to store variables that can be passed to other workflow steps. These variables do not survive persistence and can only be used from custom workflow activities. Not supported in CRM Online.

Dialog support variables of type string, int and float that can be passed from one step to another. For other types, SharedVariables can be used from custom workflow activity.

Monday, June 13, 2011

While there are multiple system entities such as contact and user which have an auto-populated full name field, there is no simple way to extend that functionality to custom entities. The auto-populated full name field consists on a field that is maintained by the system and the value comes from a combination of the first, middle and last name field, as well as from the system settings on how to format full names (e.g. “Gonzalo Ruiz” vs. “Ruiz, Gonzalo”). For custom entities, you could have a custom fullname field which contains the entire name instead of separating the name into 3 fields (first, middle, last), but you would be missing on the following advantages:

Sort/search by first, middle or last name while still showing full name in views, lookups, reports.

Enforcing a consistent full name format across the organization.

Because of the previous limitations, I have created a solution that allows you to extend the “Full Name feature” to custom entities. The solution is uploaded to CodePlex and supports:

Creating a full name primary field for any custom entity.

Auto-populate the full name according to the full name format selected in the organization system settings.

Auto-populate the full name from custom first, middle and last name fields.

Tuesday, June 7, 2011

You might have noticed that the process designer in CRM provides steps for updating/creating a record, sending an email, etc. but there is no step for deleting or sharing records. I have shared a CRM 2011 solution that adds a "delete" and "share" step in the workflow designer:

With this solution you will be able to delete and share the primary entity of the workflow, as well as all the related entities by a 1:N relationship.

The solution supprots the following actions:

Deleting the primary entity of the process or related entities (1:N relationships with primary entity).

Sharing the primary entity of the process or related entities (1:N relationships with primary entity).

Can be used in workflows and dialogs.

Use of dynamic expressions (e.g. Share record with the "Manager of the Owner of the primary entity").

Sharing of any privilege (read/update/create/append/share/assign/etc).

No support for CRM Online

It is very simple and you only need to install the managed solution and voila. You can download the solution from CodePlex here. There is also documentation available on how the tool works.

Friday, June 3, 2011

I recently had the requirement to flag customers with warning messages so the CSR would immediately notice that the customer needed special care (e.g. VIP customer, or mentally ill patients). The customer wanted some kind of color-coding in the form; however, they decided to not use any unsupported customizations. Instead, we used the form header to capture this information and use regular attributes to do so.

Today I saw a post from Matt Parks which gives us a great solution for the same problem. Unfortunatelly, it is still unsupported in CRM and might break in the future, but it is simple and can be extremely useful, see the screenshot here:

Thursday, June 2, 2011

I decided to post this article since I am hearing quite often about developers using Disk and GAC for registering the custom plugin assemblies in CRM 2011. I have also heard claims such as “you must register on disk in order to debug” or “it is easier to update the assembly version when they are stored on disk” which I will do my best to disprove.

1. Only database assemblies can be packaged in solutions

Solutions are the future of CRM and Microsoft is not supporting packaging disk/GAC assemblies in solutions. Such statement almost suggests that GAC and disk are legacy registration modes, and moving forward only database should be used. Take advantage of being able to export, transport and import your plugin in a solution by registering it on database.

2. Zero service interruption to update a database assembly

If you register your assembly on disk or GAC and you would like to update it, you might be aware that even after the file is overwritten, the changes will not take effect until you do an “iisreset” which will cause down-time to your organization. Additionally, you must consider whether the plugin is asynchronous in which case you must also restart the CRM Asynchronous Processing service. Besides the down-time, there are also a number of manual steps to restart the services that you would probably want to avoid. If you register on database, all you need to do is click on “update” using the Plugin Registration Tool and update the assembly content.

This is indeed just as fast (if not faster) than drag-drop-replace but you won’t need to restart the services because the new assembly will take effect immediately after the update! The reason why you don’t need to restart the services is that the assembly loading routine from the bytes works different in .Net. When loading from GAC or disk, the assembly is loaded in the AppDomain as is never loaded again until the AppDomain or process is restarted. Note that if you plan to debug the assembly, you still need to copy the symbols to disk (symbols cannot go in database) and you can debug as usual.

3. Simplified organization backup / import.

If your plugins are registered on disk/GAC then backing up the organization database will not be enough. You will need to also backup all the custom assemblies you might have in the GAC or in disk. When you import the organization then you must also remember to copy those dll’s back into the new server(s). However, if you use database assemblies you only need the database backup and forget about tracking down these custom assemblies in order to restore your organization.

4. Disk assemblies will not support multiple versions

In CRM 2011 there is support for assembly versioning so you can have multiple versions of a given assembly coexisting in the system. For example, the workflow designer lets you select which version of a particular assembly for a custom workflow activity you would like to use:

Because both versions of the assemblies would have the same filename then you cannot register them simultaneously on disk.

5. All assemblies consolidated into a single place

With database assemblies another good thing is that they are all stored in a single place: the database. You don’t need to worry about deploying dll’s to file and GAC in multiple servers. If your CRM deployment is spread out in different server roles for load balancing, then you don’t have to worry about which roles will need your assemblies and on what servers you must deploy which assemblies. It can be really cumbersome with disk/GAC assemblies as you can easily lose track for example of which plugins run asynchronous vs. synchronous so they must be deployed to the web and async servers respectively.

6. Sandbox and CRM Online only support database assemblies

If you have your assemblies registered on database, you could include them in a solution. Therefore, you can easily migrate to CRM Online by exporting/importing the solution and you can mark your assemblies as sandboxed. You would not be able to sandbox your assemblies for disk/GAC and you would not be able to package them to migrate to CRM Online.

Wednesday, June 1, 2011

Do you get error messages like "You do not have the correct security role to do this. Only a user with the deployment administrator role can create or update processes that are created outside the Microsoft Dynamics CRM Web application." or "This process cannot be created, updated, or activated because it was created outside the Microsoft Dynamics CRM Web application. Your organization does not allow this type of process." ?

With CRM 2011, workflows integrate with WF4 giving us all the power of the WF4 engine and designer. Nevertheless, there are some caveats to this approach. First, for now, custom XAML workflows are only available on premises (for the same reason as custom workflow activities are only available on premise: They cannot be sandboxed). Second, importing custom XAML into CRM requires the highest privilege (deployment administrator) and the organization must be configured to support XAML workflows (disabled by default).

These are the steps to follow before you import custom XAML:

Ensure you are a deployment administrator. To verify this, you can try to open the Deployment Manager. If you are able to do so then you have the privilege. Otherwise you will need to ask your deployment administrator to add you as a deployment administrator (in DM) or to import the custom XAML for you.

Make sure that the organization supports declarative (XAML) workflow. To do so, you should run this script in powerShell:

About me

I used to be part of the CRM product team at Microsoft and I recently joined the Avanade Canada team as a consultant in the CRM Service Line, I developed a sort of delight in seeing how Dynamics CRM is evolving as a platform (xRM) and how its feature set has matured to be able to model and address plenty of business scenarios beyond Customer Relationship Management. I was recently given the Microsoft MVP award in Dynamics CRM and I am really excited to be part of the program and continue contributing to the CRM community.