It is a common business requirement among any kind of business which uses Dynamics CRM application that “We need some kind of manager approval process in place of our sales pipeline or contract management or service lifecycle”. Detailing it further, at some point of stage in our sales or other pipeline, we all need respective managers approval in order to proceed ahead of the pipeline. This blog provided 2 alternative designs to achieve manager approval:


1.    Business Process Flow

If you are already using a BPF as part of your business pipeline for an entity, then you can easily incorporate this design as part of your business requirement.

First step is to create 3 new fields

  1. Approval Manager: This is a lookup field to user entity in CRM. Also enable field security profile on top of this field so that only privileged users can edit or view it.
  2. Manager Approved: This is a 2 optionset field with default option set to NO. This field has field security profile enabled on it. It is a required field on BPF.
  3. Approval Date: This is a date time field in CRM. And it is locked & required field on BPF.

Second step is to add these 3 fields to any existing BPF stage or add a new stage (Manager Approval) to your BPF with above 3 fields as part of that stage.

Now create 2 field security profiles in CRM:

  1. Approval admin group: Add the above 2 field level security fields approval manager & manager approved to this group with complete privileges on read, update and create permissions. Only add those users to this group who are considered as admins of your business and who have the privilege to overwrite existing data in these 2 fields.
  2. Approval Manager Group: Add the above 2 field level security fields to this group with create, read and update permissions set to YES for “Manager Approved” field and only read permission set to YES for “Approval Manager” field. Add all the required managers who needs to approval any sales orders or service contracts to this group.

Third step is to populate the manager field with a specific user. Create a new synchronous workflow which should be registered on Start of “Manager Approval” BPF stage (you can run the workflow when someone enters the BPF stage by registering the workflow on start of BPF stage). The workflows picks up the owner of the current record and will populate “Approval Manager” field with his manager (you must list the manager of the current record’s owner in CRM under user entity). However, you are always open to customize and create your own CRM element/process on how to populate this “Approval Manager” field.

After entering this stage, only users who are part of the Approval Manager field security group can see the data in Approval Manager field and update the Manager approved field to YES. For other users in CRM, these both fields appears to be locked and when they try to move to next stage it shows an error notification “You needs to fill in the required fields before moving to next stage”.

Fourth step is to write a java script which will validate if the logged in user who checked “Manager Approved” field to YES is same as the one listed in “Approval Manager” lookup field. If both are not same, then raise an error dialogue. The reason behind this validation is to prevent any user who is part of Approval Manager group from checking in “Manager Approved” field to YES except the actual manager who is listed in “Approval Manager” lookup field.

Register the JS script on change of “Manager Approved” field:

