One of the limitations of the existing workflow design is that it does not give the flexibility, to the administrators or the workflow rule designer, to fine tune the scope of apply rule dialog. I.e. ability to define who can and apply the workflow rules.
The administrator can make the apply rule option to disappear for a user by taking away his/her workflow process instance privileges. In that case only the automated rules work but the user can not apply any of the workflow rules. The adaptive UI will remove the apply rule menu option from the Action sub menu.
What some administrator may want is not to cripple the user with his/her ability to apply workflow rules but to disallow users from invoking some critical workflow rules. To do that the below simple .net assembly comes very handy. Below strategy will ensure that only automatic invocation of the rule works by making the workflow rule inert to manual invocations. Note: The only special case is for the owner of the rule. He/she can still invoke this rule manually.
public class Test
public bool AllowCaller(string callerXml, Guid ownerId)
if (GetUserId(callerXml) == ownerId)
private Guid GetUserId(string callerXml)
//Note: the callerXml is of the fomat:
//callerXml = “<caller><userid>684F160A-E4D9-4C3C-ADDD-1464D2B14EB2</userid><merchantid>F671739E-189A-4EE8-AF86-66DC8CF5F6C4</merchantid></caller>”;
XmlDocument xmldoc = new XmlDocument();
return new Guid(xmldoc.DocumentElement.SelectSingleNode(“//caller/userid”).InnerText);
Workflow Config file registration:
<method name=”AllowCaller” assembly=”CrmTest.dll” typename=”CrmTest.Test” methodname=”AllowCaller” group=”Utility”>
<parameter name=”callerXml” datatype=”caller”/>
<parameter name=”ownerId” datatype=”lookup” entityname=”systemuser”/>
Activate the workflow rule and test it out.
You can also use similar strategy to restrict manual invocation of the rule to a group of users like users with system administrator roles or to a predefined set of users.