Dynamics 365 Solutions: how we solved a client CRM challenge8 min read

Welcome to our brand new technical series for Micrososoft Dynamics 365 consultants.

In these detailed articles, we will set out how we’ve approached and solved a challenge for clients by applying novel thinking to knotty problems. Our intention is to share best practice to promote excellence and collaboration in the national Dynamics 365 community.

This week, ANDREW FULLER and MOHAMMAD ADNAN, from our Delivery and Client Success Teams respectively, describe how they conquered an issue of quote approvals.

Background

Company A uses Microsoft Dynamics 365 to manage and report on its sales process. Their business process involves converting leads into opportunities and then fulfilment to obtain business.

When a lead is converted into an opportunity, the existing business process requires the approval of a group of ‘approvers’ to approve the quote presented to the customer if the business intended exceeds £30,000. The approvers are divided into two groups. Group A review opportunities where the monetary value is between £30,000 and £80,000. Group B reviews opportunities where the monetary value exceeds £80,000.

The monetary amount is captured in a currency field before approval is requested. The current implementation allows the primary (Owner) and secondary (BDM) sales agents to move along an opportunity sales process business process flow to get to a stage where an approval flow is triggered to the respective group of approvers.

Until the approval of the opportunity is granted by an approver, the agents cannot proceed further on the business process flow for the closure. This is managed by a read-only Two options field data step at the approval results BPF stage which is automated to change its value to ‘Yes’ once the approval has been granted. This allows the agents to proceed further on the business process flow to generate an order.

Requirements

Company A faces a challenge with its business process where all the approvers in either of the groups receive approval requests through their Dynamics 365 CRM whenever a sales agent triggers it. This creates confusion between approvers and more than one of them ends up reviewing the opportunity.

The company wants to implement a solution where the primary or secondary sales agent should be able to select an approver to obtain approval of the opportunity. This would mean only one approver would be engaged with the opportunity.

The requirements also state that only the primary or the secondary sales agent of the opportunity should be able to select the approver of their opportunity to ease communications. The last part of the requirements includes a 72-hour timer for getting the approval of the opportunity.

If the approval is not granted for more than 72 hours, the business process flow stage should change back from the approval results stage to a stage back where the approver selected by the sales agents needs to be deleted and the sales agents would select the approver again and move forward to the approval results stage to trigger the approval of the opportunity again.

Challenges

Amendments in security roles would not resolve the selection of approvers as it is more ownership specific. The User level privilege will not allow the secondary agent to select an approver as they are captured by a lookup of the system users and cannot behave as the owner of the opportunity.

Considering the business unit level of security privilege on opportunities can end up in multiple combinations of business units to be created which is not a good solution and a sales agent not involved with an opportunity might still end up choosing an approver of the opportunity.

Field Security Profile for the group of sales agents to control the update of implemented ‘Approver’ field, used to select the approver of the opportunity, would also allow all the sales agents in the field security profile to select the approver for an opportunity they are not a part of.

A combination of both was also not an accurate solution for the requirement as the secondary agent would end up unable to select an approver for his/her opportunity.

An SLA was considered to record the time that the opportunity spent on the ‘approval results’ stage and its failure to move back a step in the business process flow to select the approver again. This was adding another layer of complexity and the solution intended not to make a lot of changes in the current set of automation.

Solution Components

1. Table Contents Opportunity

(Please refer to Appendix A for the Business Rules logic)

2. Workflows

a. Opportunity- Clear Date sent for approval

• On-demand workflow
• Real-time
• Clears c9_datesentforapproval.

b. Opportunity – Send email reminder for approval of the opportunity

• Triggers on change of c9_sendreminderforapproval.
• If c9_sendreminderforapproval is ‘Yes’ then sends an email to the sales agents of the opportunity.
• After sending the email, updates c9_sendreminderforapproval to ‘No’.

c. Opportunity- Update date sent for approval

