Rollout your own limit dashboard

Spring 15 release brings some goodies as usual. One particular feature I liked is the REST API Limit Resource feature which will be in GA and will be available 24 hours after the scheduled release. I particularly like this feature, which I even sign up for a developer a preview a couple of months back, is because I'm annoyed with the system lack of dashboard page that allows me to track whether I'm almost hitting organisation limits. Simple requirement such knowing how many mail SingleEmail have been sent out requires you to contact Salesforce contact centre. Now it might be a product strategy from the San Francisco company as some of these limits (soft limits) can be increase by buying it in addition to the editions hard limits, or maybe just really not in the roadmap yet. We don't really know for sure but its good that developers and in some ways, administrators now has a way to check these limits without calling support.

Here are the limit information the the feature currently returns:

• Daily API calls
• Daily Batch Apex and future method executions
• Daily Bulk API calls
• Daily Streaming API events
• Streaming API concurrent clients
• Daily generic streaming events (if generic streaming is enabled for your organization)
• Daily number of mass emails that are sent to external email addresses by using Apex or Force.com APIs
• Daily number of single emails that are sent to external email addresses by using Apex or Force.com APIs
• Concurrent REST API requests for results of asynchronous report runs
• Concurrent synchronous report runs via REST API
• Hourly asynchronous report runs via REST API
• Hourly synchronous report runs via REST API
• Hourly dashboard refreshes via REST API
• Hourly REST API requests for dashboard results
• Hourly dashboard status requests via REST API
• Daily workflow emails
• Hourly workflow time triggers

How to normally check the limit usage

Before we delve into how we can expose the limit information, lets take a look first on how we can normally access it. I will use workbench here for the purpose of simplification but feel free to use any tool of your liking.

Basically, we just need to go to the REST Explorer section of Workbench. Then you type in then limit resource url /services/data/<version>/limits/, then choose the GET option and then click Execute button.

Note that this is only available for REST API version 29 and to users with "View Setup and Configuration" permission. The DataStorageMB and FileStorageMB limits will only show for users with if "Managed Users" permission. 

Rolling out your custom limit dashboard

Administrators wouldn't want to always execute a REST call just to see the limit usage for the environment. What is needed is a dashboard the shows the current usage versus the hard limit. Below is a simple Visual force page executing a JavaScript to retrieve the same limit information.

<apex:page>
    <script type="text/javascript">
        var xmlhttp = new XMLHttpRequest();
        var url = "/services/data/v32.0/limits/";

        xmlhttp.onreadystatechange=function() {
            if (xmlhttp.readyState == 4 && 
                xmlhttp.status == 200) {
                myFunction(xmlhttp.responseText);
            }
        }
        xmlhttp.open("GET", url, true);
        xmlhttp.setRequestHeader("Authorization", 
                                 "Bearer {!$Api.Session_ID}");
        xmlhttp.send();

        function myFunction(response) {
            var res = JSON.parse(response);
            var d = document.getElementById('result');
            
            // iterate to the object keys 
            // and display the property values
            Object.keys(res).forEach(
                function(key,index) { 
                    //key = the name of the object key 
                    //index = the ordinal position of the key within the object 
                
                    d.innerHTML += "<strong>" + key + "</strong><br/>" + 
                                  "Max: " + res[key].Max + "<br/>" + 
                                  "Remaining: " + res[key].Remaining + 
                                  "<br/><br/>";
        
            });
        }
    </script>
    <div id="result">
    </div>
</apex:page>

I will not explain the code in detail but as a high level, we did an HTTP get using JavaScript XMLHttpRequest object to the REST url /services/data/<version>/limits/, passing our session Id to authenticate and then iterating over the list of information returned by the call.

The sample screenshot is below:

We can include a lot of of other improvements to the page like changing the look and feel so that it would look better and to retry retrieving the information on a timed interval. I hope this post have help anyone.

Happy coding!

Using SoapUI to do SOAP calls to Salesforce

I've been involved on integration with Salesforce.com from and to other systems. One of the oldest protocol used on integrating with the system is using the SOAP protocol as it has a SOAP API that allows other systems to manipulate records. 

Personally, its worth while to have knowledge on how to consume the Salesforce SOAP method specially if you are working with an integrator who does not have prior experience integrating to Salesforce using the protocol. 

