Implementing Approval Verification Processes

I have been invited again to post on the Microsoft Dynamics CRM Team Blog. The article can be reached here;
http://blogs.msdn.com/crm/archive/2009/01/12/implementing-approval-verification-processes.aspx

Today we welcome Microsoft Dynamics CRM MVP Umar Khan who is a Microsoft CRM Consultant. You can read more from Umar on his blog at https://umarkhan.wordpress.com.

In business processes, there are sometimes scenarios in which certain steps require approval, authorization or verification from specific users to move forward. Microsoft Dynamics CRM 4 can be customized to implement such Role based or User dependent processes. One such example could be the requirement of authorization if opportunity is of more than 10K USD. I will be suggesting few options for implementing such a feature.

Note: This article assumes that reader is familiar with CRM Customizations, the CRM SDK and web services.

First step will be creating a new bit (or picklist) attribute in the entity and then adding it on the form. Bit field can either have true or false value but existing records will have null value in the new bit field. If approval field has false value then it means current record is not approved yet, else if it has true value then it means it is approved. Another option can be to use the existing status field for approval and unapproval by adding new values in picklist of status reason field. Simplest solution will be to depend upon the users themselves to control the updating of the approval field. All the users will have access to update the approval field but normal CRM users may not try to change the value of approval field and only Manager User change the value to approve or unapproved as per their decision.

But better solution will be to enforce the process and making sure that unauthorized user could not change the value of approval field. So by using web service call in “on load” event of the form, we can determine the current login user and then can make the approval field enabled or disabled depending upon the current login user’s rights.( How to Control Update Access for a Field )

There are some other options also available for implementing this process with more interactive interface;

a. Using JavaScript’s Confirm box:

1. After creating a field on entity to store the Approval or Unapproval status, add it on form and make it read only. By default its value will be false.

2. Add an “Approval” button on the toolbar of the entity window. A click on it will trigger the approval functionality.

3. When user clicks this button, using web service, check if the current login user is the authorized person to give the approval.

4. If it is not then alert the message that “You are not authorize to approve.”

5. If it is the authorized person then show “Confirm” box for user input.

  1. if ( confirm(“Please approve the credit facility for the Account.”) )
  2. { alert (“Approved”);}
  3. else
  4. { alert (“Unapproved”);}

JavaScript: Confirm box

6. If OK is pressed then make the approve status field to True otherwise its value will be False. Using JScript, you can enable or disable fields on the form depending upon the approval status.

Note: JavaScript’s “Prompt” box can be used if you want the user to also pass some important value before moving further.

JavaScript: Prompt box

JavaScript solution is suitable when requirement is for only approval and unapproval. If end user needs to perform more actions than most probably the second option will be better.

b. Model window ASPX web form:

ASPX web form can be used to give CRM user more options then only Ok and Cancel. Basically an ASPX page can be developed to be shown in model window for user input. A modal dialog box retains the input focus while open. The user cannot switch windows until the dialog box is closed. Opportunity Close window is an example of this form. This ASPX page development will involve good understanding of .net and CRM SDK and it will be hosted on Web Server. This model window may open on click of the “Approval” toolbar button. Steps will be almost same as JScript Prompt box. In case CRM Users are using Outlook offline client, then this ASPX page is required to be hosted in all the client machines also to make this feature functional in case of offline mode.

c. CRM Workflow:

CRM workflows are one of the mostly used solutions for the approval feature. Develop “on demand” workflow rule which is only accessible to authorized users. A complex authorization process can be easily implemented in CRM workflows. Workflows will mostly give solution without involving coding and they will be easy to manage and deploy. Workflows can also be triggered on the click of a toolbar button with the help of some JScript. The disadvantage in this solution is that it will take few seconds before workflow is executed and if form is still open then it will not automatically refresh to reflect the changes on the form. User needs to manually refresh the page to see the changes like change of value in approval field. Sometimes, changes are not required to be seen immediately; in those cases this solution is ideal.

CRM Workflow window

If you have some specific scenarios with different solutions, we’d love to hear from you.

Cheers,

Umar Khan

Advertisements

Recursive Workflow, Recursive Reminders

Manual Workflows  of Microsoft CRM 3 can be called recursively to achieve some new possibilities. Recursive Reminders are one of them.
 
If requirement is something like this that send reminder, if opportunity is open even after 7 days of its creation date. Ok. No problem. It can be easily developed. But if it is also added in the requirment that keep reminding after every 7 days if opportunity is open, than stop, we have to think.

There is a solution, a very simple one, create a recursive manual workflow.

You will need to create two workflows. One manual WF and another one on Create event for the sole purpose of calling the manual workflow.
Let’s first create manual workflow.

recursive-workflow-recursive-reminders-1.jpg

recursive-workflow-recursive-reminders-2.jpg

Note: If current WF is not saved than its name will not appear in the list of the sub processes. You will once need to save the manual WF and than open it again to add the action of calling sub process.

Now you need to create another WF on Create event of the Opportunity in which you will just call the manual WF.

recursive-workflow-recursive-reminders-4.jpg

Remember to activate both the workflows. Your reminders are working now.