The same code can also disable other stage-specific fields (such as additional qualifying info dates, etc.). For example, if the current stage is Completeness Review, only the Completeness Review decision option set should be enabled all other fields on all other BPF stage chevrons should be disabled. The last trick is to add a little JavaScript to disable all decision gate fields that do not correspond to the current active BPF stage. While we cannot reconnect a branch to the main trunk, we can set it programmatically by: The next piece of the puzzle is to solve the ever-branching BPF.
Crm business process flow update#
If possible, this workflow should be synchronous to ensure that if a user clicks on the next stage button in the BPF area, the stage-exit workflow will update the UI to the next status on save. When a user makes a choice in ‘Household Eligibility’ stage shown above, this workflow will run and will set the appropriate status based on the decision taken. This workflow will be triggered by the change in the corresponding decision gate field and its main task is to set the matching record status. for the process described here there’s a workflow for Draft, Pending Doc, Completeness, and all other possible stages. One workflow per stage (status value) is required to implement the decision gate selection. This is strictly speaking not necessary for linear flows but the decision field is helpful to serve as an indicator of an acceptance of the current state and an additional audit mechanismĭecision field as indicator of current state The main data element displayed in a BPF’s stage is a decision field which drives the flow to the next stage. The solution To avoid potential confusion between looking at the field value and the BPF area, map the record status values to BPF stages. If you look at the BPF designer, the fork is created using a condition:Īll the suddenly terminating branches, except the top one, are there to support forks and loops. In another example, if we imagine ‘Completeness’->’Household Eligibility’->’Project Set-up’ as the main branch of the process (as it belongs to a happy branch that can lead to an approval), if we go to ‘Request for Info’ fork in the BPF, there is no built-in way to go to ’Household Eligibility’ after that. The challenge in implementing this flow is that once the BPF flow is forked, you cannot continue from the forked branch to the main branch - a run-time error will result. This latter stage can create a closed loop by sending the process back to Completeness Review stage. The application lifecycle diagram, depicted below, is not very complex, but it has multiple forks where some forks can lead to prior stages in the process, creating loops.įor example, Completeness Review stage (3rd box from the top), can lead to Household Eligibility Review or Request for Additional Info. For example, if there are Draft and Review values in the status field, the ideal system should:Įach BPF stage therefore contains only stage-specific decision fields. One of the main ingredients that is often lacking is the missing or unenforced connection between a record’s status value (which is typically mapped to a lifecycle stage) and the selected stage in a BPF. A purely visual guide with a random set of fields under each stage’s chevron quickly becomes inadequate. The reason many users often fail to see much utility in BPFs is that a typical BPF is weakly connected to actual processes users go through when working with data and often fails to serve as an enforcer of institutional rules. The real-life usage of BPFs sometimes falls short of the promise to make users' lives easier by guiding them through a business process.
However, one of the first questions we often hear from users after the new project goes live is “Is there a way to hide BPF area of the form?”.
The problem When starting a new project, we usually end up designing and building a set of BPFs for the most important records in our system. The set of chevrons at the top of the single record form typically represents major phases in the record’s lifecycle. We are all familiar with Business Process Flows (BPF) in Dynamics 365 – they’ve been around for a while. This is a guest blog post from Dmitri Riz, the director of InfoStrat's Microsoft Dynamics Practice.
0 kommentar(er)
