Learn how to use dependency injection to mock read-only fields, such as formula fields and child relationships in your tests.

⚙️ Repository on Github: Mock Field Reader.

A while ago we explored the Mock Data Layer Pattern, which allows us to mock virtually any relationships between records within your tests. This is especially handy when trying to improve the performance of these tests — more details here.

Now, how can we mock formula fields and read-only child relationships if they are, well, read-only fields? 🤔

Mocking values in read-only fields

For this exploratory project, we will continue using the convenience of interfaces and dependency injection, but this time to develop a class used to mock field values.

We will use a not-so-realistic scenario with parent and child accounts, but the intent is to create a test for the Account Trigger Handler that will use a Mock Field Reader and a Mock Data Layer.

The Mock Field Reader will be used so we can mock two read-only fields on the Account object.

• Child_Accounts__r, a read-only child relationship on the parent record.
• External_URL__c, a formula field on the child record.

The trigger handler logic will update the following field:

• Parent.Latest_Child_URL__c

Based on the following formula field:

• Child.External_URL__c

Show me the code!

First, let’s create an interface with the required methods for the Field Reader:

Using this interface, let’s create a class that reads values from a SObject record, using standard SObject methods:

Also, using this interface, let’s create a class that will allow us to mock the read-only fields:

Getters

To respect the injected dependency, these methods must be present on both the real instance of the field reader ( FieldReader ) and the mock instance of the field reader ( MockFieldReader ).

public Object getFieldValue(SObject record, String fieldName)

This method is used to retrieve the mock values of formula fields. It returns an Object that can later be cast as different types, such as String, Number, Id, etc.

public SObject getFieldRecord(SObject record, String fieldName)

This method is used to retrieve the mock values that represent a single record. It returns a SObject.

public List getFieldRecords(SObject record, String fieldName)

This method is used to retrieve the mock values that represent a list of records, such as a child relationship. It returns a list of SObjects.

Setter

There’s only one method used to set the values, and it’s only present on the mock instance of the field reader ( MockFieldReader ).

public void addValueToField(SObject record, String field, Object value)

This method adds the field/value pair to a map of mocked values, indexed by the record Id.

Examples

In the repository on Github, you will find a trigger handler class and its respective test class with the usage of this Mock Field Reader.

Snippet from the AccountTriggerHandler: pay attention to how the following methods are being used:

fieldReader.getFieldRecords(parentAndChildAccount, 'Child_Accounts__r');
fieldReader.getFieldValue(latestChild, 'External_URL__c');

And in the AccountTriggerHandlerTest you can see how these read-only fields can be mocked:

With this code and the Mock Field Reader, it becomes easy to mock read-only fields used in the tests.

I hope that helps!

Created by Matheus Gonçalves. Originally published on matheus.dev.

T o keep things fresh, we’ve updated this, one of our most popular posts. See the latest version here.

Now is the time to become Salesforce-certified. With 48 resume-worthy Salesforce Credentials and counting — including 30 certifications and 18 superbadges — there are endless opportunities to showcase your experience with Salesforce and take your career to the next level.

More than ever, companies need Salesforce-skilled talent to help them drive their digital transformation. No matter your role, Salesforce Credentials allow you to prove that you’re the expert of your domain and showcase to current and future employers that you have the knowledge and skills to help them go digital fast.

Approximately 95% of all websites use JavaScript and there are more than 11 million JavaScript developers worldwide.

That’s why we’re so excited to introduce the Salesforce Certified JavaScript Developer I certification. This new certification validates two core competencies:

1. Standard JavaScript developer skills
2. Hands-on development skills for those working with JavaScript-related technologies, like Lightning Web Components

Your path to JavaScript certification

To maximize your learning and showcase your expertise, the JavaScript Developer I Certification is comprised of two parts that you can take in either order.

