Skip to main content

Deployment Boundaries

Understand the building blocks behind any Salesforce feature and deploy with confidence.

Pablo Gonzalez avatar
Written by Pablo Gonzalez
Updated over 3 weeks ago

Deployment boundaries are a new way of looking at Salesforce metadata. Instead of seeing your org as a giant pile of fields, objects, and automations, deployment boundaries let you focus on the specific pieces of metadata that a feature depends on.

This perspective is useful for everyone:

  • Admins – Quickly list out every field, button, and component that makes up a page layout.

  • Developers & Architects – Know exactly what metadata you need in a scratch org before you can start building.

By understanding these boundaries, you reduce surprises on deployment day and avoid the dreaded “missing dependency” errors.

What’s a Deployment Boundary?

A deployment boundary is the set of metadata required for a feature or configuration to exist.

Let’s take an example: a Workflow Rule that sends an email when a custom field on Account meets a condition.

The deployment boundary for this workflow includes:

  • The Account object itself

  • The custom field(s) used in the criteria

  • Any fields referenced in those criteria (like formulas)

  • The email template used by the workflow

  • Any fields that template references

If any of those pieces are missing, you can’t create—or deploy—the workflow.

Another way to think of it: if you tried to delete any of those items, Salesforce would block you, because the workflow depends on them. That’s the deployment boundary.

How HappySoup Helps

Manually identifying deployment boundaries is tedious. HappySoup makes it effortless:

  1. Go to Modularity → Deployment Boundary in HappySoup.

  2. Pick the metadata type (e.g. Page Layout, Apex Class).

  3. Search for the specific item.

  4. Hit Show Deployment Boundary

You’ll instantly see every dependency that makes up that boundary—fields, buttons, email templates, and beyond.

In the example above, we can see all the dependencies of the LeadTrigger trigger. You can then use the export panel to export a package.xml

You can then use the package.xml to retrieve the entire deployment boundary and deploy it to another org. Once that's done, you can deploy the trigger itself, and it will work as if it was in the original source org.

Did this answer your question?