In the below examples I will be using SoapUI, an open source testing tool that supports not just SOAP but also other protocols such as REST and HTTP. I'll also be using the Salesforce partner wsdl but will provide alternative examples using the enterprise wsdl. For more information on the difference of the two, please take time to read this article.

The first thing to do is to download the Salesforce WSDL from Setup --> Develop --> API.

Once the WSDL is generated and download, we need to create a new SOAP project in SoapUI as depicted below.

Clicking the "Ok" will create the project as well as list the SOAP methods and samples (if "Create Request" checkbox is selected). Below is the generated project tree.

So let's starting creating our sample SOAP calls.

Partner login call

There are different ways of authenticating with Salesforce but for our example, we will use the login method that require to pass the user name and password to get a Session ID which is an encrypted value Salesforce pass back which is needed for succeeding calls.

Go to the login method from the SoapUI project tree and use or create a new request. Delete all of the values under <soapenv:Header> as we don't need to pass any value on the SOAP envelop. We will refer to this as the soap envelop header moving forward.

The request should be as follow (click here for the enterprise wsdl sample):

<soapenv:Envelope 
     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"     
     xmlns:urn="urn:partner.soap.sforce.com">
   <soapenv:Header>
   </soapenv:Header>
   <soapenv:Body>
      <urn:login>
         <urn:username>Salesforce User Name</urn:username>
         <urn:password>Password + security token</urn:password>
      </urn:login>
   </soapenv:Body>
</soapenv:Envelope>

From the request window, click the submit  icon to process the request. SoapUI will then attempt to do a SOAP call to Salesforce and returns a response below.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns="urn:partner.soap.sforce.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Body>
      <loginResponse>
         <result>
            <metadataServerUrl>
              https://na5.salesforce.com/services/Soap/m/30.0/00D700000008fqn
            </metadataServerUrl>
            <passwordExpired>false</passwordExpired>
            <sandbox>false</sandbox>
            <serverUrl>
              https://na5.salesforce.com/services/Soap/u/30.0/00D700000008fqn
            </serverUrl>
            <sessionId>Session ID</sessionId>
            <userId>005700000012RyAAAU</userId>
            <userInfo>
               <accessibilityMode>false</accessibilityMode>
               <currencySymbol>$</currencySymbol>
               <orgAttachmentFileSizeLimit>5242880</orgAttachmentFileSizeLimit>
               <orgDefaultCurrencyIsoCode>USD</orgDefaultCurrencyIsoCode>
               <orgDisallowHtmlAttachments>false</orgDisallowHtmlAttachments>
               <orgHasPersonAccounts>true</orgHasPersonAccounts>
               <organizationId>00D700000008fqnEAA</organizationId>
               <organizationMultiCurrency>false</organizationMultiCurrency>
               <organizationName>REMOVED</organizationName>
               <profileId>00e70000000sEkZAAU</profileId>
               <roleId>00E70000000olJBEAY</roleId>
               <sessionSecondsValid>7200</sessionSecondsValid>
               <userDefaultCurrencyIsoCode xsi:nil="true"/>
               <userEmail>REMOVED</userEmail>
               <userFullName>REMOVED</userFullName>
               <userId>005700000012RyAAAU</userId>
               <userLanguage>en_US</userLanguage>
               <userLocale>en_US</userLocale>
               <userName>REMOVED</userName>
               <userTimeZone>America/Los_Angeles</userTimeZone>
               <userType>Standard</userType>
               <userUiSkin>Theme3</userUiSkin>
            </userInfo>
         </result>
      </loginResponse>
   </soapenv:Body>
</soapenv:Envelope>

Note that I have removed a couple of information from the response. However, the most important thing to note from the response is the Session ID and the ServerURL which we will used in our succeeding examples.

Our SoapUI should look like below:

Partner create call

Now that we have a Session ID and Server URL, we need to create a new request using the create method. Go to the create method from our project tree and use or create a new request. Delete all of the values soap envelop header except for <urn:SessionHeader> where we will need to add the Session ID value from the login call.

The request should be as follow (click here to see create call using enterprise wsdl):

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:urn="urn:partner.soap.sforce.com" 
    xmlns:urn1="urn:sobject.partner.soap.sforce.com">
   <soapenv:Header>
      <urn:SessionHeader>
         <urn:sessionId>Session ID from Login Call</urn:sessionId>
      </urn:SessionHeader>
   </soapenv:Header>
   <soapenv:Body>
      <urn:create >
         <urn:sObjects>
            <urn1:type>Account</urn1:type>
            <Name>Sample Account (Partner)</Name>
         </urn:sObjects>
      </urn:create>
   </soapenv:Body>