• JavaScript Developer I proctored multiple-choice exam — Intended for Trailblazers with 1–2 years of experience in developing front-end and/or back-end JavaScript applications for the web stack. The ideal candidate should be able to use JavaScript-specific design patterns for programming and can combine JavaScript with CSS, HTML, and other markup languages.
• Lightning Web Components Specialist superbadge — Validates Trailblazers’ expertise in developing fully functional Lightning Web Components. The ideal candidate should be able to use JavaScript and Salesforce Lightning Design System to create base and custom Lightning Web Components, using Lightning Data Service to manipulate Salesforce data and creating Lightning Message Service channels to communicate across the Document Object Model (DOM).

Learn foundational skills before unlocking the superbadge

To guide you on your path to earning the Lightning Web Components Specialist superbadge, we’ve developed a series of core badges to provide you with the foundational knowledge needed to become a successful Salesforce Certified JavaScript Developer.

1. Quick Start: Lightning Web Components — Set up your developer environment, tools, and editor, and create your first Lightning Web Component.
2. Lightning Web Components and Salesforce Data — Develop Lightning Web Components that interact with data in your Salesforce org, including using Apex and server errors handling.
3. Testing Lightning Web Components — Set up the Jest testing framework and start testing Lightning Web Components, including tests for Wire services, mocking base, and custom components.
4. Coding for Web Accessibility — Write code to build accessible user interfaces.

🌟 Pro tip: The Lightning Web Components Specialist Superbadge: Trailhead Challenge Help is designed to assist Trailblazers with FAQs about this superbadge, including links to helpful articles and explanations of different troubleshooting techniques.

Prepare for your certification with guided Trailhead resources

On the road to JavaScript Developer Certification, there’s no shortage of Trailhead resources to help you prepare:

1. Review the Salesforce Certified JavaScript Developer I exam guide — This guide includes recommended training, resources, and relevant Trailhead modules.
2. Complete the Prepare for Your Salesforce JavaScript Developer I Credential trailmix and the Study for the JavaScript Developer I Exam trail — We’ve curated step-by-step learning paths to help you understand and apply the key concepts you’ll need to prove your skills and become a #CertifiedPro.
3. Take the Certification Preparation for JavaScript Developer I (CRT-600) course — We’re excited to introduce this brand new course to supplement your self-studying on Trailhead and reinforce your knowledge of key features and concepts of the JavaScript programming language.
4. Join the Trailblazer Community — When getting certified, collaboration is key, and the Trailblazer Community is a great place to start. Engage for help on the trails, to join a user group in your area, to find a study partner/mentor, and to connect with other Trailblazers from around the globe with similar experiences and challenges.

Ready to earn your JavaScript certification?

Feeling inspired to be among the first to become a Salesforce Certified JavaScript Developer? It’s time to dive in! Head over to the Salesforce Certified JavaScript Developer I Credential page for all the details on this exciting new certification, including access to all of the study resources available to you on Trailhead.

And don’t forget to shout out your success on social using #CertifiedPro so we can follow your success!

JavaScript Developer I Certification: Empowering JavaScript Developers to Build on Salesforce was originally published in The Trailblazer on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to query for Salesforce Apex classes code coverage? — Matheus Gonçalves

In Salesforce Orgs, code coverage percentage is a calculation of the number of covered lines divided by the sum of the number of covered lines and uncovered lines.

In addition to ensuring the quality of your code, unit tests enable you to meet the code coverage requirements for deploying or packaging Apex. To deploy Apex or package it for the Salesforce AppExchange, unit tests must cover at least 75% of your Apex code, and those tests must pass.

After running tests, you can view code coverage information in the Tests tab of the Developer Console. The code coverage panel includes coverage information for each Apex class and the overall coverage for all Apex code in your organization.

However, you can also use SOQL queries with Tooling API as an alternative way of checking code coverage and a quick way to get more details. Let’s see how it works:

Inspecting Code Coverage

Step 1 — Get your org’s base URL:

If you know what’s your Org’s base URL (you can get it from your browser as well), please jump to step 2.

