A Decade of Evolution: The Journey of Business Process Flows in Microsoft Dynamics CRM
It has been a decade since the release of Microsoft Dynamics CRM 2013, codenamed Project Orion. With this release, Microsoft Dynamics CRM adopted a modernized user interface, moving away from its Outlook 2000 look to something more akin to Windows 8. Senior Consultant Nuno Lima shares insights on the evolution of Dynamics CRM, the introduction of Business Process Flows (BPF), and the potential for further enhancement in collaboration with the Microsoft community.
What is a Business Process Flow?
Business Process Flows (BPF) are a set of steps designed to guide users towards a desired outcome, providing a visual representation of the stages within a business process. BPFs ensure consistency across various business processes, from customer service to invoicing.
How Did Project Orion Revolutionize Business Process Flows?
Project Orion brought significant changes, including an enlarged user interface with more white space, making it more suitable for touchscreens and providing a contemporary look for CRM. Dynamics CRM 2013 introduced BPFs for all custom tables, expanding their application beyond just Cases, Leads, and Opportunities.
Microsoft’s announcement at the time highlighted the excitement around BPFs, stating:
“An exciting part of the Orion release is the concept of a Business Process Flow. A Business Process Flow (BPF) allows you to represent your business processes in CRM.”
This release marked a pivotal shift towards a platform where applications could be created to support diverse business processes, independent of Sales, Marketing, and Customer Service modules.
The App Maker’s Perspective
From an App Maker’s perspective, BPFs are built with a wireframe showing the stages, actions, and sequences of a process:
Figure 1: A Business Process Flow for guiding a Lead to Onboarding process (App Maker perspective).
The App User’s Perspective
For users, BPFs are presented visually, with the active stage highlighted and other stages displayed horizontally:
Figure 2: A Business Process Flow for guiding a Lead to Onboarding process (App User perspective).
Newfound Freedom in BPF
The documentation for Business Process Flows includes resources like the whitepaper: Process Enablement with Microsoft Dynamics CRM 2013 and its updated overview: Business Process Flows Overview.
In these documents, Microsoft product owners emphasized a “Guide vs Control” approach, advocating for BPFs to provide guidance in the UI rather than rigidly enforcing a single sequence of steps. BPFs also support Business Rules and can trigger automation with Workflows and modern Flows, allowing for a dynamic adaptation of the UI based on the current stage of the BPF.
For example, Business Rules can be conditional on the Stage Category, which groups stages based on the type of action and reports accordingly:
Figure 3: An App Maker perspective of grouping reports based on the stage they are in.
BPF configurations can extend to executing Business Rules when a specific stage is active, or when a user interacts with a BPF stage header:
Figure 4: Execute Business Rule based on the stage of BPF (App Maker perspective).
Low-Code/No-Code Accuracy
These components contribute significantly to creating a user-friendly interface with low-code/no-code configurations. However, BPFs currently do not support form switching, which limits their functionality to a single screen. Complex apps with numerous fields on a single form still require meticulous UI design.
Enhancing BPF with Form Switching
It would be valuable if BPFs included a mechanism for switching forms as stages change. A configurable default form for each BPF stage could eliminate the need for JavaScript to automate form changes. The proposed configuration might look like this:
Figure 5: A “Default Form” configuration suggestion.
With this setup, when a new BPF stage is activated, the associated form would open, running the relevant business rules for that form. For instance, different stages like “Standard Contracts” and “Special Contracts” could each have distinct forms with varying fields, charts, and sub-grids:
Figure 6: A mock-up image indicating the correct form for the BPF.
Figure 7: Form loading mock-up image from App User perspective.
Developers could leverage this feature, knowing that form switching will be visible to users, and Business Rules will execute in a clear context.
Continuous Improvement in the Microsoft Community
The idea of making default forms configurable from the BPF has been submitted to Microsoft’s Ideas website for community feedback and upvotes.
Visit our Power Platform page to explore its extensive capabilities or contact our team of Power Platform experts to learn more or get in touch today.