Salesforce Sandboxes – Key Player in Managing & Deploying Customization

Salesforce Sandboxes – Key Player in Managing & Deploying Customization

What is a Sandbox?

A Sandbox to a developer/administrator is like a playground for a child, it allows the developer/administrators to customize, play and configure the application development environment without affecting the actual production release versions. Sandboxes in Salesforce are used for app development, code management, version control, testing, and training without compromising the actual data and applications in your Salesforce production organization.

Types Of Sandboxes:

  Developer Sandbox Developer Pro Sandbox Partial Copy Sandbox Full Sandbox
What is their Usage? For coding and testing in an isolated environment For coding and testing in an isolated environment For  Testing environments and quality assurance task For testing environments and for performance and  load testing and staging
What do they include of  Production Environment? A copy of production organization’s configuration (metadata). A copy of production organization’s configuration (metadata). They have a larger storage limit than Developer sandboxes. A copy of production organization’s configuration (metadata), and a subset of production data as defined by a sandbox template. Replica of the production organization.
Licenses with which you can create Sandboxes  ·  Full Sandbox ·  PartialCopy Sandbox ·  Developer Pro Sandbox ·  Developer Sandbox · Full Sandbox · PartialCopy Sandbox · Developer Pro Sandbox · Full Sandbox · PartialCopy Sandbox · Full Sandbox

Sandboxes In SDLC Process

In a Salesforce app development life cycle, comes various phases of code development, unit testing, UAT etc. A simple example is: 

   In a case when different teams work on multiple areas simultaneously which finally have to be merged into a single organization, that is a single Production environment, with time the process becomes rather complex. It overcomes this a staging platform is created to repressively test the performance without affecting the production version. An example for the same is shown below: 

Managing Sandboxes For Release Management Process

Though there is no thumb rule or out of the box process defined on which organizations are dependent on handling their release management system. But still there are some points on sandboxes to be considered for running the process:

  • Make a practice to refresh the sandboxes after every release so that we make sure to leverage the new features and make sure that our environment is compatible with the new changes.
  • Also, it’s recommended to have a strategy to align the org releases with Salesforce releases, in order to reduce the efforts for refreshing sandboxes.
  • A Post Refresh Run List should be prepared and followed every time sandboxes are refreshed after a new release. Few things which should be included are:
    • Data Masking Needs
    • User Profile Modifications
    • Test Data Loads
    • Deployment Plan
    • Turn Off Scheduled Jobs
    • Manage Outbound Email.

Hope this would help you in getting an overview of what Salesforce sandboxes are.

Org Security Fundamentals

Org Security Fundamentals

It is no doubt that your org contains essential data which obviously you do not want to share with anyone. Ever imagined what can happen if your important information is leaked to the third party. They can play around with confidential information stored in your Salesforce org. It’s always better to take precautions in advance before it gets too late. So it’s high time to take precautions and make your org safe and avoid leaking of any important information. What we should make sure on our end is:

  1. User Access
  2. Connected Apps
  3. Custom Code
  4. Compromised Accounts


We should set some security principles to ensure the safety of your org. We can opt for following strategies:

  • Defense In Depth: It’s always good to have multiple layers of defense, since using any one layer has potential to fail. Therefore, if we have more layers then it is less likely that all the layers fail at same time. This principle should always be kept in mind.
  • Principle of least privilege: As word suggests, each entity should have the least number of privileges which they need to do their job. It helps to limit the damage.


(I) User and Access management

There is always need to make sure that users who need access to org only has access.

Here are different layers of access management:

  • Organization Access:
    This deals with organization access as a whole. We should make sure that whenever a person leaves a company, then he is de-provisioned. All access should be removed or taken away from him. To remove provision one can freeze user or deactivate them so org access can’t be misused.
  • Profiles:
    To remove the mess and for security purposes, we can grant access to users on the basis of their profiles. Also, we can give different permission to each object according to profiles. Field Level Security (FLS) controls the access of fields. While creating profiles assign them the specific set of roles.
    To set object level permission one should go to
    Quick Find Search >> Profiles >> Select a Profile >> Object level Permission
    Now you can provide read access or write access to the objects you want to give access of to that specific profile.

  • Sharing Default: It is a record level access.
    • Public vs. Private:  Public refers that if someone has access to all the objects in the org. Then automatically he has access to all the records for that object. The principle is to keep access to private, i.e.; a user has access to the objects according to role hierarchy.
    • Internal vs. external: By internal we mean that people who have the direct login to the org and external refer to the people coming through public facing communities, portals or external chatter users. If access is set to public and we have logged in through any portal, then there are high chances of any mishap.

