D365 Workflows give Users Superpowers. That’s why a Workflow has Scope.

One of the best parts of being a Microsoft Dynamics 365 Consultant, is talking to users, power users, product managers, etc. about the options available for customizing Dynamics 365. And these conversations are the most productive when avoiding technical jargon and explaining a client’s options in non-technical terms. For instance, when describing Workflows, we sometimes tell clients, “They give your users superpowers, so let’s just be careful.”

We recently deployed a Workflow that runs when the Status Reason of a record changes. The Workflow assigns the record to a different User, sends an email from the previous Owner to the new Owner, creates a Queue Item, and updates a custom field on the record. To perform these steps manually, the User would spend about 2 minutes performing a few dozen keystrokes. The Workflow accomplishes the same thing in about 15 seconds, freeing up the User to perform more important tasks that actually require human decision making. In this case, we gave the Users superpowers and the client was happy.

But we do need to make sure these superpowers are not overused, so we should always be asking the client which records Workflows should run against. In other words, we discuss the scope of the Workflow. These discussions are much easier when consultants speak the client’s language rather than expecting the client to speak our Dynamics 365 language.

So, don’t ask the client if they want the Workflow to run against records the User owns, or records in the User’s Business Unit, or records in the User’s Child Business Units, or records in the entire Organization. Those terms and concepts likely mean nothing to the client. So, no, don’t ask the client which Option to select on the Workflow Designer:


Instead, ask the client when they want their Users to be able to use superpowers. Should it be only on records they are directly familiar with? Or perhaps only on records they are somewhat familiar with? Or maybe every record in the system, even if they know almost nothing about that record? We like to imagine the Workflow Designer looks like this:

When can the User invoke superpowers?

Requirements discussions are much easier when the consultant speaks the client’s language rather than the other way around. Adding a bit of humor never hurts, either.

Of course, there are many technical considerations to determining the appropriate scope of a Workflow, including things like Permissions, Business Units, “Execute As,” etc. This was meant simply as a reminder of the importance of communicating in non-technical language.

Don't forget to subscribe to our blog for more D365 tidbits.

Happy Dynamics 365’ing!