</soapenv:Envelope>

Note that we have manually typed the type node (represents the SObject type) and Name (which is the API name of the standard Name field) above for the request.

Before submitting the request, we also need to change the submit endpoint using the Server URL login response.

Below is the response from the create call.

<soapenv:Envelope 
     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"    
     xmlns="urn:partner.soap.sforce.com">
   <soapenv:Header>
      <LimitInfoHeader>
         <limitInfo>
            <current>2</current>
            <limit>15000</limit>
            <type>API REQUESTS</type>
         </limitInfo>
      </LimitInfoHeader>
   </soapenv:Header>
   <soapenv:Body>
      <createResponse>
         <result>
            <id>0017000001ExlcFAAR</id>
            <success>true</success>
         </result>
      </createResponse>
   </soapenv:Body>
</soapenv:Envelope>

Note that the <createResponse> node will have the result of the call. The <id> will contain the record Id for the record you are creating and the <success> will tell whether the call is successful or not.

The SoapUI should look like below:

Partner update call

Using the same Session ID, Server URL and the record Id from the create call, use or create a new update request from the SoapUI project tree and delete all the values from the soap envelop header except for the SessionHeader. The request should look as below (click here to see update call using enterprise WSDL):

<soapenv:Envelope 
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:urn="urn:partner.soap.sforce.com" 
    xmlns:urn1="urn:sobject.partner.soap.sforce.com">
   <soapenv:Header>
      <urn:SessionHeader>
         <urn:sessionId>Session ID from Login Call</urn:sessionId>
      </urn:SessionHeader>
   </soapenv:Header>
   <soapenv:Body>
      <urn:update>
         <!--Zero or more repetitions:-->
         <urn:sObjects>
            <urn1:type>Account</urn1:type>
            <Name>Sample Account (Partner) Updated</Name>
            <urn1:Id>0017000001ExlcFAAR</urn1:Id>
         </urn:sObjects>
      </urn:update>
   </soapenv:Body>
</soapenv:Envelope>

The response is below:

<soapenv:Envelope 
     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"    
     xmlns="urn:partner.soap.sforce.com">
   <soapenv:Header>
      <LimitInfoHeader>
         <limitInfo>
            <current>3</current>
            <limit>15000</limit>
            <type>API REQUESTS</type>
         </limitInfo>
      </LimitInfoHeader>
   </soapenv:Header>
   <soapenv:Body>
      <updateResponse>
         <result>
            <id>0017000001ExlcFAAR</id>
            <success>true</success>
         </result>
      </updateResponse>
   </soapenv:Body>
</soapenv:Envelope>

The SoapUI should look like below:

Partner upsert call

The upsert call is not much different with the update call except that there is an <externalIDFieldName> node that is required to have the API name of the field marked as external Id or the Id field. The field must be part of the request.

Below is the sample request using the same Session ID , Server URL and record Id which was used as the external id fr(click here to see update call using enterprise wsdl):

<soapenv:Envelope 
     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"  
     xmlns:urn="urn:partner.soap.sforce.com" 
     xmlns:urn1="urn:sobject.partner.soap.sforce.com">
   <soapenv:Header>
      <urn:SessionHeader>
         <urn:sessionId>0Session ID from Login Call</urn:sessionId>
      </urn:SessionHeader>
   </soapenv:Header>
   <soapenv:Body>
      <urn:upsert>
         <urn:externalIDFieldName>Id</urn:externalIDFieldName>
         <!--Zero or more repetitions:-->
         <urn:sObjects>
            <urn1:type>Account</urn1:type>
            <!--Zero or more repetitions:-->
            <Name>Sample Account (Partner) Upserted</Name>
            <Id>0017000001ExlcFAAR</Id>
         </urn:sObjects>
      </urn:upsert>
   </soapenv:Body>
</soapenv:Envelope>

Below is the response.

<soapenv:Envelope 
     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
     xmlns="urn:partner.soap.sforce.com">
   <soapenv:Header>
      <LimitInfoHeader>
         <limitInfo>
            <current>4</current>
            <limit>15000</limit>
            <type>API REQUESTS</type>
         </limitInfo>
      </LimitInfoHeader>
   </soapenv:Header>
   <soapenv:Body>
      <upsertResponse>
         <result>
            <created>false</created>
            <id>0017000001ExlcFAAR</id>
            <success>true</success>
         </result>
      </upsertResponse>
   </soapenv:Body>