• From Developer Console, open the Debug menu, then select the option “Open Execute Anonymous Window (CTRL+E)
• Enter the following Apex Code:

String baseURL = 'https://' + System.URL.getSalesforceBaseUrl().getHost();
System.debug(baseURL);

• Click the button [Execute]
• Go to your Logs tab on the bottom of the page
• Copy the full Base URL, including https://

Step 2 — Now you know your base URL, create a Remote Site Setting

• From Setup, enter Remote Site Settings in the Quick Find box, then select Remote Site Settings.
• Click New Remote Site.
• Enter a descriptive term for the Remote Site Name.
• Enter the URL for the remote site.
• Optionally, enter a description of the site.

• Click Save.
• Just in case, create a second Remote Site Settings for the URL in the “Visual.force.com” format:
• https://c.xx99.visual.force.com — where xx99 is the code of your org’s instance.

Step 3 — Get the JSON file for the Code Coverage Wrapper

• Go back to the Developer Console, open the Debug menu, then select the option “Open Execute Anonymous Window (CTRL+E)
• Enter the following Apex Code:

• Click the button [Execute]
• Go to your Logs tab on the bottom of the page
• Copy the full JSON result
• Please note you will need to remove any text before the first “{“ bracket.
• Eg.: “hh:mm:ss:999 USER_DEBUG [99]|DEBUG|“
• Go to the website JSON2Apex: https://json2apex.herokuapp.com/
• Paste your JSON file
• Enter the name for the generated class (here, we will use CodeCoverageWrapper)
• Click the button [Create Apex]

• Download the generated zip file that contains the Wrapper class plus the Test class.
• Extract the files
• Open the files with your preferred text editor
• Check if everything looks good, and add these classes to your Salesforce org as new classes.

This is how it looks like:

Step 4 — Create a Helper Class

• Create the following class, that contains a method that will query and return information about the Code Coverage

Don’t forget to write the test class for it.

Step 5 — Create a Controller and a Page to display the Code Coverage

• Create the following class, that contains the logic for the page

Create the following page, using the controller we just created.

• Please note we’re leveraging Salesforce Lightning Design System;

The page has two buttons. One to sort the results by Class / Trigger name, and another button to sort the results by Code Coverage.

This is how it looks like:

Final Considerations

You can follow the same logic to use the Tooling API whenever you need to query exposed metadata used in developer tooling that you can access through REST or SOAP.

Also, the method sortCodeCoverageMapByCoverage from CodeCoverageHelper is quite handy and can be used as an example for situations when you need to sort Maps by its values. In this case, sort the Code Coverage percentage value.

Just don’t forget to adapt the Wrapper and the Comparable.

You can find all code used for this project in my GitHub account, at github.com/gitmatheus/QueryCodeCoverage

I hope you enjoyed the ride and learned something new today.

See you next time.

This article was originally posted at matheus.dev

I’ve been trying to use some of my spare time to help my fellow Salesforce Developers in our community. And one of the best places to do so, is Salesforce Stack Exchange.

And a few days ago someone posted the following question:

How can I write a test method without actually doing the query (to speed up test run times)? As far as I know, the only way to return relationships more than one level deep is to query for them. I know ApexMock has IDGenerator but cannot see how I can use it for this use case?

Well, can we mock relationships in Apex to improve a test’s performance?

And the answer is yes, it’s possible. I’m going to explain how to achieve that in incremental steps, to try to simplify the concept.

You can mock virtually any relationship if you use a Mock Data Layer Pattern.

Imagining the scenario presented by the developer in that question, you could add an Interface to your main class. Let’s call it IDataLayer. Add this new interface to the main class (here, called DataLayerHandler.cls)

Now, in the same class, let’s create an inner class for this data layer, implementing the Interface you just created:

Ok, now how to access it? We need to create an instance of this DataLayer, and we will use the DataLayerHandler Class constructor for that. This is really important, I’ll explain it below:

But why do all of that?! And this is the magic: because now you can pass a MOCK version of the data layer to your class to use!! Given this handler class, let’s create a test class and a mock class, implementing the same interface:

With the mock version of the data layer, you can start creating your mock records. Use the method getFakeId(Schema.SObjectType type) to create Ids to your mock records:

There you go. This way you can mock several different types of relationships.

This is an extremely useful pattern and allow you to test your logic in different scenarios without running queries, without hitting the database. It’s a good way to improve your test performance.

Just don’t forget to create some bulkified tests as well.

I hope that helps!

This article was originally posted at matheus.dev

Salesforce DX is finally available and it is amazing! Now professional developers can build collaboratively with continuous delivery using Salesforce DX, the open and integrated experience that makes development on the Salesforce Platform easy.

I strongly recommend you to watch this presentation, made by Wade Wegner, with an introduction to Salesforce DX, talking about principles of Modern Software Delivery, how DX will improve the Developer Experience, some patterns and anti-patterns and how to adopt Salesforce DX:

Well, once you decide to switch, you’ll notice that you can use the Salesforce command-line interface (CLI) for most Salesforce DX tasks. These tasks include authorizing a Dev Hub org, creating a scratch org, synchronizing source code between your scratch orgs and VCS, and running tests.
You can start using the CLI right after you install it.

The CLI commands are grouped into top-level topics. For example, the force top-level topic is divided into topics that group commands by functionality, such as the force:org commands to manage your orgs.

Run — help at each level to get more information.

sfdx --help // lists all top-level topics
sfdx force --help // lists all the topics under force
sfdx force:org --help // lists all the commands in the topic force:org
sfdx force:org:open --help // detailed info about the force:org:open command

Imagine you want to login to your Hub Org:

sfdx force:auth:web:login --setalias my-hub-org --instanceurl https://login.salesforce.com

Imagine now that you want to login to your sandbox:

sfdx force:auth:web:login --setalias my-sandbox --instanceurl https://test.salesforce.com

To set this alias as your current default:

sfdx force:config:set defaultusername=my-sandbox

Maybe you want to get a list to all orgs you’re connected to:

sfdx force:org:list

To open one of these orgs:

sfdx force:org:open -u my-sandbox

To mark a scratch org for deletion:

sfdx force:org:delete -u my-sandbox

To remove an old hub org or non-scratch org from Salesforce DX org list, you need to manually clean up the DX configs in the local installation. It would be nice for this to be something in the actual CLI commands: the ability to clean up old orgs that are no longer needed. For the time being, use the following steps:

On Mac OS and Linux, you can find your DX config folder, called .sfdx, in your user home directory.

cd ~/.sfdx

On Windows, you can use

%USERPROFILE%\.sfdx

In that folder, there are a host of .json files, named for the username of the admin user you registered for that org. In my case, in this instance it was called mgoncalves@dx.pilot, so sure enough, there it was:

mgoncalves@dx.pilot.json

Inside the file or the hashes for a current access token, refresh token, and all the other OAuth goodness that allows DX to access your org. So I simply deleted that file:

> rm mgoncalves@dx.pilot.json

That appears to have cleaned it all up.

To retrieve unpackaged Source Defined in a package.xml file (eg.: the file created by MavensMate):

sfdx force:mdapi:retrieve -r ./mdapipkg -u [your_username] -k ./package.xml

To retrieve an unmanaged package you want to convert to Salesforce DX:

sfdx force:mdapi:retrieve -s -r ./mdapipkg -u [your_username] -p

To convert the retrieved source Defined in a package.xml file: the first step is to unzip unpackaged.zip using a zip file management utility or from the command line. For example, on a Mac, double-click unpackaged.zip in Finder or type the following command on the command line:

unzip ./mdapipkg/unpackaged.zip -d ./mdapipkg/

Then convert the source code to the Salesforce DX project structure:

sfdx force:mdapi:convert -r ./mdapipkg

To create a scratch org, first create a JSON file with the or configuration. Then:

sfdx force:org:create -f project-scratch-def.json -a MyScratchOrg

To push changes, use a Force Push:

I mean, use this:

sfdx force:source:push -u MyScratchOrg

To push changes ignoring errors (with great powers, great responsibilities. Be careful):

sfdx force:source:push -u MyScratchOrg --ignorewarnings --forceoverwrite

For an even more powerful approach, you can retrieve and deploy code from/to a regular org. First, authorize the regular org using the login command we learned above. Then, choose one of the options below, depending on if you want or not to deploy Lightning/Aura Components:

sfdx force:source:retrieve -m CustomObject,ApexClass,ApexTrigger,ApexPage,CustomLabels

sfdx force:source:deploy -m CustomObject,ApexClass,ApexTrigger,ApexPage,CustomLabels

sfdx force:source:deploy -m CustomObject,ApexClass,ApexTrigger,ApexPage,CustomLabels,AuraDefinitionBundle

sfdx force:source:retrieve -m CustomObject,ApexClass,ApexTrigger,ApexPage,CustomLabels,AuraDefinitionBundle

Salesforce DX CLI is a powerful command-line interface, a tool that simplifies development and builds automation when working with your Salesforce org.

For even more information, run this command to view all available commands in the force topic.

sfdx force:doc:commands:list

See you next time.

This article was originally posted at matheus.dev

This content was presented during Trailhead Live Atlanta, on September 14th, 2017.

Some people say we never stop learning because life never stops teaching. Sometimes, the difference between a bad day and a good day is if we learned something.

It’s all about the joy of understanding. So, today let’s talk about Trailhead and how to use it to boost your team’s knowledge!

In a nutshell, Trailhead is a fun way to learn Salesforce. And I mean it.

It’s an online learning platform based on gamification, so once you finish the units in a given module, you get a shiny new badge and level up your character.

Whether you’re an admin just starting out, a graduate fresh from college, a Salesforce user, or someone who loves to learn,
there’s something on Trailhead for you.

Watch the vídeo above to learn more about using Trailhead to improve your skills. Don’t forget to share it with your team!

See you next time.

This article was originally posted at matheus.dev

How to select the Salesforce release for a Scratch Org — Matheus Gonçalves

Did you know you can specify the release (preview or previous) when creating a scratch org?

That is especially helpful when testing your code against future features in Preview orgs, but it’s even more than that:

During every major Salesforce release, you have the opportunity to get early access to the release in your scratch orgs and sandboxes to test new customizations and features before your production org is upgraded. This is called the Salesforce Preview, and scratch orgs created on the upcoming release are called preview scratch orgs.

This way you not only can try out new features in an upcoming release, to check if they will fit your needs but also by running your applications in preview orgs, you can proactively check if your code is in good shape or if there will be a breaking change.

Then you can add any future bug to your backlog and plan your work accordingly, with fewer surprises.

Normally, you create scratch orgs that are the same version as the Dev Hub. However, during the major Salesforce release transition that happens three times a year, you can select the Salesforce release version, Preview or Previous, based on the version of your Dev Hub.

Prior to this change, you would have to create a trial Dev Hub on the upcoming version to create preview scratch orgs. Now you can use your existing Dev Hub that includes your existing scratch org active and daily limits.

Because previous and preview are all relative terms, your Dev Hub org version during the release transition determines their relative significance. Here’s what happens when you try to create a scratch org with one of the release values.

Important note: If you don’t specify a release value, the scratch org version is the same version as the Dev Hub org.

Create a Scratch Org for a Specific Release

You can specify the release version in the scratch org definition file or directly on the command line. Any option you issue on the command line overrides what you have defined in your scratch definition file.

Find out which instance your Dev Hub org is on: status.salesforce.com.

Add the release option to your scratch org definition file:

If you’re planning on using some sort of script to spin up a new scratch org, or you just prefer using the command line, you can specify the release value directly on the CLI!

Please note the use of the release keyword: release=Preview

If you’re creating a previous scratch org and you have upgraded the CLI to the pre-release version, be sure to set the apiVersion to match the scratch org version.

To set it globally for all DX projects:

To set it on the command line:

What If I Want to Create a Pre-Release Scratch Org?

Pre-release is a very early build of the latest version of Salesforce that’s available before Salesforce Preview. It’s not built to handle scale and doesn’t come with any Salesforce Support service-level agreements (SLAs).

For this reason, the only way to create a pre-release scratch org is to sign up for a pre-release trial Dev Hub org (subject to availability).

Originally published at matheus.dev on July 29, 2019.

Your company has been a Salesforce customer for a while now. How old is your Org now? Five years? Ten? Chances are there are a bunch of customizations and technical debt lingering around your org that you no longer need. Business processes and priorities are constantly changing and some of the customizations you built just a few years ago may no longer be relevant. It’s time to move on and clean up your org!

Let’s follow these best practices suggested by Christopher Marzilli, a Platform Success Specialist Director at Salesforce!

Your #AwesomeAdmin and Business Analysts have identified fields, objects, workflows, classes, triggers, processes, S-controls, etc… that are no longer needed. Now, what do you do next? Just “blow away” all the customizations and hope nothing goes wrong?

Absolutely NOT!

What you need is a decommissioning process by which Administrators, Developers, and Release Managers can safely remove Salesforce customizations without causing any disruption to the business. All the while having an easy process to restore any customizations that were thought to no longer be needed but, as it may come to light, are needed. This guide will review best practices for decommissioning many different types of Salesforce customizations including custom fields and objects, validation rules, Apex code, triggers, Visualforce pages, workflows, End-of-life features like S-Controls, and much more.

Assuming you have already identified a customization that is no longer needed, there are five steps that should be completed to safely decommission a customization in Salesforce:

1. Research

Once you have identified specific customizations that are no longer needed research needs to be completed to get a full view of where the customization is used. A sandbox is the best environment to start your research. Custom fields can be particularly difficult to research since they can be used in a variety of places. Here is a checklist of places to look for usage:

Astro Tip: When you try to delete a custom field in Salesforce an error message will show if any validation rules, formula fields, workflows, processes, fieldsets or Apex reference the field. Try this in a sandbox environment as part of your research.

Armed with the checklist above begin to review your org for possible uses and removal impacts of the customization. Try a few of these different ways to conduct your research:

• In a sandbox delete the customization. Salesforce will detect many different types of dependencies like validation rules and workflows.
• If you are using a Source Control System like GIT or TFS try leveraging the search capabilities within those systems.
  In the Developer Console use the “Search In Files” function located in the Edit Menu.
• Leverage the Force.com IDE to inspect your code and metadata. The IDE has a text-based search function to help you find places where fields, classes or methods are referenced in code and config. If you are unfamiliar with how this can work check out AdminHero’s recent blog post on “Searching Salesforce Metadata Using The Force.com IDE”.
• Use the Developer Workbench, which like many other apps can leverage the Metadata API to search your metadata.
  Check out the Salesforce Toolkit for a variety of additional helpful tools.
• Leverage SchemaSurfer, an AppExchange app that provides a way to browse and explore object metadata inside of Salesforce

You should be sure to test removing the customization in a sandbox. Check that all apex tests run successfully after removal. Don’t forget to test your inbound and outbound system integrations and to regression test any critical business processes after removal from a sandbox.

Once your research is complete you should have a list of all the places the customization is referenced with a plan on how to go about removing the customization and to update or remove any dependencies.

2. Communicate

Notify end users that the customization is being decommissioned. You can do this using a chatter post or as part of a regular newsletter. No matter how you send the communication, be sure to include a couple of key pieces of data:

• The customization being decommissioned
• An explanation as to why it is being decommissioned
• Information on if another customization replaces what is being decommissioned
• A contact person to reach out to if anyone has any questions or concerns

You should also label the customization so it can be clearly seen within the UI that it is being decommissioned and inform users what the label signifies. In the case of a custom fields, objects or workflows you can update their labels with “ OLD” or “ TBR “ for “To Be Removed.”

With classes or triggers, whose names can’t change add comments at the top of the file to signify a change.

Insert some text at the top of a Visualforce page to warn users of the pending removal.

Allow users some time (~15 to 30 days) after they have been notified to observe if any of their day-to-day work may be impacted.

Note: Be mindful here of Customer and Partner Communities that may have access to fields, Visualforce pages and other customizations you are decommissioning. Notification and labels presented to these groups may need to vary versus an internal audience. In some cases, no notification or label may be required and you can move to the next step of restricting access.

3. Restrict

Now that you have reached the point where the changes have been communicated and clearly labeled and no one has reported any issues with the change it’s time to remove access to the customization from users. This is an important step because it may save you time as opposed to deleting the customization at this point. Having to bring back something after it has been deleting is much harder than simply re-authorizing access to the customization.

For many customizations like workflows, triggers, processes, and validation rules you can simply make them inactive. For customizations like custom fields and objects, you can leverage Field Level Security and Profiles to ensure no users have access to the fields or objects. You can also remove fields, Visualforce components and Lighting components from apps and page layouts. Rights to Visualforce pages and apps can also be revoked via profiles.

4. Monitor

Now that access has been restricted the next step is to institute a waiting period of ~15 to 90 days as a safeguard before final removal.

In the case of custom fields and objects, make a backup of their data before and after the monitoring period so you can check for any change in the data. You can also use Field History here if you have available fields for tracking.

Be sure an Administrator or Developer has an action item scheduled at the end of the waiting period to do a final examination and ensure the customization is no longer being used.

5. Decommission

Time to remove your customization from production. At this point, you should have notified all users, labeled the customization appropriately, run through tests in your sandbox environments and restricted access to the customization for a period of time. While you should follow your standard lifecycle (SDLC) here are a few items to include when decommissioning a customization.

Start by backing up the customizations metadata and data (if any). To backup metadata you can use your Force.com IDE which can download metadata in the form of an XML file. This can be stored on a file system but an even better solution is to use a Source Control System like GIT to store code and config changes in your org. Data can be backed up in a variety of ways from exporting reports to leveraging the data loader to pull down a CSV file of the data.

Now that you have backed up the customizations metadata and data you are ready to delete the customization from your Org! Unfortunately, changesets can’t be used to delete customizations in Salesforce. So for the most part Administrators will have to leverage Setup to delete customizations. Alternatively, you can leverage the Force.com ANT Migration tool with a destructiveChanges.xml file to remove changes or one of the many 3rd party deployment apps available. In either case, you have reached the final step of removing the customization from production.

Deleting Data

The Salesforce data deletion mechanism can have a profound effect on the performance of large data volumes. Salesforce uses a Recycle Bin metaphor for data that users delete. Instead of removing the data, Salesforce flags the data as deleted and makes it visible through the Recycle Bin. This process is called soft deletion. While the data is soft deleted, it still affects database performance because the data is still resident, and deleted records have to be excluded from any queries.

The data stays in the Recycle Bin for 15 days, or until the Recycle Bin grows to a specific size. The data is then physically deleted from the database after 15 days; when the size limit is reached; or when the Recycle Bin is emptied using the UI, the API, or Apex. See View and Purge the Recycle Bin.

In addition, the Bulk API supports a hard delete (physical delete) option, which allows records to bypass the Recycle Bin and become immediately available for deletion. We recommend that you use the Bulk API’s hard delete function to delete large data volumes.

If you want to delete records in a sandbox organization’s custom objects immediately, you can try to truncate those custom objects. You can contact Salesforce Customer Support for assistance with this task.

Congratulations! If you followed these best practices, then you have safely removed unneeded technical debt from your Org. You, your company and your Org are better for it! Now go off and build something cool!

And don’t forget to check out the great ideas available on Trailhead! 😉

See you next time.

Originally published at matheus.dev on September 22, 2017.