CRM的Workflow给我们的流程处理带来不少便利，但是这种自带的Workflow并不是万能的，中间某一step不能支持，往往会牵一发而动全身，可能造成整个Workflow Steps的重新设计。幸好CRM还提供了其它的方案来实现这类需求，这里要说的就是Custom Workflow Activity。
下面用个具体的实例来说明下，现在有Entity A,B,C,D，它们的关系是，A上有对B的Lookup字段BLookup，B上有C的Lookup字段CLookup，C上有D的Lookup字段DLookup，希望由A的某个字段的变动触发Workflow，发送邮件，而邮件的接收人是D上的某个User字段的值。配置过Workflow的人都知道，CRM的Workflow是不能跨多层去指定这个User的，所以这里我们可以借助Custom Workflow Activity来实现。
首先在Visual Studio Project的配置上，Custom Workflow跟Plugin是相似的，需要额外引用一些dll，比如microsoft.xrm.sdk.workflow.dll，System.Activities.dll等
接着是指定类的继承，与Plugin需要继承IPlugin相似，这里需要继承CodeActivity(System.Activities.dll)
再然后，就是指定输入参数和输出参数了，毕竟我们是要根据一定的规则去获取最终的User。
指定输入参数：
指定输出参数：
指定输入输出Attribute，并使用InArgument<Type>和OutArgument<Type>，在这里需要注意的是，Custom Workflow仅支持如下的Type
还有一点就是，有一些特殊的类型，需要指定额外的Attribute：EntityReference，需要指定ReferenceTarget；OptionSetValue，需要指定AttributeTarget。
最后就是方法实现
protected override void Execute(CodeActivityContext executionContext) { try { IWorkflowContext context = executionContext.GetExtension<IWorkflowContext>(); IOrganizationServiceFactory factory = executionContext.GetExtension<IOrganizationServiceFactory>(); IOrganizationService service = factory.CreateOrganizationService(null); //service.Execute 获取user ReferringOfficer.Set(executionContext, user); ｝ catch{...} ｝
Project完工之后，可以使用Plugin注册Tool注册这个，不用添加任何Step。而Debug Custom Workflow，也是跟Plugin相似的套路，这里就不再多赘述了。
之后就可以在CRM自带的Workflow->Add Step中看到这个Custom Workflow了，配置好输入信息，并在Send Email Step中，配置返回值作为邮件的To，就达到了我们想要的效果了。
在使用Custom Workflow的时候，一定要注意返回值是空的情况，毕竟我们不能保证所有的数据都是完整的，比如D上的User是空，那么这个时候，需要注意配置默认值，也就是我在上面截图中的[Default]。