</soapenv:Envelope>

Here is the SoapUI screenshot:

Most of the other SOAP methods follow the same request sample. However there are other functionalities such as running assignment rules, changing the debug log levels that are controlled via the envelop header.

Hopefully the example above can help anyone starting to learn integrating to Salesforce.com. :-)

Sample Salesforce SFDC Enterprise upsert

This is a sample SOAP Upsert using Enterprise WSDL. Note that we only passing the session Id  on the header information since we don't need the others and that the envelop must be posted to the ServerURL you got from the login call as per described in this blogpost. In addition, we need to put a value on the <externalIDFieldName> node with the field API name of the objects external Id. In this example, I used the Salesforce standard Id field.

<soapenv:Envelope 
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:urn="urn:enterprise.soap.sforce.com" 
    xmlns:urn1="urn:sobject.enterprise.soap.sforce.com"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Header>
      <urn:SessionHeader>
         <urn:sessionId>Session ID from login call</urn:sessionId>
      </urn:SessionHeader>
   </soapenv:Header>
   <soapenv:Body>
      <urn:upsert>
         <urn:externalIDFieldName>Id</urn:externalIDFieldName>
         <urn:sObjects xsi:type="Account">
            <Id>0017000001ExVRDAA3</Id>
            <Name>Sample Account (Enterprise) Upserted</Name>
         </urn:sObjects>
      </urn:upsert>
   </soapenv:Body>
</soapenv:Envelope>

Below is the sample SOAP response:

<soapenv:Envelope 

     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 

     xmlns="urn:enterprise.soap.sforce.com">
   <soapenv:Header>
      <LimitInfoHeader>
         <limitInfo>
            <current>11</current>
            <limit>15000</limit>
            <type>API REQUESTS</type>
         </limitInfo>
      </LimitInfoHeader>
   </soapenv:Header>
   <soapenv:Body>
      <upsertResponse>
         <result>
            <created>false</created>
            <id>0017000001ExVRDAA3</id>
            <success>true</success>
         </result>
      </upsertResponse>
   </soapenv:Body>
</soapenv:Envelope>

NOTE:

The <createResponse> node will have the result of the call. The <id> will contain the record Id in SFDC for the record you are creating and the <success> will tell whether the call is successful or not.

*I noticed that SoapUI 5.0.0 does not automatically add the xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance". This is important when you are setting the object type <urn:sObjects> tag.

Sample Salesforce Enterprise SOAP update

This is a sample SOAP Update using Enterprise WSDL. Note that we only passing the session Id  on the header information since we don't need the others and that the envelop must be posted to the ServerURL you got from the login call as per described in this blogpost.

<soapenv:Envelope 
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:urn="urn:enterprise.soap.sforce.com" 
    xmlns:urn1="urn:sobject.enterprise.soap.sforce.com"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Header>
      <urn:SessionHeader>
         <urn:sessionId>Session ID from login call</urn:sessionId>
      </urn:SessionHeader>
   </soapenv:Header>
   <soapenv:Body>
      <urn:update>
         <urn:sObjects xsi:type="Account">
            <Id>0017000001ExVRDAA3</Id>
            <Name>Sample Account (Enterprise) Updated</Name>
         </urn:sObjects>
      </urn:update>
   </soapenv:Body>
</soapenv:Envelope>

Below is the sample SOAP response:

<soapenv:Envelope 
     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"      
     xmlns="urn:enterprise.soap.sforce.com">
   <soapenv:Header>
      <LimitInfoHeader>
         <limitInfo>
            <current>10</current>
            <limit>15000</limit>
            <type>API REQUESTS</type>
         </limitInfo>
      </LimitInfoHeader>
   </soapenv:Header>
   <soapenv:Body>
      <updateResponse>
         <result>
            <id>0017000001ExVRDAA3</id>
            <success>true</success>
         </result>
      </updateResponse>
   </soapenv:Body>
</soapenv:Envelope>

NOTE:

The <createResponse> node will have the result of the call. The <id> will contain the record Id in SFDC for the record you are creating and the <success> will tell whether the call is successful or not.

*I noticed that SoapUI 5.0.0 does not automatically add the xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance". This is important when you are setting the object type <urn:sObjects> tag.