function Manager_Approval() {
ManagerApproved_Value = Xrm.Page.getAttribute(“new_managerapproved”).getValue();
if (ManagerApproved_Value) {

var userSettings = Xrm.Utility.getGlobalContext().userSettings;
var currentUserId = userSettings.userId;
var SalesApprovalManager_Id = Xrm.Page. getAttribute(new_approvalmanager).getValue();

                if (currentUserId && SalesApprovalManager_Id && SalesApprovalManager_Id[0].id == currentUserId) {
                    var confirmStrings = { text: "Please confirm your approval.", title: "Sales Manager Approval Confirmation" };
                    var confirmOptions = { height: 200, width: 450 };
                    Xrm.Navigation.openConfirmDialog(confirmStrings, confirmOptions).then(
                        function (success) {
                            if (success.confirmed) {
                                Xrm.Page.getAttribute(new_approvaldate).setValue(new Date());                                
                            else {
                                // Do nothing
                else {
                    Xrm.Page.ui.setFormNotification("You are not listed as the 'Approval Manager' on this Contract.", "ERROR", "managerapprovalerror");

If the logged in user is same as the manager listed in “Approval Manager” field, it will display a confirm dialog after which it populate the “Approval Date” field to current date.

Fifth step is to develop a business rule which will check if created on field has data and locks the “Approval Date” field in BPF.

This is the first design of manager approval process through BPF. Any sales person or CRM user wont have access to 2 field level security fields and thus cannot advance the BPF to next stage as “Manager Approved” and “Approved Date” fields are mandatory as part of that BPF. Any manager who is part of the approval manager group cannot check the “Manager Approved” field because the JS will validate if the current logged in user is same as the user listed in “Approval Manager” lookup field and throws an error notification if both aren’t same. Therefore, only the manager listed in “Approval Manager” lookup field can approve and advance to next stage of BPF. Neither sales person nor any other peer managers can approve it.

One exception is that users who are part of approval admin group have read and update level privilege to both the fields. So, they can even change the “Manager approved” and “Approval Manager” fields value. The reason behind this provision is that if managers are OOO or left the company, admin should be able to update “Approval Manager” field with some other manager who is currently active.


This is alternate design when you are not using a BPF for the current sales or service pipeline where you require to incorporate manager approval process. Once you reach to that point of pipeline which requires manager approval, then trigger a synchronous workflow which would create a task (with regarding set to current CRM record), owner of task should be set to the manager of the current CRM record’s owner (or you can select task owner as per your business requirement).

Now create a separate dashboard for all managers and show only tasks which are in their basket. That way, manager can refresh the dashboard to see all pending tasks to him and can approve/reject the request. Create a new status reason on the entity “Pending Approval” to indicate that the record status is currently waiting to be approved by manager. Also if you want no one to edit the record during this status, write a JS which would lock all the fields on form when status is “Pending Approval”.

function disableAllFields(){
            formContext.ui.controls.forEach(function (control, index) {
                var controlType = control.getControlType();
                if (controlType !== null && controlType !== "iframe" &&   controlType !== "webresource" &&
                    controlType !== "subgrid") {

Create a synchronous/asynchronous workflow on activity entity which needs to be triggered on status change of activity. Check if the activity type is task: If status is approved, then based on regarding lookup on task, update the status of regarding record from “Pending Approval” to In-Progress or customize it to perform necessary action as per your business requirement. Similarly, if rejected perform necessary actions as per your business requirement.

Now comes the main part where we have to make sure tasks created for a manager or team should only be visible to respective persons and not to anyone else using the CRM. Since task is one of the activity, we have to make sure everyone using CRM has only user level read write permissions on activity entity, so they can approve/reject tasks that are owned by them rather than some other user in CRM. This can be the major disadvantage of this design as restricting security privilege on task entity would reflect on other activities (like email, phone call, fax etc.) as we might want all users in CRM to be able to view every other email or any activity in CRM. Unfortunately, there is no workaround this problem as if we try to create a new activity type “Manager Approval”, but still the security for newly created activity type should still be managed with default activity entity security.


This is the latest and optimal solution any developer/non-developer can easily implement “Manager Approval” process within dynamics CRM. We can easily inter link CRM with Microsoft flows to achieve our approval process within business pipeline. There are 2 ways using which we can achieve this using flows:

  1. Email with options: There is a ‘Send email with options’ block available under Outlook where under user options field we can configure Approve/Reject options. This would send email to manager with 2 buttons: approve, reject. Next there is a condition block which will check selected option and perform necessary task. This is the simplest way of implementing Approval Process and can easily fit into any business pipeline. Once an email is sent out to manager, the flow will be in waiting status till it receives a response from the user after which it executes tasks in Yes or No condition or a max 30 days.


Approval Flows: There is another type of flow which is basically designed only for approval tasks. You can configure it somewhere similar to above email task but the user will get approval requests under Approval tab present when you open flows from office instead of getting an email. I would leave this to user to get his hands dirty to incorporate approval flows in your business pipeline.

FYI, starting from 2018 flows have become instance specific. So if you create flows pointing to dev instance in your development organization, after deploying into UAT or production, please make sure to change the connection to point to UAT or prod instance in their respective organization.