• On-demand
• Real-time
• Updates c9_datesentforapproval with ‘now’ date and time when the Opportunity Sales Process moves to the ‘approval results’ stage.

d. Opportunity-Clear Approver modified by

• Background
• Triggers on change of c9_approved or c9_approvermodifiedby
• Clears c9_approvermodifiedby if c9_approver does not contain data and c9_approvermodifiedby contains data
• Includes a delay of a minute
• Useful to remove the error displayed and enables the saving of the record if the approver was selected by someone other than the responsible sales agents.

e. Opportunity-Update Approver modified by

• Real-time
• Triggers on change of c9_approver
• Updates c9_approvermodifiedby with out of the box ‘modifiedby’ when an approver is selected in c9_approver.

3. Opportunity Sales Process

The Opportunity Sales Process contains three stages that are key to the implementation of this solution. The stage referenced above as ‘approval results’ is divided into two different stages, ‘Group A approval result’ stage ‘Group B approval result’ stage. Both of them are branched based on the value of the monetary amount stored in one of the data steps of the ‘Pre-approval stage’ and record information like the user who approved the opportunity, the date when the opportunity was approved and whether the opportunity was approved or not. The branching occurs if the monetary amount is greater than £30,000. Otherwise, the approval process is skipped. The three stages are described as follows:

a. Pre-approval stage Contains the data step to store the monetary value of the quote presented to the customer, c9_approver and ‘Saved the record?’ columns as data steps as well. The latter two are visible only if the monetary value is greater than £30,000.

b. Group-A approval result The stage consists of two workflows, ‘Opportunity-Update Approver modified by’ and ‘OpportunityClear Date sent for approval’, which get triggered on stage entry and stage exit respectively. When an opportunity sales process enters this stage, the date an approval request was sent is recorded in c9_datesentforapproval. Similarly, when an opportunity exits the stage, c9_datesentforapproval is cleared. This is to support the automation involved in moving the opportunity back a step if the opportunity sits on this stage for more than 72-hours without getting approved.

c. Group-B approval result Behaves similarly to Group-A approval result.

4. Power Automate

a. Power Automate 1

Purpose: Sends out an approval request triggered on stage change of the Opportunity sales process. If the active stage changes to either ‘Group-A approval result’ or ‘Group-B approval result’. The flow gets the system from the c9_approver stage and sends out an approval request to the selected approver from the Primary/Secondary sales agent and waits for the approval/rejection.

b. Power Automate 2

Purpose: A scheduled flow that runs every hour to check if any of the open opportunities’ c9_differencebetweentodayandapprovalsent is greater than 72 and then lists their respective opportunity sales process record and moves them back from the approval results stage to the pre-approval stage clearing out c9_approver. It also updates c9_sendreminderforapproval to Yes which sends out an email to the sales agents of that opportunity to re-initiate the approval process.

Implementation

The implementation part can be broken down into the following two parts based on the requirements.

1. The Approver should be selected only by either of the responsible sales agents

2. Managing the approval

The Approver should be selected only by either of the responsible sales agents

The following flow diagram defines the way the mentioned part was implemented. Business Rules and workflows were very useful during this implementation:

Managing the approval

The following flow diagram defines the management of the approval process. The logic model works alongside the business rules and workflows specified earlier and give an impression of field security implemented differently.

Potential Improvements

A noticeable improvement that could have been implemented was to have two different ‘Select approver’ pre-approval stages rather than one which would have enabled us to have two different lookup fields with different filter criteria to show just Group A and Group B approvers.

This would have made the business process more accurate, especially in the case of a recruit who might not have a good idea of the approvers belonging to a certain Group.

However, as per the company, they use the Kanban view to see their opportunities and it would have caused a lot of confusion to see all the different stages on the Kanban view.

Some of which can be irrelevant to the type of opportunities a sales agent might specifically be dealing with e.g. opportunities yielding below £30,000. Another improvement that could have been instated was to automate an email reminder to the sales agents if the approval of the opportunity is rejected.

Appendix A