Sample Salesforce Enterprise SOAP create

This is a sample SOAP Create using Enterprise WSDL. Note that we only passing the session Id  on the header information since we don't need the others and that the envelop must be posted to the ServerURL you got from the login call as per described in this blogpost.

<soapenv:Envelope 
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:urn="urn:enterprise.soap.sforce.com" 
    xmlns:urn1="urn:sobject.enterprise.soap.sforce.com"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Header>
      <urn:SessionHeader>
         <urn:sessionId>Session ID from login call</urn:sessionId>
      </urn:SessionHeader>
   </soapenv:Header>
   <soapenv:Body>
      <urn:create>
         <urn:sObjects xsi:type="Account">
            <Name>Sample Account (Enterprise)</Name>
         </urn:sObjects>
      </urn:create>
   </soapenv:Body>
</soapenv:Envelope>

Below is the sample SOAP response:

<soapenv:Envelope 
     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"    
     xmlns="urn:enterprise.soap.sforce.com">
   <soapenv:Header>
      <LimitInfoHeader>
         <limitInfo>
            <current>9</current>
            <limit>15000</limit>
            <type>API REQUESTS</type>
         </limitInfo>
      </LimitInfoHeader>
   </soapenv:Header>
   <soapenv:Body>
      <createResponse>
         <result>
            <id>0017000001ExVRDAA3</id>
            <success>true</success>
         </result>
      </createResponse>
   </soapenv:Body>
</soapenv:Envelope>

NOTE:

The <createResponse> node will have the result of the call. The <id> will contain the record Id in SFDC for the record you are creating and the <success> will tell whether the call is successful or not.

*I noticed that SoapUI 5.0.0 does not automatically add the xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance". This is important when you are setting the object type <urn:sObjects> tag.

Sample Salesforce Enterprise SOAP login

This is a sample SOAP Login using Enterprise WSDL. Note that we are not passing any header information here for the sake of example.

<soapenv:Envelope 
        xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:urn="urn:enterprise.soap.sforce.com">
   <soapenv:Header>
   </soapenv:Header>
   <soapenv:Body>
      <urn:login>
         <urn:username>replace this with our SFDC username</urn:username>
         <urn:password>password + security token</urn:password>
      </urn:login>
   </soapenv:Body>
</soapenv:Envelope>

Below is the sample SOAP response:

<soapenv:Envelope 
     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
     xmlns="urn:partner.soap.sforce.com" 
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Body>
      <loginResponse>
         <result>
            <metadataServerUrl>
               https://na5.salesforce.com/services/Soap/m/30.0/00D700000008fqn
            </metadataServerUrl>
            <passwordExpired>false</passwordExpired>
            <sandbox>false</sandbox>
            <serverUrl>
              https://na5.salesforce.com/services/Soap/u/30.0/00D700000008fqn
             </serverUrl>
            <sessionId>REMOVED</sessionId>
            <userId>005700000012RyAAAU</userId>
            <userInfo>
               <accessibilityMode>false</accessibilityMode>
               <currencySymbol>$</currencySymbol>
               <orgAttachmentFileSizeLimit>5242880</orgAttachmentFileSizeLimit>
               <orgDefaultCurrencyIsoCode>USD</orgDefaultCurrencyIsoCode>
               <orgDisallowHtmlAttachments>false</orgDisallowHtmlAttachments>
               <orgHasPersonAccounts>true</orgHasPersonAccounts>
               <organizationId>00D700000008fqnEAA</organizationId>
               <organizationMultiCurrency>false</organizationMultiCurrency>
               <organizationName>REMOVED</organizationName>
               <profileId>00e70000000sEkZAAU</profileId>
               <roleId>00E70000000olJBEAY</roleId>
               <sessionSecondsValid>7200</sessionSecondsValid>
               <userDefaultCurrencyIsoCode xsi:nil="true"/>
               <userEmail>REMOVED/userEmail>
               <userFullName>REMOVED</userFullName>
               <userId>005700000012RyAAAU</userId>
               <userLanguage>en_US</userLanguage>
               <userLocale>en_US</userLocale>
               <userName>REMOVED</userName>
               <userTimeZone>America/Los_Angeles</userTimeZone>
               <userType>Standard</userType>
               <userUiSkin>Theme3</userUiSkin>
            </userInfo>
         </result>
      </loginResponse>
   </soapenv:Body>
</soapenv:Envelope>

