When creating workflows there are some things that have to be taken into account. One thing that you might not know the details about is the Scope in “Options for Automatic Workflows”. There are four options that are very similar to the options used for setting up security roles. They are:
– User
– Business Unit
– Parent: Child Business Unit
– Organization
Bellow the selection of the scope, there are some workflow triggering options, like starting the workflow when on create or when an attribute has changed.
The meaning of this is that dependent on the scope you have selected, the triggering will be set up, based on the user who owns the workflow.
So, for instance, if I select “User” in scope and then select triggering on attribute change, and I am the owner of the workflow, then it will only trigger when I make a change to the object.
If scope is set to Organization, it will trigger for all users in the tennant which is why this is most often used. Note however that user is set as default, so you’ll have to change this when creating the workflow if you want it to work for someone else than yourself.
This is a useful tool since it can allow powerusers to create their own workflows to help them with their work without actually enabling this for everyone else.
As I have mentioned earlier, the workflow functionality is very powerful, and even thought there are protections agains infinite recursions and such, there is still the risk that semi skilled powerusers creating workflows that put a heavy load on the asyncservice, so I would be a bit reluctant on letting them use this. Thorough training is a must before and try to teach them to keep the workflows simple. If you have several custom workflow activities, for instance, activities for integrating with other systems, I would be very careful since it is hard, if not impossible to restrict a custom workflow activity to just a selected amount of users.
Gustaf Westerlund
Microsoft Dynamics CRM Architect
Logica
www.logica.com
Hi, your blog has been very helpful. Could you please help me with the following problem. I created a custom 1:N relationship between the Account and Lead entities to allow the user to link a lead to an account. I realised while testing that once the user has added a lead to the account he/she cannot remove it from the list of leads in accounts by deleting it. If you delete the lead from accounts, it is deleted from the system. Is there a way around it? Thanks. Heti
Hi Heti,
Nice to hear that my blog is appreciated.
Well, there is no out-of-the box solution that will work from the list. If you open the lead, select the lookup with the account an then press delete, you will remove the link.
This can be automated with a workflow that can be called on several entities manually from the list.
The third alternative is to create an ASP.NET page that has some code to handle this. This will require some ASP.NET coding skills of course.
I hope this gives you some help.
Gustaf