Introduction to Deployment Boundaries

Deployment Boundaries are a new concept in the Salesforce ecosystem and are relevant to administrators, developers and architects. You can use deployment boundaries to answer key questions including:

• Admins – What are all the fields and buttons that make up a specific page layout?
• Developers & Architects – What metadata should my scratch orgs have before I can start using them for development?

These boundaries will help you to prevent deployment issues, and go into ‘release day’ with more confidence.

In this article we’ll explain what deployment boundaries are, then we’ll explore some practical use cases and close by showing you how you can use Happy Soup to identify and export deployment boundaries with just a few clicks.

What Is a Deployment Boundary?

A deployment boundary is all the metadata that an org needs to have in order for a particular feature/configuration to exist. Let’s use the example of a Workflow Rule that sends an Email Alert when a Custom Field on the Account object evaluates to a particular value.

What is all the metadata that this Workflow Rule needs to exist? We can think of the following:

• The object that it evaluates (i.e Account or a Custom Object).
• The custom fields that it uses in the evaluation criteria (and if some of those fields are formulas, then the fields those formulas use).
• The email template that the email alert uses.
• Any custom fields that the email template references.

Without any of the above, it would be impossible to create the workflow rule.

Another way to think about this, is that if you tried to delete any of the components above (i.e if you try to delete a custom field), Salesforce would stop you because the workflow rule cannot exist without any of them.

All the metadata above is what we call the deployment boundary of this workflow rule, because the workflow rule depends on it.

Let’s use another example, this time, the deployment boundary of a Page Layout:

• The fields it references (and any other fields they reference i.e formulas)
• Buttons
• Inline visualforce pages

If you try to delete any of the above, Salesforce will stop you.

Where Does the Name “Deployment Boundary” Come From?

Normally we tend to think about all the metadata (fields, apex classes, objects) in our org as an unorganised pile of configuration. This is often referred to as a “happy soup”.

A deployment boundary is then the boundary of a particular feature/configuration within that happy soup. As always, a picture speaks a thousand words:

What we see here is that our org is full of seemingly unorganized metadata. But by drawing a boundary between a specific feature’s metadata and the rest of the org, you are able to see that the metadata does have a pattern to it.

We can draw this line in pretty much every feature/configuration and we’ll realise that our org is not a pile of metadata (a happy soup) but instead a large group of deployment boundaries.

Practical Use Cases

So, we’ve covered what deployment boundaries are. Now let’s see some practical use cases and learn how we can actually create or identify these deployment boundaries.

Admins: Get All the Fields and Buttons on a Page Layout

Suppose you are an admin/consultant and are asked to review all the fields and buttons on a page layout to identify redundant fields, or maybe to create a data dictionary.

Given that a deployment boundary is all the metadata that the page layout uses, identifying and exporting it is the way to review all the fields, buttons and so on that make up the page layout.

Developers: SFDX Scratch Orgs

When Salesforce released Salesforce DX (SFDX) back in 2017, the promise was that you no longer needed to wait a long time for a sandbox to be refreshed before you could start working on a new feature. You could simply create an empty scratch org and start building.

The challenge with this approach is that most of us hardly ever build new features on an empty org. Most of the development/configuration is done on existing metadata that has been there for years and that has many dependencies.

This brings up the following questions:

• How can we use scratch orgs to do development on top of existing metadata?
• Do we create a scratch org with all the metadata from our production environment?

The answer to these questions is that in order to use scratch orgs to do development on top of existing metadata, the scratch orgs need to be loaded with the deployment boundary of the feature you will be working on.

So, rather than loading the entire org’s metadata into a scratch org (something Salesforce strongly advises against), you just need to deploy the deployment boundary of a given feature.

Once the deployment boundary has been deployed to the scratch org, you can start building your feature just as if you were doing it in your original org.

Using Happy Soup to Identify and Export Deployment Boundaries

Let’s see what deployment boundaries actually look like. We’ll be using Happy Soup, an open source, community-led project that provides an easy way to work with deployment boundaries.

Head over to Happy Soup and log in to any of your Salesforce orgs.

To see the deployment boundary of a page layout, follow these steps:

1. Select “Page Layout” under “Select a Metadata Type”
2. Start typing the name of the layout in question and select it
3. Select “Deployment Boundary” under “Select a Query Type”
4. Click Search

You should now see all the buttons (webLinks) and fields that make up this page layout!

Now let’s look at the deployment boundary of an Apex Class that depends on a lot of other metadata.

We can see that for each metadata that is referenced, we also get what that metadata depends on it. This is all the metadata that is needed for the class to exist, and what you would need to deploy to a scratch org if you wanted to do development on that class.

Summary

We learned that deployment boundaries at its core is a new way of thinking about your org’s metadata and how it is organised. Thinking about your org in this way can be useful for admins, developers and architects.

We also learned how you can use Happy Soup to quickly identify and export deployment boundaries with just a few clicks.