Let’s look back at the journey of Business Process Flows since the release of Microsoft Dynamics CRM 2013, ten years ago!
It has been a decade since Dynamics CRM’s 2013 release, codenamed Project Orion. With this release, Microsoft Dynamics CRM adopted a user interface less like Outlook 2000 and more akin to that of Windows 8. We spoke to Senior Consultant, Nuno Lima, about the evolution of Dynamics CRM, the introduction of Business Process Flows (BPF), and how the Microsoft community can work together to continually improve this application for App Makers and Users alike.
What is a Business Process Flow?
Business Process Flows (BPF) are sets of steps to allow users to achieve a desired outcome, providing a visual indicator of which stage they are in the business process. BPFs enable consistency in business processes, from customer service processes to invoicing.
How did Project Orion revolutionise Business Process Flows?
This change was exemplified by all buttons and menus being enlarged, the white space between screen components increased for use on touchscreens and overall, a new, modernised look for the Customer Relationship Management (CRM) application. Dynamics CRM 2013 was also when Business Process Flows (BPF) were made available for all custom tables rather than exclusively Cases, Leads and Opportunities.
Microsoft’s announcement at the time read:
“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.”
The release was an important step in pivoting away from the existing CRM software and towards a platform where applications could be created to support diverse business processes with or without Sales, Marketing and Customer Service underpinnings.
From the App Maker’s perspective, the Business Process Flow is built with a wireframe showing the stages, actions and sequence of the process:
Figure 1 – A Business Process Flow for guiding a Lead to Onboarding process (App Maker perspective).
From the App User’s perspective, the Business Process Flow is presented on the screen, with the active stage highlighted and the other stages laid out 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 the whitepaper: Process Enablement with Microsoft Dynamics CRM 2013 and its summarised and more up-to-date overview: Business process flows overview.
In this whitepaper, Microsoft product owners set out a vision for how to use Business Process Flows. The main idea conveyed in the “Guide vs Control” chapter, is that developers should configure Business Process Flows to create guidance in the user interface (UI) rather than attempt to constrain users to follow a single pre-determined sequence of steps.
Nevertheless, BPF has its own configuration for making the data fields required, is compatible with Business Rules and can trigger automation with Workflows and modern Flows. Those interactions with Business Rules are not prominently documented in the Microsoft Learn website, but they do allow adapting the UI according to the current state of the Business Process Flow.
For example, a rule can be conditional on which Stage Category is active, as shown below. A category allows users to group stages based on a type of action, and Stage Category groups reports based on the stage they are currently in.
Figure 3 – An App Maker perspective of grouping reports based on the stage they are in.
Taking this configuration one step further, you can have your Business Rule execute when a specific stage of the BPF is active (for example, a new stage was entered), or when a user clicks on a specific BPF stage header:
Figure 4 – Execute Business Rule based on the stage of BPF (App Maker perspective).
Low-code/no-code accuracy
These two components can play an important role in a low-code/no-code configuration of a user-friendly interface, guiding users to complete tasks consistently. However, the Business Process Flows in isolation do not support form switching, therefore will only work on a single screen. This means that more complex apps with dozens of fields on the same form still require careful consideration when laying out all the UI components.
How can the Microsoft Community continue to enhance its solutions?
Wouldn’t it be interesting if instead, the BPF offered a mechanism for switching forms as the process changes stages? If Microsoft implemented a configurable default form to load for each BPF stage entry, we would no longer need JavaScript to make the Form change automatically.
The configuration could look as simple as on this mock-up screen:
Figure 5 – A “Default Form” configuration suggestion, as shown in the mock-up image above.
This configuration means that when a new stage of the BPF is activated, the chosen form would open and the business rules applicable to the scope of the new form would run. The form switching would be noticeable especially because it is the user’s action that causes the BPF to move to a new stage.
Going back to the example of the first image, where we test a Condition “Standard Contract Applies?”, each of the two stages “Standard Contracts” and “Special Contracts” could have their own different Forms, with a variation of which fields, charts and sub grids shown on the users’ screens. When the BPF progresses to one of those stages, the correct form would be displayed.
From the App Maker’s perspective, they’d need each stage to load a specific form as per the mock-up screen shown:
Figure 6 – A mock-up image indicating the correct form for the BPF.
While from the App User’s perspective, when a specific stage is entered, the correct form would load:
Figure 7 – Form loading mock-up image from App User perspective.
Crucially, the developer could leverage this BPF configuration along with simple Business Rules set with a scope corresponding to either “Standard Contracts” or “Special Contracts”. They can do this knowing that when the BPF stage changes, the switching to the chosen screen form will be clearly visible to the user. Any Business Rules for changing whether fields are mandatory, visible or trigger suggestions will have a clear execution context, further contributing to practical and helpful user experiences.
Continuous improvement in the Microsoft Community
This suggestion of making the default form configurable from the BPF was submitted to Microsoft using their Ideas website, where it welcomes upvotes and suggestions.
Visit our Power Platform page to learn more about its extensive capabilities, or get in touch with our team of Power Platform experts today for more information.