Monday, August 15, 2016

With the introduction of the “Entity” scope in Business
Rules, we can now configure them to execute on the server instead of a form
(client-side) logic. However, this brings a dilemma on whether to use business rules
or synchronous workflows for server level validations and business logic
implementation.

Business rules that are defined on the scope of a form opens the door to defining form
business logic that is configurable and requires no coding (something that
previously would require JavaScript). Although there are many limitations to
business rules, they enable simple business logic to be implemented by a
configurator rather than a developer. However, in many scenarios the data in
CRM is not created/updated via a CRM form.
For example, bulk data import, workflows, plugins, API/SDK calls would bypass
the CRM forms and therefore would also bypass any JavaScript or form Business
Rule validations you might have configured. These type of server-side
validation had typically required plugins or synchronous workflows.

Luckily, business rules now have a new scope “Entity” which applies at the server
level instead of the form level. What this means is that these business rules,
just like plugins and sync workflows, will execute even if you are not using a
CRM form in your transaction because they happen on the platform (server side)
instead of the form (browser/client side). There are certainly a large number
of limitations on what business rules can do and there is still a large number
of scenarios for which you must write code (plugins) to implement more complex
rules. However, I sometimes get asked the question: If I can implement my server-side business logic as a business rule or
a sync workflow, which one should I use?

Although I would love to hear from the broader community
what is your position on the question above, I will provide my own personal
view. If the question is asked, then I assume whatever you need to implement
can be done with either business rules or sync workflows (what are the limitations of each is a separate topic not covered in
this post). And in that case my answer is almost always to use business
rules if you can. This is why:

Business Rules are contained in the entity
itself in the solution which I find somewhat cleaner and more organized, you
can review which business rules apply to each entity and when exporting a
solution (CRM 2016+) decide which business rules to export. You can argue
processes have a primary entity and you can use that field for the same
“organization” purpose (sure I give you that).

Business Rules are actually implemented as sync
workflows! The business rule is nothing more than an abstraction of a sync
workflow but behind the scenes each business rule is converted to a sync
workflow. However, I find the abstraction useful, mostly because I can
interpret business rules a lot easier in my head than workflows. If you export
a solution with a business rule you will notice the business rules are actually
“processes” just like sync workflows so there is a conversion layer from entity business rules to sync workflows.
What this means is that there are basically 2 separate designers (process
designer and business rule designer) that produce the same workflow XAML
definition that is executed by the same runtime. While both workflows and
business rules are actually stored in the “Process” table/entity there seems to
be a slight difference in the triggers: The workflow triggers are stored in the
same Process table but the business rule triggers have their own
“ProcessTrigger” (anyway that’s all implementation details).

Workflow designer is quite outdated and probably
reaching its end of life. However, it seems Microsoft is investing more and
more in the business rules designer and supporting more and more scenarios with
each CRM release. I personally find it more pleasant to work with the business
rule designer than the old process designer.

On the other hand, sync workflows can be more useful if you
want to at some point enable additional capabilities not supported by business
rules. For example, user-level scope of a workflow (as opposed to Organization)
and some of the other settings available in the process designer which are not
available in the business rules designer.

In summary, sync workflows (and by extension process
designer) have a lot more capabilities than business rules (and business rule
designer). But if you have some business logic which can be implemented with
either, then would suggest using business rules in that case instead of
synchronous workflows.

About me

I used to be part of the CRM product team at Microsoft and I recently joined the Avanade Canada team as a consultant in the CRM Service Line, I developed a sort of delight in seeing how Dynamics CRM is evolving as a platform (xRM) and how its feature set has matured to be able to model and address plenty of business scenarios beyond Customer Relationship Management. I was recently given the Microsoft MVP award in Dynamics CRM and I am really excited to be part of the program and continue contributing to the CRM community.