(II) Health Check:

What if a user has access to the objects which are required by him but has very weak password? Ever thought??.. Yup, password plays a great role for providing security. We can protect this since Salesforce provides a way to make your org secure and safe. To perform health check:
Quick Search >> Health Check

Health check provides the following info:

Password length
Password history
Max invalid login attempts
Session timeouts, etc…
Health Check in a way or the other helps you to know the recommendations which Salesforce provides you in general.

(III) Two-factor authentication:

Many times passwords have proved to be very weak links which can easily be stolen. They act as a single point of failure. They can often be guessable. Some of us have tendency to use the same password for all the accounts which can be fatal sometimes.

One can use even Salesforce Authenticator to provide security. This app can be installed quickly. Once user logs in, they have to provide their password and one-time security token that is displayed on the app. This authenticator is not limited to only Salesforce.
Here are the steps to set up 2FA:

  1. Create 2FA permission set
  2. Assign to profiles
  3. At login, users will be invited to use 2FA

Hence, 2FA is perfect defense and proves a lot useful when it comes to providing security to the org.

(IV) IP whitelisting:

It is a very good practice to adopt. This is next level of defense. It is useful when we have scenarios such as where person don’t have device which provides 2FA or the security token. We can whitelist our static IP ranges in the org. We can set it for all the profiles including API users and integrations. To whitelist IP we can go to
Setup >> Network Access >> Put your static IP

By doing so, whenever you log in next time it will not demand any security token.

Now it’s a lot to help you, keeping your org safe and secure. Make sure always to follow best practices of defense before you get engrossed and start working. There is always someone who spies and just need that single chance to get all your information. It can be easy for him if you leave any loopholes in between. So please don’t give that single chance to anyone and take precautions before something fatal occurs. BE PROTECTIVE!!!….

Process Builder Vs Apex Triggers –  Choosing Between Automation Tools

Process Builder Vs Apex Triggers – Choosing Between Automation Tools

Process Builder Overview

Process Builder is a graphical representation of your process as you build it. It consists of

Criteria, Immediate and Scheduled Actions.

There are following things which can be done by process builder:

  • Create Records:In addition to updating a record, you can create a record and set the field values within the record.
  • Create Chatter Post:   Push a chatter update into Group or Feed.
  • Create an approval:Traditionally you needed a trigger to push a record into an approval process automatically. With Process builder, you can do this automatically based on criteria of the process.
  • Quickly consolidate Workflow:Quickly consolidate multiple workflow rules that in one process.
  • Call an Apex Class:You can now call an Apex class.

Trigger Overview

A trigger is the piece of code, that is executed Before or After a record is inserted or updated.

Usually, an APEX (code) based evaluation of criteria to set off a chain of events.These events execute the following types of operations

  • Insert
  • Update
  • Delete
  • Merge
  • Upsert
  • Undelete

In Apex Trigger you must have

  • Need to programming knowledge.
  • Need to design test classes to meet required test coverage.

But the main difference in process builder is you can not delete any record and can’t show any error. For these, you have to write Trigger code. For example:

Apex Limitations

  • Total number of records retrieved via SOQL queries                                       50,000
  • Total number of records retrieved by DML                                                        10,000
  • Total number of SOSL queries issued                                                                 100(Sync) | 200(Async)
  • Total number of SOSL queries issued                                                                 20
  • Total number of records retrieved by a single SOSL query                             2,000
  • Total number of DML statements issued                                                           150
  • Maximum number of characters for a trigger                                                   1 million

Process Builder Limitations

Editing: User can’t edit process once it has been activated.Therefore much like with flow, a new process needs to be created by cloning the initial process and making modifications to that cloned records.

Validation: Processes DO NOT  trigger Validation rule and can, therefore, invalidate data.

Deletion: The inactive process can’t be deleted for at least 12 hours after inactivation and do not appear in the Recycle Bin

Error Message: You can’t specify error messages when creating a process that doesn’t trigger as you can with flow or validation rules.

Formula help: When utilizing formula in criteria, there is no function help preview next to the syntax

