In Chapter 6, we covered Lightning Flow, followed by an in-depth overview of Lightning Process Builder. We also examined approval processes using real-life examples.
This chapter consists of three parts. In part one, we look at limits of declarative customization and when to use programmatic development. In part two, we examine the application development life cycle, including different types of sandboxes and deployment tools. In part three, we study different deployment tools.
Limits of Declarative Development
As awesome as out-of-the-box point-and-click features are, there are limits to their reach. For example, we’ve studied formula fields, validation rules, Process Builder, page layouts, and so on. These point-and-click tools make Salesforce even better, allowing for easy configuration and maintenance. The problem arises when one gets requirements that cannot be solved using out-of-the box features.
Business Use Case 1
Pamela Kline is still working as a salesforce administrator at GoC. She has discovered that sales reps are deleting Closed Lost opportunities, which is detrimental to accurate analytics, to say the least! Pamela wants to make sure that sales reps are only allowed to delete those opportunities that are not Closed Won or Closed Lost.
How should Pamela meet this business requirement? If your answer is to use a validation rule, take a few minutes to ask yourself: when would the validation rule fire?
A validation rule fires only when a record is created or edited, not when a record is deleted. So now you know that using a validation rule is not the right thing to do. This use case also reveals limitations of declarative solutions and indicates that we need to go beyond point-and-clicks toward code.
Solution: Use an Apex Trigger
A trigger is executed during Data Manipulation Language (DML) database actions. For example, you can create a trigger on the Account object that executes whenever an Account record is updated or deleted. Therefore, triggers are called implicitly from a database action.
Business Use Case 2
Pamela Kline just received another requirement from her manager: whenever a new account is approved in Salesforce, create a pdf and send it to all contacts on that account.
Let’s take a few minutes to pause and think. Can we use a point-and-click solution here? If your answer is no, then you are on the right track!
Solution 1: Use a Visualforce Page
There are various solutions available in the market to generate pdf documents from Salesforce, but one thing they all have in common is that they are built using custom development.
Visualforce is a framework that includes a tag-based markup language. It allows you to build sophisticated, attractive, and dynamic custom user interfaces. You can use almost all standard web technologies—such as, CSS, jQuery, and HTML5—with a Visualforce page. This means you can build a rich user interface for any device, including mobile, tablet, and so on.
Solution 2: Use an AppExchange App
An alternative solution for Pamela to meet the requirement is to use Salesforce AppExchange apps such as Conga, Drawloop, Nintex, DocGen, and so on.
Are you wondering whether it is better to write Apex code or use apps from an AppExchange app? The answer should always depend on availability of time, budget, and ability to meet expectations.
The pros and cons of using Apex vs. leveraging AppExchange are as follows: custom development offers flexibility and a highly tailored solution to meet your specific needs and expectations in a highly granular manner. However, precisely because of this, it may take longer to build and, as a result, may cost more. AppExchange apps, on the other hand, may not meet all of your needs completely, but the apps will be up and running in hours, if not minutes. And, as a result, the end product may be cheaper. In such a situation, the best practice is to do a gap analysis and, based on the outcome, opt for one or the other solution.
Business Use Case 3
Pamela’s manager wants to provide detailed information about GoC’s potential customers, such as the weather in the city where a contact resides, to sales reps. To achieve this, GoC wants to display weather information based on a contact’s mailing city. What do you think? How should Pamela meet this requirement? Does Salesforce have any out-of-the box functionality to achieve this?
Solution: Use APIs
The answer to the previous question is, again, no. Unfortunately, Salesforce doesn’t have any out-of-the-box functionality to meet Pamela’s new requirement. So, the next question is: how should she meet the requirement? The answer is to use APIs. Yes, you got it right. API stand for application program interface. Web sites like Weather.com and AccWeather offer APIs so that developers can consume it and get the necessary information. Using APIs, it is possible to get weather information based on a customer’s mailing location.
Use Case Summary
As the three scenarios discussed in this section show, the best practice is to assess the pros and cons of declarative customization vs programmatic development. When you start working on real projects or with a Trailhead module (which I strongly suggest), you will master the art of deciding the best path forward—be it declarative, programmatic, or both!
Managing the Application Life Cycle
Application life cycle management entails end-to-end management of the software development process. The process includes governance, development, and operation. The software development life cycle (also known as SDLC), on the other hand, focuses primarily on the development phase.
Depending on your software development methodology (waterfall, Agile, or DevOps), application life cycle management might be split into separate phases or may be fully integrated into a continuous delivery process. Regardless, application life cycle management can be broken down into three category: governance, development, and operations.
Application Governance
Application governance teams start by gathering requirements from business stakeholders. Architects or solution designers create design documentation. The team then hands over the document to a development team for implementation.
Application Development
Next comes the development stage of application life cycle management. SDLC includes building, testing, releasing the build, releasing the test, and updating the application.
Application Operations
The third step in application life cycle management is operations. Operations includes deployment of the application and maintenance of the technology (which is not applicable in Salesforce).
Sandboxes
No sandbox comes with a developer org. Fortunately, we have used Salesforce’s free developer edition org to perform the tasks and exercises in this book. Because developer orgs are yours forever, you can keep practicing in such orgs even if you switch jobs.
This, however, is not the same when you work on your company’s org. You lose access to the org when you switch jobs. The advantage of being on a company’s Salesforce org is that you get access to at least one sandbox org. A sandbox is like a developer org except that it is affiliated with a company’s production org. A sandbox allows you to build and test business processes in a controlled environment without negatively impacting your production org. When you know your workflow rules, formula fields, and flows are working correctly in a sandbox, you can migrate them to your production org. You can create a sandbox from production or from a live org.
- 1.
Data storage: 5MB
- 2.
File storage: 20MB
- 3.
Salesforce licenses: 2
- 4.
A fewer number of API calls per day
When you start working on a real project, you may need a playground that allows you to work with more data and file storage, including more API calls per day, and more Salesforce licenses so you can create more than two user accounts, if required.
Sandbox Types and Their Differences
Sandbox Type | Refresh Interval | Storage Limit | Sandbox Template | What Copied |
|---|---|---|---|---|
Developer | 1 day | Data storage: 200MB File storage: 200MB | No | Metadata only |
Developer Pro | 1 day | Data storage: 1GB File storage: 1GB | No | Metadata only |
Partial copy | 5 days | Data storage: 5GB File storage: 5GB | Required | Metadata and sample data |
Full | 29 days | Same as your production org | Available | Metadata and all data (or sample data, if a sandbox template is being used), and chatter and history (optional) |
In Table 7-1, “metadata” means all configurations, Apex code, and all users. The refresh interval is often referred to when discussing sandboxes. To “refresh” a sandbox means to copy fresh information from other sandboxes or a production org.
Let’s look at the different types of available sandboxes more closely to help you choose the sandbox you would use for a project.
Developer Sandbox
Use a developer sandbox for isolated development purposes. In general, each organization has a good volume of such sandboxes. If you have seven developers working on a project, you can create seven developer sandboxes and give a separate sandbox to each developer. This eliminates the possibility of developers overwriting each others’ work. This sandbox includes your production org’s metadata (Apex, all users, and other configurations). A developer sandbox can be refreshed once a day.
Developer Pro Sandbox
Like the developer sandbox, the dev pro sandbox is used for development, Apex testing, and unit testing. A dev pro sandbox has a higher storage limit compared to a developer sandbox. Higher limits allow developers to test an application with larger data sets. Like a developer sandbox, a dev pro sandbox also includes your production org’s meta data (Apex, all users, and configurations). And it can be refreshed once a day too.
Partial Sandbox
A partial sandbox contains a subset of data from your production org. The specific subset of data you include in the partial sandbox is defined in a sandbox template. A partial sandbox can be used for user acceptance testing, regression testing, and so forth. Unlike a developer sandbox and a dev pro sandbox, a partial sandbox can only be refreshed every five days.
Full Sandbox
A full sandbox is a replica of your production org. It can contain metadata such as attachments, object records, as well as users. In addition, it can also include chatter and field history data. This type of sandbox is used for integration testing, staging, and production debugging. It can be refreshed every 29 days.
Setting up a Sandbox
- 1.
She navigates to Setup (gear icon) ➤ Setup ➤ Environments ➤ Sandboxes.
- 2.
- 3.Pamela enters the sandbox name Dev1 and, from the Create From drop-down, she selects Production, as shown in Figure 7-2.
Figure 7-2Entering sandbox details
- 4.Pamela clicks the Next button available in the Developer section. The system redirects Pamela to a new window to specify the Apex class she created previously from the SandboxPostCopy interface , which runs the scripts after each create and refresh for this sandbox. In this scenario, Pamela leaves this field blank, as shown in Figure 7-3.
Figure 7-3Entering Apex class details
- 5.
When done, Pamela clicks the Create button, which starts the sandbox creation process. This process may take from several minutes to several days, depending on the size and type of your org.
Accessing a Sandbox
We’ve seen how to set up a sandbox, but how do we access one? If you recall, the setup process didn’t ask us to set up a user account for our new sandbox!
- 1.
When the sandbox is ready, Pamela receives an e-mail from Salesforce to activate it, which she does.
- 2.
The username is the production username appended by the sandbox name. For example, Pamela’s production username is [email protected] and the sandbox name is Dev1. As a result, the sandbox username is [email protected].
- 3.
The password is the same as the production password.
Deployment
Pamela starts working in her newly created sandbox environment—the best way to configure or customize applications in Salesforce. She wants to understand how to move metadata to the production org from her sandbox.
- 1.
Change sets
- 2.
Packages
- 3.
Integrated development environments (IDEs; such as SFDX or Force.com)
- 4.
Force.com migration tool
- 5.
Third-party deployment tools (such as Copado)
Deploy Using Change Sets
Change sets are the easiest way to deploy metadata between connected orgs. For example, you can use change sets to deploy a metadata component from sandbox to production, sandbox to sandbox, and production to sandbox.
- 1.
Outbound change sets
- 2.
Inbound change sets
Outbound Change Sets
Outbound change sets can be used to send metadata components from a sandbox to production or to another sandbox.
- 1.
She logs in to the sandbox environment by opening the URL https://test.salesforce.com.
- 2.
She navigates to Setup (gear icon) ➤ Setup Home ➤ PLATFORM TOOLS ➤ Environments ➤ Change Sets ➤ Outbound Change Sets.
- 3.In the Change Sets section, she clicks the New button to create a new outbound change set, as shown in Figure 7-4.
Figure 7-4Creating a new outbound change set
- 4.This action opens a window, where she enters the following details:
Name: She enters a meaningful name for the outbound change set: Anniversary Date.
Description: Pamela writes some meaningful text so other developers and administrators can understand easily why this outbound change set was created in the first place.
Her screen looks like Figure 7-5.
Figure 7-5Entering change set details
- 5.
When done, Pamela clicks the Save button.
- 6.Next, Pamela must add all the metadata components she wants to deploy to the target org. To do so, she navigates to the Change Set Components section and clicks the Add button, as shown in the Figure 7-6.
Figure 7-6Outbound change set components
- 7.For Component Type, Pamela selects Custom Field. Then she selects the Anniversary Date field from the list, as shown in Figure 7-7.
Figure 7-7Adding components to the change set
- 8.
When done, she clicks the Add To Change Set button. If Pamela had wanted to add multiple metadata components to her outbound change set, she would have repeated steps 6 and 7.
- 9.Pamela uploads the change set to the target (production) org. To do so, she navigates to the Change Set Detail section and then clicks Upload, as shown in Figure 7-8.
Figure 7-8Uploading a change set
- 10.Pamela then selects the target organization from the Upload Details section and specifies where she wants to upload the change set. She selects Production, as shown in Figure 7-9.
Figure 7-9Selecting a target org
- 11.
When done, Pamela clicks the Upload button. If the upload is successful, she’ll see a message onscreen, as shown in Figure 7-10. Pamela also receives and e-mail from Salesforce, affirming her change set upload was successful.
Upload success message
Inbound Change Sets
- 1.
She logs in to her sandbox org by typing https://login.salesforce.com.
- 2.
She navigates to Setup (gear icon) ➤ Setup Home ➤ PLATFORM TOOLS ➤ Environments ➤ Change Sets ➤ Inbound Change Sets.
- 3.Then she navigates to the Change Sets Awaiting Deployment section, as shown in Figure 7-11. There she sees a list of inbound change sets (from sandboxes) that are awaiting deployment.
Figure 7-11Change sets awaiting deployment
- 4.
Pamela clicks the Anniversary Date inbound change set to view its details.
- 5.In the change sed Detail page, she notices two buttons: Validate and Deploy.
Validate: Pamela knows she can use this button to simulate an actual deployment. She would be able to view the success or failure messages received with an actual deployment.
Deploy: Pamela also knows that she uses the Deploy button to deploy the change set, which is done in a single operation. If the deployment is unable to complete (if it fails for any reason), the entire transaction is rolled back.
Pamela knows the best practice is to validate the change set first. When it’s successful, she would then deploy it.
- 6.
Pamela clicks Validate and notes that the simulated change set deployment is a success.
- 7.
She then deploys the change set by clicking Deploy. Pamela could select a test class to run, but she defaults and clicks Deploy. A warning message is shown that states that once a change set is deployed, it cannot be roll backed.
- 8.Pamela clicks the OK button and sees a message while the upload is in progress, as shown in Figure 7-12.
Figure 7-12Upload started
- 9.
When the upload is finished, whether a success or a failure, Pamela sees it listed in the Deployment History section, as shown in Figure 7-13.
Deployment successful
If the status of the change set is Deploy : Succeeded, the change set was deployed successfully.
Benefits of Using Change Sets
- 1.
There is a nice and tidy user interface to select changes that need to be deployed.
- 2.
Change sets can be validated before deployment.
- 3.
There is no need to install any other app to use change sets.
- 4.
It is easy to clone a change set.
- 5.
You can upload the same outbound change sets to multiple sandboxes or directly to a production org.
- 6.
Change set deployment is tracked with an audit trail!
Deploy Using Packages
Packages are containers that hold metadata components—either one component or group of components. Packages are mainly used to distribute to the org the app’s metadata components that are not connected. For example, you can use packages to deploy metadata components from a free developer edition org to one of your sandboxes or between two production orgs.
Types of Packages
Unmanaged Packages | Managed Packages |
|---|---|
You can view and modify Apex code and other components included in an unmanaged package. | It is not possible to view the code of components, such as Apex class or Apex trigger. |
Components can be edited in the organization after installation. | Components cannot be edited in the organization after installation. |
The source organization has no control over the package after it is installed in a customer’s org. Indeed, code within the package can be altered. | The code can only be altered in the source organization, where the package components were developed. |
Unmanaged packages are generally used for module distribution among developers or freelancers. | Managed packages are generally used by Salesforce AppExchange partners to distribute apps to their customers. |
The third type of package is called unpackaged. It refers to the components that exist natively in your organization, such as standard objects. Standard objects can go in an unpackaged package.
Points to Remember
- 1.
E-mail deliverability for new and refreshed sandboxes must be set to system e-mail only.
- 2.
You can create and manage sandboxes from the production org.
- 3.
In a full sandbox, record IDs are identical to the production org’s.
- 4.
You can’t use change sets to delete or rename components.
- 5.
When deploying using a change set, the system runs all tests of Apex code. If your overall coverage is less than 75%, you will not be able to deploy a change set.
- 6.
Change set deployment is tracked by an audit trail, which means you can check which components were deployed and when.
- 7.
Use packages when you want to distribute your metadata components to customers across the globe.
- 8.
To deploy metadata components through any tools requires system administrator permission.
Hands-on Exercises
- 1.True or False? It is possible to modify a trigger directly in a production org.
- a.
True
- b.
False
- a.
- 2.Which deployment tool activity is tracked by an audit trail?
- a.
Change set
- b.
Force.com IDE
- c.
Package
- d.
Force.com Workbench
- a.
- 3.Dennis Williams, a system administrator at GoC, created an application in his free developer org. Now he wants to share the application with his peers so they can use the application without seeing any code, and can provide their feedback. Which of the following deployment strategies Dennis should use?
- a.
Change sets
- b.
Managed packages
- c.
Unmanaged packages
- d.
SFDX
- a.
- 4.Dennis Williams receives a requirement to create a sandbox that brings all Lead records from production. GoC has 25,000 leads at the moment. Which sandbox should Dennis use?
- a.
Developer
- b.
Developer pro
- c.
Partial copy
- d.
Full
- a.
- 5.Dennis Williams receives a requirement to create a sandbox for regression testing. GoC just completed an integration with one of the leading banks in the United States and is planning to start integration testing, which may create millions of record. Which of the following sandboxes should Dennis use?
- a.
Developer
- b.
Developer pro
- c.
Partial copy
- d.
Full
- a.
Summary
In this chapter, we looked at the limits of declarative development vs. programmatic development. We also went through the application development life cycle. Furthermore, we studied different sandbox types. Last, we examined the deployment process in Salesforce by using an example. In Chapter 8, we take a look at the social and reporting capabilities of the Salesforce platform.