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:
– Business Unit
– Parent: Child Business Unit
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.
Microsoft Dynamics CRM Architect