Syntax: Pick-list fields are evaluated as text fields in process builder so that they won’t support any pick list formulas like ISCHANGED or ISNEW.

Apex Trigger Best Practices

  • Apex code must provide exception handling.
  • When query large data set use an SOQL FOR loop
  • Don’t use  SOSL and SOQL inside for loop.
  • Avoid Hard Coding IDs

Process Builder Best Practices

  • Check: To see if there are any workflows on the object doing the same things as the process. Also, verify no active Apex Trigger.
  • Avoid: Interviewing Apex, workflows, and processes together for the same process.
  • Document: Use the Description field to populate information such as when it was created by who and what the process does.Also, if processes work in conjunction with each other.
  • Test: And then test some more.Especially when you are first starting to use this please practice in the sandbox first.

There’s a lot of ability to impact users and data here if you do something wrong.

Now the question is Why Process Builder and how is it differ from trigger?

Process builder is fully customization. No code required here because we require lengthy logic and record to complete and fulfill the requirement or if we using process builder it will take less time to complete the requirement.

It has some benefits over the trigger:

Scenario I

Populate a lookup field on record update:

Traditionally required a trigger and It can be done easily with process builder.

The issue is Multi layer lookup logic- i.e. multiple / nested maps of related data required in the trigger.

          Process builder Trigger Traditionally been something that requires a Trigger. Process builder allows administrator can do this without the use of the code.
Scenario II

Set an Account Owner based on Record criteria

Process builder


Process builder can be used to assign ownership of records based on criteria in the object.
Scenario III

Post a chatter message based on record criteria

Process builder


Process builder can be used to post to chatter based on record criteria.
Scenario IV

Submit a Quote for Approval when Opportunity Stage= Proposal

Process builder Trigger Requires 2 Processes one to Update the Quote based on the opportunity stage and another to submit the quote for the approval when the criteria on the quote had been met.
Scenario V

Launch a Flow via record criteria vs a button or link.

Process builder


Process builder can be used to set record criteria and then launch a trigger ready flow.
Scenario VI

Clone an opportunity and change the field values

Process builder


Although Process builder can create a new record it can’t reference any of the values from the cloned opportunity without the use of a flow to capture the opportunity values.

Let’s have a look on given Process builder example :

Allow Contact to copy Current User Address in Contact Address and Account Billing Address only when any address field(Street, Country, state )is blank/NULL.

Step 1:

Make your Process-builder on Contact Object. Provide the criteria as Contact.Mailing Street (IS NULL = FALSE) and likewise for every address fields of Contact and Opportunity.

Step 2:

In “Immediate Action” give reference of Mailing Country to that of Contact.Owner.Country and Activate your Process as:

 Step 3:

Now test this process builder in your org by leaving any address field blank in your org.

Step 4:

After leaving Contact address blank here is the address which got autofilled same as contact’s owner address. Similarly you can test this for your Contact’s Account.

This is the reason for using Process builder rather than using Apex. But  in some scenarios you’ll have to write trigger code where process builder can’t be.

For example:

Create a checkbox field “SAME COUNTRY AS USER & COMPANY”. Throw error when a Contact is getting inserted in Salesforce having Country same as User country and Company country.

Above example can’t be done via Process builder since this do not allow you to throw error while inserting Contact.
Create  Checkbox field named “SAME COUNTRY AS USER & COMPANY” on Contact.

public class SameUserAndCompanyCountryContact {

public static void sameCountry(List<Contact> conList){

   User user = new User();

   user = [SELECT Id , Country , CompanyName from User where Id =:UserInfo.getUserId()];


Organization orgDetails = [ SELECT Name , Country , Address from Organization where Name =: user.CompanyName];


for(Contact con : conList) {

  if(con.MailingCountry == user.Country && con.MailingCountry == orgDetails.Country){

   con.addError('Country of Company and User is same as country of Contact trying to insert');

     con.Same_Country_As_User_And_Company__c = True;




trigger ErrorOnSameCountry on Contact (before insert){
  List<Contact> conList =;
     if(conList!=null) {


Although the usage of process builder over apex trigger or vice versa is dependent on various other factors too, such as:

  • Complexity Of Codes.
  • Programmatic Logics.
  • Rapid Iteration In Process Builder Can Be Challenging.
  • Unit Test Considerations.