Microsoft Dynamics CRM 2013 Added new Workflow based mechanisms: Custom Action and Real Time (synchronous) Workflow. Along with Dialogs and Background (a-synchronous) Workflow, these mechanisms render the already powerful Processes family into a versatile implementation suite which allows implementing complex business logic in online and on-premise deployments. Some business logic which in version 2011 was only achievable via custom code, can now be achieved via declarative Process.
This versatility increases the ROI on Custom Workflow Activities components development as these components, which complete the capabilities of the Processes family via code, can now be reused in even more business scenarios by non developers.
One functionality is painfully missing in the Processes basic toolbox: the Share functionality. This may derive from the potential negative performance impact related to record Sharing in large scales which must be taken into consideration when planning an implementation.
It is recommended to share records with Teams rather than with single Users, and also to revoke shared privileges when ever possible.
To supply the required Share functionality via Processes, a Custom Workflow Activity can be used. Custom Workflow Activity is a DLL developed in .NET and deployed to Microsoft Dynamics CRM organization. It allows extending the Process capabilities with custom functionality. Once developed and deployed, this component can be used in Dialogs, Workflows (a-synchronous and synchronous) and Custom Actions in various business scenarios for different entities.
In order to Share a business record with a User or Team, some input details are required. These details are mapped by the user defining the Process hence the Custom Workflow Activity component must support matching input parameters:
- Target record – which business record is to be shared?
- Target principal – with what User/Team is the target record to be shared?
- Share privileges – what privileges (read/write/delete etc.) are to be granted to the Target Principal regarding the Target record?
There are some challenges in developing a generic Custom Workflow Activity component, which I will discuss next.
One major challenge is making this component generic enough to handle any entity that supports the Share operation.
This challenge derives from the Custom Workflow Activity input parameter types, which sadly do not include the Entity class. The supported EntityReference parameter type requires the ReferenceTarget attribute, which bind it to a specific entity type. So using EntityReference does not achieve the required generic solution.
My solution is to let the user (who defines the Process) define the target entity schema name as an input parameter of string type. This approach puts the responsibility of getting the entity schema name on the user defining the Process. I trust anyone who is can define a Process is capable of correctly copying the entity schema name from the entity customization page.
Another challenge is getting the id of the target business record. As this component is required to operate on any sharable entity, the user defining the process must be able to point to any business record of any entity. Again, the Custom Workflow Activity input parameter types limit us.
The solution here relies on the Workflow ability to supply the URL of any business entity as part of the attributes exposed in the Workflow editor. As this URL eventually contains the record GUID (unique record id), it can be used to supply the required target business record id.
The rest of the input parameters are more trivial. As records can be shared with either User or Team, two EntityReference input parameters allow specifying the target principal respectively. The privileges input parameter allows the user to specify the required privileges via a simple string.
The same approach can be implemented in version 2011 as well.