Microsoft CRM 4.0 has several methods to add functionality, to create custom workflow in CRM you have two options plugins and workflows.
Plug-ins are .NET classes which are triggered by messages sent to the CRM platform. These messages are any of the requests that can be execute on the CrmService such as the Create, Update and Delete events, but also the Retrieve, ConvertQuoteToSalesOrder and even the Execute message it self. Plug-ins are typically used for sort running actions such as validation, auto-completion of data and creation of related records. Workflows on the other hand are typically for two other senarios; creating long running rules, such as wait until the activity due date then trigger a reminder action. They can also be used to allow users to create there own business logic. Using the CRM web based workflow editor user can create simple workflow rules them selves. Workflows can be used on in CRM Live where plug-ins cannot.
CRM 4.0 offers a whole set of new functionality and with it a new domain of terms.
Plug-in: A piece of custom business triggered by a Crm Request messages. In CRM 3.0 this was called a Callout.
Plug-in assembly: .NET assembly containing one or more Plug-in types
Plug-in type: a registration of a .NET class.
Plug-in step: a filter which defines the condition when to invoke a Plug-in type
Plug-in (step) image: a image of an entity related to a request to be passed to a plug-in step.
Workflow: A Windows Workflow Foundation based definition of activities to execute.
Workflow step: An activity within a workflow.
Custom Workflow Activity: A Windows Workflow Activity with some CRM specific meta data. In CRM 3.0 this was called a Workflow assembly.
A plugin can be any .NET class which implements the Microsoft.Crm.Sdk.IPlugin interface. More information on plugins you can find here. Plug-in are also used to start the workflows, when you publish a workflow in CRM it actually creates and registers a plugin which starts the workflow.
When you want to pass an image to a plug-in you need a reference to determine which entity to pass. This must be a parameter of one of the following types: Guid, MonikerSelector, Moniker, EntitySelector. You can also use a property of the input parameter (such as a lookup attribute on a dynamic entity input parameter) for the reference. The name of this parameter can be different for most messages, which are the available parameters and their types you can find here. The meta data based plug-in registarion of my CRM tool will automatically select the parameter name to use for the most common message types.
Workflows are basically standard Windows Workflow Foundation activities with a CrmWorkflowActiviy attribute added to them. Details on writting custom workflow activities can be found here for the CRM specifics look here.
Besides the standard information available in the links above I have found some use full information while working with them.
There are several options to start a workflow.
You can use the standard triggers: Create, status change, attribute change, assign or delete.
You can manually trigger it (On Demand).
Or trigger it from an other workflow.
The last method can be used if you have a more complex criterea to start the workflow; such as if a record is created with a specific value in a field. You can ofcourse add an conditional statement at the start of the workflow, but another option is to create a plugin to start the workflow. This option is more complex to implement but you can be more selective in starting workflows. The workflow is simply started using the ExecuteWorkflow message.
When working with workflows you will in most cases need references to one or more entities. The entity on which you define the workflow can be retrieved from the IWorkflowContext PrimaryEntityName and PrimaryEntityId properties, see on how to get a reference to the IWorkflowContext.
If you need reference to other entities such as an activity you created earlier in the workflow you can add a property to the workflow. You do this by defining a property of type Lookup and adding a CrmInput attribute to define it as a input parameter. You also need to add a CrmReferenceTarget attribute to define which type of entity can be referenced. If you want to allow the customer to select multiple entity types you will need to add multiple properties and for each property you can a single CrmReferenceTarget attribute with a single entity type. The SDK contains more information on the available metadata attributes.
One other thing when defining a dependency property the name of the property field (myLookupProperty in the example) below MUST be exactly the same as the property name (myLookup) with Property added at the end.
public static DependencyProperty myLookupProperty = DependencyProperty.Register("myLookup", typeof(Lookup), typeof(CreateCustomEntity));
[CrmInput("My Lookup")]
[CrmReferenceTarget("account")]
public Lookup myLookup
{
get { return (Lookup)base.GetValue(myLookupProperty); }
set { base.SetValue(myLookupProperty, value); }
}If the Web based workflow editor does not allow you to create a workflow the way you like; for example if you need a looping construct. Then you may want to consider creating a workflow entirely in visual studio. Here you can leverage all the abilities of the WWF. The way to do this is actually very simple, you just create a custom workflow activity. To be more specific you create a sequence activity. In a workflow activity library project if you add a new item and select the Activity template (same type as the default class available in a new activity library project). This class has a designer attached in which you can add other activities. When you created this activity you can compile and upload it as a custom workflow activity. The using the web based CRM workflow designer you create a workflow with only a single step: the activity you just created. Here you also set the start criterea.