Dynamic Approval Process in Salesforce

Dynamic Approval Process



Dynamic Approval Process in Salesforce: Allocate the approvers dynamically to the record. Populate the approvers in the user lookup fields in the record.
In static approval process, we have to define the approvers in the approval process. Meaning whenever the record matches the approval process condition and approval process fires and associate the record to the approver which we define in approval process.




Always we cannot achieve business criteria with static approval process, meaning we have conditions like record should be routed to different approvers based on region, country or with some other criteria. We have to write one static approval process for each condition.

So to avoid multiple static approval process for the same requirement with same kind of implementation we will go for dynamic approval process.
– This process is full of apex and implementation is somewhat tricky but very powerful and useful for the huge projects.
– We have to write apex (triggers) to populate the approver in the record lookups.
– To achieve dynamic approval process we have to create one new object (approval matrix), which is useful to define all the conditions (region, country, etc…) and the approvers.

So once user clicks on SUBMIT button. We should fires apex code and check what and all the approval matrix matches to the record and we will take the approvers from the approval matrix and populate the approvers into the user lookups in the record, then we will fire the approval process. Inside approval process we have to define the steps like route process instance to approvers.




Example: Create an approval process on opportunity object, should be routed to base on Country. (Let say we have almost 200 countries in our project)

Steps to Implementation of dynamic approval process
1. Create User lookup fields and one picklist field (Status__c and values are Open, Submitted, Approved and Rejected).
2. Create an Approval process on Opportunity Object with Entry criteria is Status equal to Open.

3. Create one new Object called Approval Matrix to define all the conditions
4. Execute the below code on submit button.




public class OpportunityApprovalMatrix{
public static list<Approval.ProcessResult> ApprovalMatrixMatch(Set<Id> OpportunitySet){
List<Opportunity> updatedOpptyList = new List<Opportunity>();
Set<String> countrySet = new Set<String>();
List<Id> OpptyIds = new List<Id>();
Map<Id,Approval_Matrix__c> approvalMatrixMap=new Map<Id,Approval_Matrix__c>();
List<Opportunity> opptyList = [SELECT Id,Name,country__c,status__c,Approver1__c,Approver2__c FROM Opportunity where Id IN:OpportunitySet];
for(Opportunity opptyRec :opptyList){
opptyRec.Approver1__c = ”;
opptyRec.Approver2__c = ”;
countrySet.add(opptyRec.Country__c);
}
List<Approval_Matrix__c> approvalMatrixList = [SELECT country__c,Approver1__c,Approver2__c from Approval_Matrix__c where Country__c IN :countrySet];
for(Opportunity opptyRec :opptyList){
for(Approval_Matrix__c approvalMatrix :approvalMatrixList ){
if(opptyRec.country__c == approvalMatrix.country__c){
opptyRec.Approver1__c = approvalMatrix.Approver1__c;
opptyRec.Approver2__c = approvalMatrix.Approver2__c;
opptyRec.status__c = ‘Open’;
updatedOpptyList.add(opptyRec);
OpptyIds.add(opptyRec.Id);
}
}
}
update updatedOpptyList;
list<Approval.ProcessSubmitRequest> submitOpptyList = new list<Approval.ProcessSubmitRequest>();
for(Id oppId: OpptyIds){
Approval.ProcessSubmitRequest req = new Approval.ProcessSubmitRequest();
req.setComments(‘Submitting request for approval.’);
req.setObjectId(oppId);
submitRequestList.add(req);
}
Approval.process(submitRequestList);
}
}



Notes:
– This code only checks country level, if business requirement has many conations with different objects related to opportunity then we create one more object child to approval matrix and add all the conditions there.
– We can implement many approvers you need and levels as well in this process
– We can assign to the group of user (Queue instead on single user) also in this process.
– In this process we can get many matching record with our criteria, so we can add couple of fields in approval matrix like “threshold” and need to modify the logic based on this. Meaning if there are three matrix are matched for the opportunity then we can filter based on Threshold values which is maximum.
– Some cases we won’t find any matrix matches, in this case we can create default matrix. If any match is not found then we can route to this matrix.





About Sharing Rules in CRM software Salesforce

Sharing Rules in CRM software Salesforce




Rules are basically to provide the additional access on records to the specified users via Roles, Public Groups, Profiles and particular users.




How many ways sharing is happening?
– Organization-Wide Defaults
– Role Hierarchy
– Sharing rules
– Apex programming

1. Organization-Wide Defaults:
This setting is applicable for whole org not for single group or single person. And data will share to others based on the “Default Sharing Settings”.

We have different types of OWD setting:
Private: Whenever the OWD setting is Private, no one can see other data, means Opportunity is set to private and I created one opportunity in the org, no body have access on that record.
Public Read/Write: Whenever the OWD setting is Public Read/Write, everyone get access on every record with read and write record.
Public Full Access: Whenever the OWD setting is Public Full Access, everyone get access on every record with full access.
Public Read/Write/Transfer: Everyone get the access on every record with read, write and transfer access on that record.
Controlled by Parent: This setting is enabled only for child records (master details), everything is controlled by its master (parent) record.

2. Role Hierarchy(Grant Access Using Hierarchies):
– Sharing will get based on role hierarchy, means if I (SalesRep) create one opportunity record and my manger will get access on that record.
Setup -> Security Controls -> Sharing Settings -> Edit -> Grant Access Using Hierarchies
– By Default standard objects doesn’t have edit option on Grant Access Using Hierarchies.
– If we uncheck for the custom object then no body get the access on those records.




3. Sharing Rules:
If we want to share the records with specified groups or roles, then we can user criteria based rules.
Setup -> Security Controls -> Sharing Settings -> Sharing rules -> click on new -> create.
We have two types here
a. Based on record owner: We can provide which user’s records to whom and provide the access to what level like read only or read/write.

CRM Software 1

b. Based on criteria: Here we can create a criteria with object’s fields, like opportunity name contains with specified string (Accenture).



CRM Software 2

4. Apex programming: We can share the records in apex code to the specified groups, roles and users. First three methods are useful the sharing is at the org level and group’s level even to the individual users but not on action performed on the record.
Example:
Owner has changed to someone and get the READ access to the previous owner.
Note: we cannot achieve this one with first 3 methods. So we will go for trigger and write apex programming.
trigger OpportunityShare on Opportunity ( after update){
List<OpportunityShare> opptyShareList = new List<OpportunityShare>();
for(Opportunity oppty: trigger.new){
if(oppty.ownerId != trigger.oldMap.get(oppty.id).ownerId){
OpportunityShare opptyShare = OpportunityShare();
opptyShare.UserOrGroupId = trigger.oldMap.get(oppty.id).ownerId;
opptyShare.ParentId = oppty.Id;
opptyShare.AccessLevel = ‘READ’;
opptyShare.Rowcause = Schema.OpportunityShare.Rowcause.manual;
opptyShareList.add(opptyShare);
}
}
insert opptyShareList;
}