NOTE:

The following is important on your succeeding calls using SOAP

• sessionId: This is the value you would need to pass to succeeding SOAP calls as this proves that you are authenticated.
• serverUrl:  This will be the URL you will need to post succeeding SOAP calls.

please see my blogpost for doing SOAP integration using Partner WSDL.

Skip Logic using Custom Permission

On my blog post last June, we discuss about using custom settings for skipping execution of triggers, validation rules and workflow rules. Today we can achieve the same logic using a feature Salesforce.com release last Summer 14.

But first, what is custom permission? Custom Permission allows us to extend a profile and custom permission access by allowing us to create our own "permission" attribute and can be optionally associated with a connected app. It's a simple yet powerful feature that can be use on a custom or generic application.

Below I created 3 custom permissions via Setup --> Develop --> Custom Permission.

Checking custom permission assignment in Apex Trigger requires querying the data from three setup objects called SetupEntityAccess, CustomPermission and PermissionSetAssignment. I have created a utility class that can be used to check if a user is assigned to any of the above custom permissions as below. The class cache the assignment in a permission set Id/DeveloperName and Boolean key/value pair where passing an Id or the custom permission developer name can return TRUE (if its assigned) or FALSE (if not assigned).

public class CustomPermissionUtil {
    private static Map<String,Boolean> permissionMap;
    
    public static Boolean hasCustomPermAccess(String devName){
        Boolean hasCustomPerm = false;
        if(permissionMap==null){
            refreshCache();
        }
        
        if(permissionMap.size()>0){
            if(permissionMap.containsKey(devName)){
                hasCustomPerm = permissionMap.get(devName);
            }
        }
        
        return hasCustomPerm;
    }
    
    public static Boolean hasCustomPermAccess(Id permId){
        Boolean hasCustomPerm = false;
        if(permissionMap==null){
            refreshCache();
        }
        
        if(permissionMap.size()>0){
            if(permissionMap.containsKey(permId)){
                hasCustomPerm = permissionMap.get(permId);
            }
        }
        
        return hasCustomPerm;
    }
    
    private static void refreshCache(){
        permissionMap = new Map<String,Boolean>();
        
        Set<Id> permissionIds = new Set<Id>();
        
        Map<Id,CustomPermission> customPermMap = new Map<Id,CustomPermission>(
                [SELECT Id, DeveloperName FROM CustomPermission 
                WHERE NamespacePrefix = null]);
        for(CustomPermission permObj : customPermMap.values()) {
            permissionMap.put(permObj.DeveloperName, false);
            permissionMap.put(permObj.Id, false);
            permissionIds.add(permObj.Id);
        }
        
        for(SetupEntityAccess setupEntObj : [SELECT SetupEntityId FROM 
                               SetupEntityAccess WHERE SetupEntityId in 
                               :permissionIds AND ParentID IN (SELECT 
                               PermissionSetId FROM PermissionSetAssignment 
                               WHERE AssigneeID = :UserInfo.getUserId())]){
                                                    
            permissionMap.put(setupEntObj.SetupEntityId, true);
            permissionMap.put(customPermMap.get(setupEntObj.SetupEntityId).
                DeveloperName,true);
        }
    }
    
}

To use in a trigger, an IF-condition must be added on top of the trigger code as below.

trigger TestAccountTrigger on Account (before update) {
    
    if(!CustomPermissionUtil.hasCustomPermAccess('Skip_Trigger')){
    // body of trigger
    }
    
}

For validation rule and workflow rules, a $Permission global variable is available for use.

So which one is better to use for our use-case? Custom Settings or Custom Permission? Below are the pros and cons.

Custom Settings 
Pro:

• No SOQL required to retrieve the information (when using the custom settings method).
• Custom Label global variable for formula.

Cons:

• Bounded by Custom Setting data limit.
• Access is managed on the custom setting section.
• Data needs to be created on test classes.

Custom Permission 

Pro:

• Custom Permission global variable for formula.
• Assignment is aligned with how permission is given via Profile or Permission Set.

Cons:

• Requires SOQL query to retrieve assignment.

Personally, I would go and use custom permission rather than custom settings not just because its a new feature but because it aligns to how we manage permissions to user. I would like to think that future enhancements would be released for the feature as well. However, I would recommend my readers to vote to this idea so that custom permission can be access as a global variable in Apex Code the same way we access Custom Labels. 

Happy coding!