For small teams pushing a handful of changes each sprint, change sets do the job just fine. They’re free, built into every org, and need nothing more than an authorized deployment connection to start working. But as teams grow, release cadence increases, and org complexity builds, the manual dependency work that change sets require grows faster than the headcount available to do it — and failed deploys become routine rather than the exception.

This article covers how change sets work, where they tend to break down, and what Salesforce teams do when they’ve outgrown them.

How change sets move metadata between orgs

package metadata in a source org and deploy it to a target org through a deployment connection. They use the Metadata API so you don’t need to work with XML files or run command-line tools. Instead, you select components through the Salesforce UI, upload the package, and deploy it in the target environment.

Change sets work between orgs that share the same production instance. This means you can deploy from a sandbox to production, or from one sandbox to another sandbox — as long as both sandboxes were created from the same production org. You can’t use change sets to migrate metadata between unrelated orgs, such as two separate production environments or orgs belonging to different companies.

Not being able to move metadata between unrelated orgs creates a boundary around your org which severely limits flexibility. Many teams need to move configurations between unrelated orgs — during a merger, for example, or when setting up a new business unit with its own production environment — and change sets simply can’t help. You’ll need the Metadata API directly or a deployment platform that supports org-to-org comparison regardless of lineage.

For most teams, the typical development process runs from a developer sandbox through a staging or UAT sandbox and into production. Change sets support this linear flow, but each step requires its own deployment connection and its own change set. You can’t create a single package that deploys across multiple environments in sequence — each step requires building and validating separately every time.

Setting up deployment connections

Before you can upload an outbound change set, you need to set up a deployment connection between the source and target orgs. This is a two-part process that requires you to complete some steps in each org.

In the target org (the one you’re deploying to), navigate to Setup → Deployment Settings. You’ll see a list of related orgs — your production instance and any sandboxes created from it. Select the source org you want to receive changes from and enable Allow Inbound Changes.

The source org doesn’t require additional configuration to send outbound change sets, but the connection is one-directional by default. If you want to send change sets back in the other direction — from production to a sandbox, for example — you’ll need to configure that separately in the other org’s Deployment Settings.

This step is often missed when creating new sandboxes. A common point of friction is when an admin finishes building in a new sandbox, tries to upload their first change set, and discovers the deployment connection wasn’t authorized. Checking Deployment Settings in your target org before you start building saves time later.

Permissions default to System Administrators, but you can grant deployment access to other profiles through the Upload Outbound Change Sets and Create and Upload Change Sets permissions. This lets release managers coordinate deployments without requiring full admin rights.

How to build an outbound change set

With your deployment connection in place, you’re now ready to build your change set. Building an outbound change is done in three steps, and this is where teams start to feel some initial pains:

Selecting components

To create a change set, navigate to Setup → in your source org and click New. Give the change set a descriptive name — something you’ll recognize weeks later when it’s sitting in a list of similar packages. “Q4 Release” is too vague. “Account Territory Fields Oct 2024” tells you exactly what’s inside.

The next step is adding components. Click Add and you’ll see a list of metadata types: custom objects, fields, Apex classes, flows, page layouts, and so on. Select the type, then choose the specific components you want to include. Adding the components is entirely manual.

Change sets don’t detect what you’ve modified, so you have to know what changed and add each component individually. If your work spans multiple objects, flows, and classes, you’re building the package from memory — or from notes you hopefully kept. Miss something and you won’t find out until the deployment fails in the target org. What’s worse, the deployment might succeed but leave the feature broken because a referenced field or class wasn’t included.

Using View/Add Dependencies

After adding your primary components, use the button. This scans the org for metadata that your selected components reference — for example, if you added a page layout, it might identify custom fields that the layout displays.

The dependency tool catches direct relationships reasonably well. But it struggles with indirect dependencies such as the chains of references that characterize complex configurations. A flow might reference a record type, which depends on a picklist value, which uses a global value set. The dependency tool will only surface the first link and miss the rest altogether.

The tool also doesn’t distinguish between dependencies that already exist in the target org and those that are genuinely new. Selecting everything it suggests can bloat your change set with hundreds of components. In some cases, it will overwrite production configurations with older sandbox versions.

Treat View/Add Dependencies as a starting point rather than a safety net. You’ll still need to review the list, remove components that already exist in production, and verify that what remains actually needs to be deployed. Although the tool helps you find dependencies, it won’t tell you which ones matter.

Uploading to the target org

Once you’ve added all your components, click Upload. The change set is transmitted to the target org, where it appears in the Inbound Change Sets list.

Once uploaded, a change set can’t be edited. You can’t add missing components, remove something you included by mistake, or adjust anything about the package. It’s locked.

If your deployment fails because of a missing dependency, or if you realize you forgot something, you have one option: clone the change set in the source org, make your changes to the clone, and upload again. This creates a new inbound change set in the target. The original remains unchanged and can’t be deleted from the inbound queue until it’s deployed or the target org manually removes it.

Teams that deploy frequently end up with cluttered change set lists: “Spring Release v1”, “Spring Release v2”, “Spring Release FINAL”, “Spring Release FINAL2”. There’s no built-in cleanup mechanism, and no way to trace which version actually made it to production unless you maintain external records.

This is the difference between change sets and version-control-based workflows, where you can push incremental changes without rebuilding the entire package. With change sets, every adjustment requires a complete manual rebuild, reupload, and revalidation cycle.

Setting up change set permissions

Before you even get to uploading your change set, it’s worth making sure the right people have the right access in both the source and target org — because permissions errors are one of the more frustrating things to troubleshoot mid-deployment.

To create and upload outbound change sets, users need the Create and Upload Change Sets permission. To deploy inbound change sets in the target org, they need the Deploy Change Sets permission. Both are included in the System Administrator profile by default, but can be added to custom profiles or permission sets.

Most teams restrict deployment access to one or two admins or release managers. That’s less about permissions and more about control — making sure someone accountable reviews every change before it reaches production.

If you hit an “insufficient privileges” error, check both permissions explicitly. The error won’t tell you which one is missing.

The difference between validating and deploying

Confusing validation and deployment is one of the most common causes of a failed production deployment — and it’s easy to do, because the two options look almost identical in the UI.

What validation catches — and misses

Before deploying, you have the option to . Validation runs through the deployment process without committing any changes, checking for metadata conflicts, missing dependencies, and (for production deployments) running Apex tests.

Validation catches errors that would cause the deployment to fail, but it’s not foolproof. It won’t detect logical errors, such as a flow that deploys successfully but breaks a business process because of a hardcoded ID that doesn’t exist in production. It also won’t catch issues caused by changes made to the target org between validation and deployment. Someone might modify a field or delete a custom object after you validated but before you deployed, creating a conflict.

Still, validation is worth the time. A failed deployment can lock the org’s metadata for extended periods, blocking other admin work. Validating first lets you catch problems without that disruption.

Apex test requirements for production orgs

Deploying Apex code to production triggers test requirements that don’t apply to sandbox-to-sandbox deployments. Salesforce requires that be covered by unit tests, and all tests must pass.

This is a cumulative threshold across the entire org, not just the code you’re deploying. You might deploy a new class with 100% coverage, but if existing code in production has poor coverage, your deployment fails. New, well-tested code gets blocked by legacy technical debt.

The option lets you specify only the test classes relevant to your deployment, bypassing unrelated test failures. But you need to identify those classes manually — change sets don’t help you determine which tests cover which components.

After a successful validation, Quick Deploy lets you deploy within 10 days without re-running tests. This is the primary reason to validate before production deployments — you can run tests during a low-traffic window, then execute Quick Deploy during your scheduled maintenance window without waiting for tests to complete again.

How change sets handle profiles and permissions

Profile deployments are where change sets cause the most unexpected damage. Any incoming profile metadata replaces what already exists in the target org. So, if a permission is enabled in production but not included in the sandbox version you’re deploying, that permission gets disabled.

This creates a pattern of “silent failures” — deployments that succeed technically but leave users unable to access features they could access before. The change set completes without errors, but support tickets start arriving minutes later when people discover they can’t view reports they’ve accessed for months or edit records they own.

The problem compounds with page layout assignments. A profile in a change set only carries layout assignments for record types that are also included in that change set. If you include a profile and a record type but not the page layout assigned to that record type, the deployment removes the layout assignment entirely. Users see a default layout instead of the one they’re supposed to see, with fields missing or in the wrong order.

Many teams avoid deploying profiles through change sets altogether. They deploy the functional changes — objects, fields, flows, code — and then manually update profile permissions in production. It’s an extra step, but it’s more predictable than the blanket overwrite that profile deployments can cause. The alternative is maintaining perfectly synchronized profiles across every sandbox, which almost never happens in practice.

Change sets can’t move every type of metadata

Change sets can’t move every type of Salesforce metadata because some component types aren’t supported by the Metadata API. Others are supported by the API but not surfaced in the change set interface.

Common components that require manual recreation include standard picklist values (custom picklist values deploy fine, but changes to standard fields like Opportunity Stage don’t), organization-wide email addresses, certain territory management configurations, and some Experience Cloud components like navigation menu translations.

Salesforce maintains documentation on supported metadata types that’s worth bookmarking before you build your next change set. The list of unsupported types also grows with each release — new features often ship before deployment support catches up. Flow orchestrations, for example, took months to become deployable through change sets after their initial release.

What happens when a deployment goes wrong?

Change sets don’t have a rollback capability. Once a deployment completes, the changes are committed to the target org — and there’s no undo.

If a deployment causes problems in production — a broken flow, a misconfigured validation rule, user access issues — you have limited options. You can manually reverse the changes in production if you know exactly what changed and how to undo it. Or you can create a new change set in a sandbox that restores the previous configuration and deploy that to production.

Both approaches require you to know what the previous state was. Change sets don’t maintain snapshots of what existed before the deployment. If you don’t have external documentation or a sandbox that still reflects the pre-deployment state, reconstructing what to restore becomes guesswork.

This is why validation matters. It’s your last chance to catch metadata errors before they’re committed. But validation doesn’t catch logical errors or business process problems that only surface when real users interact with the changes. A flow might pass validation but fail when a user encounters a specific record state you didn’t test against.

For those scenarios, you need a rollback capability that change sets don’t provide. The alternative is building every change set with a matching “rollback” change set prepared in advance, which doubles the deployment work and still requires you to anticipate what might go wrong.

Moving beyond change sets

Many Salesforce teams reach a point where the cost of working around change set limitations exceeds the cost of adopting a purpose-built deployment platform. When that moment comes, teams typically look for tools that handle the deployment challenges that change sets can’t.

These tools offer direct org-to-org comparison so you see exactly what’s different, automated dependency detection with specific warnings about what will break, selective profile deployments that don’t overwrite everything, and native rollback capability so you can recover if something goes wrong.

The result is higher deployment success rates, deployment times measured in minutes instead of hours, and the confidence to release more frequently because you can recover quickly if something goes wrong.

91�Թ���: make changes with confidence — not workarounds

91�Թ��� approaches deployment differently. Instead of building packages from memory, you start by comparing your source and target orgs directly — seeing exactly what metadata exists in each, what’s different, and what’s changed. Filters let you narrow that comparison to the specific components you care about, so you’re not wading through hundreds of irrelevant differences to find the ten changes you actually want to deploy. The result is a clear, accurate picture of your org state before a single component moves.

Precision deployments mean you choose exactly what to include — nothing more, nothing less. Dependencies are surfaced automatically, with specific warnings about what will break if you proceed without them, so you’re never deploying blind. Profile deployments are handled selectively: rather than overwriting everything the profile contains, you deploy only the permissions that actually changed.

Merge conflicts are an inevitable part of working across multiple sandboxes and teams. 91�Թ��� surfaces conflicts clearly and gives you the tools to resolve them before they reach production — so you’re not discovering a conflict mid-deployment, under pressure, when the stakes are highest.

And every deployment can be rolled back. 91�Թ��� maintains a snapshot of the target org’s state before any changes are committed. If something breaks after release — a flow behaves unexpectedly, a validation rule fires incorrectly, user access drops — you don’t have to reconstruct the previous state from memory or documentation. You click a button, the deployment reverses, and your org is back to where it was. The entire process takes seconds.

Ready to leave change sets behind?

If change sets are no longer working for your team and you’re ready to move on, start a with 91�Թ��� and see the difference in your own orgs. Or book a demo if you’d like a guided walkthrough with our DevOps team.

The result is that UI testing gets treated as optional. Teams do manual regression testing instead, or skip it altogether when deadlines tighten. But when something breaks in production, the cost of not having caught it earlier becomes very visible, very quickly.

In this post, we’ll look at why UI testing is a critical part of a Salesforce testing strategy and what makes it particularly difficult to implement without the right tools. We’ll cover best practices for building a UI test suite, and how �ұ𲹰������’s AI-powered Automated Testing makes automated UI testing accessible to any Salesforce team.

The importance of UI testing for Salesforce

Unit testing and code coverage get a lot of attention in Salesforce development, partly because Salesforce mandates a minimum of 75% Apex coverage before any production deployment. That requirement has shaped how many teams think about testing, with many teams prioritizing unit testing over other types of tests, to avoid being blocked from deploying to production.

But while unit tests validate backend logic, they don’t validate frontend behavior. And unit tests only cover your Apex classes. A Flow that runs as expected when executed in isolation can still produce the wrong outcome when a user triggers it through the UI with a specific set of permissions, or when it interacts with a validation rule that was added three sprints ago. These are the failures that reach production, are very visible to the business, and generate an influx of support tickets.

UI testing checks that the workflows your users depend on actually behave as expected when someone moves through them in a live org. This includes checking that the right fields appear for the right profiles, that a Screen Flow renders correctly and submits the expected data, that a button triggers the right action for a given record type, and more. These are the type of behaviors that unit tests can’t reach, requiring testing at the interface level.

The challenges of Salesforce UI testing

Although the importance of UI testing is clear, Salesforce presents a specific set of challenges that make UI test automation significantly harder than it would be for a standard web application. Understanding these challenges is useful context — both for teams evaluating whether to invest in UI testing, and for teams who have tried and found it harder to maintain than expected.

Technical challenges of UI testing for Salesforce

The Salesforce platform’s Lightning interface is built on a deeply nested component structure where UI elements are often wrapped in multiple layers, making it difficult for test automation tools to reliably locate and interact with them. Salesforce also uses Shadow DOMs — a web standard that encapsulates components so their internal structure is hidden from the outside — which creates additional barriers for tools that rely on directly accessing page elements.

Dynamic element IDs compound this further. Salesforce generates temporary identifiers for UI components that change between environments, meaning tests written against specific element IDs will fail when those identifiers are regenerated. And because Salesforce ships three major releases every year, even a well-maintained test suite will encounter breaking changes regularly. Layout adjustments, component updates, and structural changes to how pages load can all cause previously stable tests to fail.

The net effect is high maintenance overhead. Teams that invest time in building a UI test suite often find they’re spending significant amounts of time repairing tests after each release. For teams without dedicated automation engineers, that overhead becomes unsustainable quickly — and UI testing gets deprioritized as a result.

Organizational challenges of UI testing for Salesforce

Technical complexity is only part of the story. For many teams, the more significant barriers to UI testing are organizational.

For most Salesforce teams, the responsibility for testing is shared across developers, admins, and release managers who are also responsible for active development. Up against the immediate pressure of sprint deadlines, the time needed to set up and maintain a test automation suite can be hard to justify.

Some teams try to tackle this by assigning a member of the team to manage testing. But if one developer or automation engineer owns the test suite, they become a single point of failure. If they’re away or leave the team, testing becomes an instant bottleneck or breaks down entirely.

Add to that the fragility of Salesforce UI test automation many teams experience. When Salesforce releases, org configuration changes, or dynamic elements regularly break the tests, teams stop trusting them. False positives erode the value of the whole system. Teams start ignoring failures, skipping test runs, or abandoning the test suite altogether.

So the technical overhead and the organizational resistance reinforce each other, and UI testing becomes one of those things that everyone agrees is important but nobody has the capacity to do well.

Best practices for implementing Salesforce UI testing

The teams that implement and maintain effective UI testing suites do so by following some key best practices and strategies.

• Start with your most-used user journeys. When you start to build your UI test suite, focus on your highest-traffic, most business-critical paths, such as quote creation, case submission, and order processing. This makes sure you’ve introduced coverage where failures are most visible and most costly, building confidence in the test suite before you start dealing with edge cases.
• Test as real users. A common mistake in Salesforce UI testing is running tests under a system administrator profile, which bypasses permission settings that can cause access issues and broken screens for users in production. Tests should reflect the actual profiles your users work under.
• Prioritize which tests run. Running a full UI test suite on every single change is often impractical and time-consuming. Being able to run specific tests on-demand allows for rapid feedback during development. The ability to schedule groups of tests to run alongside that means you can maintain structured regression coverage across releases without making test execution a bottleneck on every deployment.

�ұ𲹰������’s AI-powered UI test automation, built for Salesforce

The UI testing tools available to Salesforce teams broadly fall into two categories: generic automation frameworks that aren’t built to handle ����������ڴǰ�����’s specific quirks reliably, and Salesforce-specific tools that do handle the platform complexity but need to be integrated separately with your release pipeline. Either way, configuring and maintaining automated testing competes for time with active development — and often gets deprioritized as a result.

�ұ𲹰������’s Automated Testing is Salesforce-specific UI test automation built into your release pipeline. Using AI at the foundation of how tests are created and maintained, and with the 91�Թ��� Agent embedded for natural language questions and assertions, Automated Testing with 91�Թ��� is accessible and reliable without needing specialist resource or overhead.

AI-driven accessibility for the whole team

Test creation doesn’t require scripting expertise. Low-code test creation means anyone can build tests using recorded click-paths through expected behavior and natural language prompting. AI translates these inputs into automated tests without the user needing to script anything. That means any member of the team can easily get involved in test creation regardless of experience.

Test resilience with AI-powered self-healing

With three major Salesforce releases each year, the brittleness of automated UI testing is one of the biggest reasons adoption stalls. �ұ𲹰������’s AI-powered automation is resilient to Salesforce releases, adapting to UI changes to keep maintenance overhead down and coverage intact between releases.

Built specifically for Salesforce

Generic testing tools struggle with the Salesforce platform. �ұ𲹰������’s testing is designed specifically to handle Salesforce-specific challenges reliably, including Lightning components, Shadow DOMs, validation rules, permission-based user flows, and the behavioral differences between orgs. Plus, tests run under real user profiles and permission sets, catching access issues and workflow failures that admin-level testing would miss.

Integrated into your DevOps pipeline

Testing is built into the 91�Թ��� platform rather than operating as a separate tool. Tests run automatically as part of 91�Թ��� Pipelines, with customizable gating to block promotion of changes that fail tests. Integrations with Jira and Azure DevOps mean failures are linked directly to the work items that caused them, giving visibility across the team. The result is a continuous feedback loop on every change.

Automated UI testing you can rely on

Manual testing doesn’t scale, and generic test automation tools weren’t built for ����������ڴǰ�����’s complexity. �ұ𲹰������’s AI-powered automated testing solution gives any member of your team the ability to build, run, and maintain reliable UI tests that integrate directly into your release pipeline, so your team can catch issues early, iterate quickly, and release with the confidence that the changes will perform as expected in production.

Speak to one of our DevOps experts to find out how to implement reliable test automation that works for your team, or try it hands-on with a .

This is why Salesforce impact analysis is no longer optional. Without it, teams make changes based on assumptions instead of evidence, discovering problems only after deployment — when fixes are most expensive, and trust is hardest to recover.

Impact analysis is an essential part of change management. It helps you understand what a change touches, who it affects, and where risk concentrates before anything moves to production. In this guide, we’ll break down the fundamentals of Salesforce impact analysis, explore best-practice methodologies, examine the limits of native tools, and show how automated dependency mapping with �ұ𲹰������’s Org Intelligence enables safer, faster change at scale.

What is impact analysis, and why does it matter?

Impact analysis is the systematic process of identifying everything that could be affected by a proposed change before that change is implemented. In a Salesforce context, this means understanding how a single modification to metadata — such as a field, Flow, or Apex class — ripples through the wider ecosystem of automation, security, integrations, and user workflows inside your Salesforce org.

Impact analysis exists to reduce risk. Salesforce is highly declarative, but that doesn’t make it low-risk, and declarative tools like Flows, formulas, and validation rules can reference each other in complex, non-obvious ways. Without impact analysis, teams are forced into reactive firefighting: deploying changes first, then asking “what broke?” after users report issues. With impact analysis, change management becomes proactive: “What will this affect, who will it impact, and how do we mitigate risk?”

Salesforce impact analysis typically falls into three complementary categories, each aligned to different stakeholders:

• Technical impact analysis focuses on system integrity. It asks, “Will this change break the build?” This includes metadata dependencies, Apex references, trigger execution order, and governor limit implications. Developers and architects rely on this information to ensure deployments succeed and automation doesn’t fail at runtime.
• Functional impact analysis focuses on user outcomes. It asks, “Can users still do their jobs?” This covers Flows, page layouts, record types, reports, and permission-based access. Admins and business analysts use this to assess whether changes disrupt day-to-day workflows.
• Business or economic impact analysis focuses on value. It asks, “What happens to revenue, compliance, or customer experience if this fails?” Sales leaders, operations teams, and executives care about this layer because even a technically “successful” deployment can still damage the business.

In AI-driven Salesforce environments (such as ), these align closely with failure tiers: system failures (technical), unmet user intent (functional), and limited or lost business value.

For example, imagine an admin removes a custom field they believe is unused. Technically, the deployment succeeds. But that field was referenced dynamically in Apex, used in a Flow decision formula, and queried by an external integration. The result: automations silently fail, records stop syncing, and sales reps can’t advance deals. Impact analysis is what prevents these scenarios — by revealing hidden dependencies before they turn into production incidents.

Best practices for impact analysis in Salesforce

Rather than jumping straight into tools or checklists, effective impact analysis focuses on understanding how Salesforce components interact at different layers, where risk concentrates, and why certain changes are more dangerous than others. The practices below break impact analysis into core areas — dependency visibility, automation behavior, high-risk components, testing realism, and documentation — so teams can evaluate change holistically instead of in silos.

Dependency mapping

Dependency mapping is the foundation of effective Salesforce impact analysis. Before you can assess risk or plan mitigation, you need a clear picture of how components are connected — and Salesforce orgs contain far more connections than are immediately visible.

Dependencies exist at multiple layers, each requiring a different approach:

• Schema-level dependencies are explicitly defined in metadata. When a validation rule references a field, a page layout displays it, or a Flow uses it in entry criteria, that relationship is formally recorded and can be discovered through metadata analysis.
• Runtime dependencies are more difficult to detect. Dynamic Apex that constructs field names at runtime or formulas that evaluate conditional logic creates dependencies that don’t appear in static metadata. These relationships only emerge during execution, making them invisible to basic dependency checks.
• Data-level dependencies are tied to specific values rather than structure. Hardcoded record IDs, picklist values, or assumed data states can silently bind automation to fragile conditions. Comprehensive dependency mapping accounts for all three layers — structural, runtime, and data-driven — to avoid false confidence during change planning.

Analyzing Flow changes

Flows introduce some of the most complex and high-risk dependencies in Salesforce because they blend schema relationships, runtime logic, and execution context into a single automation layer. A small adjustment can dramatically change how — and how often — a Flow runs.

The first risk area is the trigger scope. Modifying entry criteria can turn a Flow that processes a handful of records into one that executes against thousands, introducing performance issues or governor limit failures. What appears to be a minor logic change can fundamentally alter execution volume.

Flows also rely heavily on data assumptions. Many elements expect records to exist in specific states or relationships. Changing query logic, filters, or branching conditions can cause downstream elements to receive no data — or unexpected data — leading to failed decisions or assignments.

Additionally, automation chains amplify risk. Flows frequently invoke other Flows, Apex actions, or platform events. A change in one Flow can cascade through multiple execution paths. Add environment-specific values like hardcoded Record Type or Profile IDs, and Flow changes quickly become one of the most critical areas for thorough impact analysis.

Analyzing custom field changes

Custom fields often appear low risk, but they create dependencies across nearly every layer of a Salesforce org. Changing or removing a field can have far-reaching effects well beyond its object record page.

The most visible dependencies are schema-level. Validation rules, formula fields, page layouts, reports, and Flows frequently reference custom fields directly. These relationships are explicitly defined in metadata and are usually easy to identify with standard dependency checks.

The real danger lies in hidden dependencies. Custom fields referenced in dynamic Apex don’t appear in static metadata because the field name is constructed at runtime. Lightning Web Components and Aura components can reference fields in JavaScript without creating formal dependencies. Email templates and integrations may consume field values without any structural linkage inside Salesforce.

Because custom fields often act as decision points for automation and reporting, impact analysis must extend beyond “where is this used?” and include runtime logic, UI code, and external consumers to avoid breaking critical processes silently.

Identifying high-risk components

Not all Salesforce metadata carries the same level of risk. Certain components disproportionately amplify the impact of change because they sit at critical junctions in automation, security, or execution order:

• Validation Rules can halt entire business processes if their logic is too restrictive or interacts unexpectedly with automation. Edge cases often surface only under specific data conditions.
• Record Types influence multiple layers simultaneously — page layouts, picklist values, business processes, and user access — making even small changes far-reaching.
• Permission Sets and Profiles control data visibility and edit access. Changes here can break automation that assumes specific permissions or silently block user actions.
• Apex Triggers execute on every record operation within their context. Modifying trigger logic affects all downstream automation in that transaction, making triggers some of the highest-risk components to change without thorough impact analysis.

Testing in realistic sandbox environments

Impact analysis identifies what could break, but only testing confirms whether those risks materialize in practice. The challenge is that most Salesforce sandboxes don’t reflect production reality.

Empty or lightly populated sandboxes hide failure modes. Automation that works perfectly on a handful of clean test records may fail under production conditions — large data volumes, null values, special characters, duplicates, and unexpected record states. These edge cases are where Flows, validation rules, and Apex logic tend to fail.

Realistic testing requires environments that mirror production complexity, not just structure. This means validating changes against representative data volumes and patterns so performance issues, governor limit breaches, and data-quality assumptions surface early. Without production-like testing, even well-executed impact analysis can create false confidence and allow critical issues to slip into production unnoticed.

Creating impact analysis documentation

Impact analysis only delivers long-term value and supports data governance when its findings are documented and shared. Undocumented analysis lives in individual heads and disappears under deadline pressure, forcing teams to repeat the same investigations for future changes.

Effective documentation records both what was analyzed and what was discovered. This includes identified dependencies, automation chains, integration touchpoints, permission implications, and known risk areas. It should also capture rollback considerations, testing outcomes, and which stakeholders need to be informed or trained.

Native tools for impact analysis

Salesforce includes several built-in and developer-oriented tools that support impact analysis, but they’re best understood as foundational aids, not complete solutions. Knowing what these tools can and cannot tell you is essential for using them effectively without developing a false sense of confidence.

The “Where is this used?” button

Salesforce provides native dependency visibility through the , available on certain metadata detail pages such as custom fields. This capability queries ����������ڴǰ�����’s underlying dependency data to surface direct, schema-level references recorded in metadata.

It reliably identifies usage across Page Layouts, Formula Fields, Validation Rules, Process Builder processes (displayed under the “Flow” category), Apex classes and triggers, Visualforce pages, Lightning components, reports, email templates, field sets, lookup filters, URL buttons, and Flow queries, where references are explicitly declared. When Process Builder appears under “Flow,” this reflects ����������ڴǰ�����’s internal architecture, as Process Builder is built on the Flow platform. For supported metadata types, the results are accurate and immediately actionable.

Yet, the “Where is this used?” feature has important and well-documented limitations. It does not surface Workflow Rule dependencies, detect dynamic Apex references, identify hardcoded IDs, reliably expose field usage inside Flow formula resources, or provide visibility into external systems accessing fields via REST or SOAP APIs. Additional documented constraints include a 2,000-reference limit, lack of support for joined reports, and restricted visibility based on user report access and managed package boundaries.

As a result, “Where is this used?” is best treated as a fast first-pass dependency check, not a comprehensive Salesforce impact analysis solution — especially as , and Flow-based automation has become the standard.

Visual Studio Code and metadata search

Developers frequently extend native impact analysis using with the . By working in a local SFDX project, teams can perform org-wide metadata searches that uncover references not visible in the Salesforce UI.

Modern tooling has reduced the setup burden significantly. The Salesforce Extension Pack now includes Org Browser, which allows developers to browse and retrieve metadata directly from an org without manually building a package.xml. Once metadata is available locally, global text search can surface field API names across Apex, Lightning Web Component JavaScript, email templates, and Flow definitions. Regular expressions remain a best practice for identifying hardcoded Salesforce IDs, a persistent source of deployment and environment-specific failures.

The core trade-off remains freshness rather than capability. Local metadata represents a point-in-time snapshot and can quickly become stale as changes are made directly in production. While this approach is effective for targeted investigations and one-off analysis, it requires ongoing retrieval and developer oversight, making it less suitable for continuous, org-wide impact analysis in large or fast-moving Salesforce environments without supplemental tooling.

�ұ𲹰������’s Org Intelligence: Impact analysis made easy

Building impact analysis on real understanding works in principle. The challenge is doing it at scale. Manual investigation copes with small orgs and isolated changes, but breaks down when metadata changes daily, automation chains deepen across teams, and institutional knowledge fragments faster than it can be documented.

Native tools don’t close the gap. They give partial visibility into the org’s current state, which compounds into partial visibility into a change’s impact. Teams end up making decisions from assumptions rather than evidence — and discovering the gaps in production.

�ұ𲹰������’s Org Intelligence was built to bring org understanding and impact analysis into a single view. The same metadata view that lets you understand what a Flow does also lets you trace what depends on it, so the journey from “what is this?” to “what breaks if I change it?” takes seconds rather than days.

What Org Intelligence provides

91�Թ��� Org Intelligence is an AI-powered analysis and planning solution that gives you instant visibility into your org’s structure, dependencies, permissions, and change history.

It analyzes all metadata types exposed by the and models them using graph database technology. This is what makes the single-view approach possible: every component is mapped in relation to every other, with bidirectional dependency information surfaced automatically — downstream impact (what references a component) and upstream requirements (what that component depends on) read from the same underlying graph. The result is a living map of your org, not a static report — and rather than clicking through dependency trees to interpret it, you can ask the 91�Թ��� Agent questions in plain English and get answers grounded in your actual metadata.

Find any component, fast

Investigating a change starts with locating the right component. Org Intelligence makes this fast even in orgs with thousands of metadata items.

Unified metadata search allows you to find functionality across hundreds of metadata types — Custom Objects, Fields, Flows, Apex Classes, Validation Rules, Permission Sets, Reports, Dashboards, Email Templates, and more — from a single interface. No clicking through setup menus, no guessing at where something lives.

Once you’ve located a component, the full picture is one click away: structure, dependencies, permissions, and history are all surfaced in the component view, ready to support whatever question you came to answer — whether that’s a change you’re planning, a Flow you’re trying to understand, or a stakeholder waiting for a “how does this work?” answer.

Complete dependency mapping

Dependency mapping is the heart of impact analysis. Org Intelligence surfaces both directions automatically, so you can see at a glance what relies on a component and what that component relies on in turn.

Bidirectional dependency analysis reveals risk from both angles:

• Referenced By shows downstream impact. When analyzing a custom field, for example, you can see every formula, validation rule, Apex class, report filter, and page layout that relies on it — so you know exactly what could break before you make a change.
• Depends On shows upstream requirements. This answers the deployment question: what must be included for this change to work elsewhere?

Crucially, Org Intelligence picks up where native tools leave off. It catches the dependencies they miss: dynamic Apex references, field usage inside Flow formula resources, hardcoded IDs, and relationships that cross managed package boundaries. It also maps dependencies for standard fields, not just custom ones — closing one of the most persistent blind spots in ����������ڴǰ�����’s built-in tooling.

Going deeper on Flows

Flows are first-class citizens in Org Intelligence — and for good reason. They’re often the highest-risk components in an org, blending schema relationships, runtime logic, and execution context into a single automation layer. They’re also some of the hardest to understand from the outside, especially when they’ve been built and modified by multiple people over years.

The Flow Navigator lets you explore Flow logic interactively without opening Flow Builder, making execution paths easy to follow at a glance. From there, you can drill down to element-level dependencies, seeing exactly where a field or resource is used — entry criteria, decision logic, assignments, or screen components.

Bidirectional analysis is just as detailed for Flows. Referenced By surfaces which Profiles and Permission Sets grant execution access — critical for understanding which users will be affected by a change. Depends On lists the objects, fields, record types, subflows, Apex actions, and other prerequisites a Flow needs to work, so nothing is missed at deployment time.

For teams managing complex automation chains, this means Flow changes can be assessed end-to-end — execution path, data dependencies, and user impact — in a single view.

Ask your org a question with the 91�Թ��� Agent

The 91�Թ��� Agent turns Org Intelligence into a conversational interface. Instead of clicking through dependency trees or writing SOQL to investigate a question, you ask in plain English and get an answer grounded in your org’s actual metadata.

It supports the full range of questions teams ask about their orgs — from understanding what exists today to assessing what a change will affect:

• Understand an automation chain step by step — “Walk me through what triggers when a Case is set to ‘Escalated’.”
• Surface permission configuration without manually inspecting each profile — “Which profiles have edit access to the Custom_Quote__c object?”
• Trace downstream impact across automation, reports, and integrations — “If I change Account.Industry, what happens?”
• Locate dependencies across specific metadata types — “Show me where the custom field Discount_Tier__c is referenced in Flows and validation rules.”

The Agent is particularly strong for understanding Flow and process automation, permission configuration, and custom object relationships — the areas where manual investigation tends to consume the most time. For questions that require returning a long, exhaustive list (such as every dependency of a complex object), the deterministic UI is still the better tool — and the two work together: explore conversationally with the Agent, then drop into the UI when you need the complete picture.

�ұ𲹰������’s Sandbox Seeding for realistic testing

Impact analysis identifies what could break; testing determines whether it actually breaks under real-world conditions. The challenge is that most Salesforce sandboxes are structurally accurate but data-poor, making them unreliable indicators of production behavior.

Testing Flows, validation rules, or Apex in an empty sandbox often produces false confidence. Automation that works on a handful of clean test records can fail in production when exposed to large data volumes, null values, special characters, duplicates, and unexpected record states.

�ұ𲹰������’s Sandbox Seeding solves this by deploying filtered, anonymized subsets of production data into test environments. It preserves referential integrity while masking sensitive data to meet GDPR and CCPA requirements. With realistic data in place, teams can validate governor limits, uncover data-quality assumptions, and observe true automation behavior.

Deploy with confidence, not crossed fingers

Salesforce impact analysis is what separates confident, scalable delivery from reactive firefighting. Native tools provide useful starting points, but they can’t keep up with the complexity of modern orgs — dynamic logic, deep automation chains, and evolving permission models demand visibility that native tooling was never designed to provide.

�ұ𲹰������’s Org Intelligence replaces manual guesswork with a complete, continuously-updated view of your org: searchable metadata, plain-English explanations your whole team can access, bidirectional dependency mapping, hardcoded ID detection, Flow-level insight, and an Agent that lets you ask questions in natural language. Combined with �ұ𲹰������’s Sandbox Seeding for realistic, production-like testing, you move from “we hope this works” to “we’ve proven it’s safe.”

If you’re ready to make Salesforce changes with certainty instead of anxiety, to experience 91�Թ��� Org Intelligence or book a demo to see how 91�Թ��� supports impact analysis from planning through deployment.

It’s a compelling proposition, and it’s already changing how developers and admins build on the Salesforce platform. But faster code generation brings with it a challenge that can’t be overlooked: your delivery process wasn’t built for high volumes of change. The review practices, quality standards, and governance controls that protect your org were designed around deliberate, human-authored changes. When an AI agent can produce and deploy an Apex trigger in the time it used to take to open a new file, those safeguards can fall behind quickly and production incidents creep in.

This post breaks down what Agentforce Vibes is, what it means for Salesforce teams, and why governance practices like structured code reviews, automated testing, and observability become more important when vibe coding enters your delivery process.

What is Agentforce Vibes?

Agentforce Vibes is ����������ڴǰ�����’s AI coding assistant that’s available as a web-based IDE or a VS Code extension, and is part of the wider Agentforce platform. Its vibe coding agent, Vibe Codey, enables developers to describe a feature in natural language and the coding agent will generate the code to build it.

Agentforce Vibes can be used to:

• Generate Apex classes, triggers, and tests
• Build Lightning Web Components and UI elements
• Create Agentforce agents
• Debug, refactor, and optimize existing code

Connecting directly to your Salesforce org, it draws on your existing metadata and codebase to inform what it generates — helping to keep new development consistent with your existing code. It’s designed to accelerate Salesforce development with more autonomous steps and less human input, which makes governance and oversight especially important.

From low-code to AI-prompted Salesforce development

The Salesforce platform has always leaned toward low-code and no-code. Most customization happens through a visual interface and declarative configuration, with Apex and Lightning Web Components reserved for more complex logic. Although Salesforce is designed to be accessible and easily configurable, writing and deploying changes still demands technical knowledge, careful review, and a clear understanding of how each change fits into the wider org.

Agentforce Vibes takes the simplicity of the Salesforce platform a step further. Instead of constructing changes manually, you describe what you want: “Create a Flow that assigns leads to the nearest available rep based on territory” or “Refactor this Apex class to improve test coverage.” Vibe Codey then translates the prompt into code. Your role shifts from author to reviewer: guiding, refining, and validating rather than building from scratch.

Benefits of vibe coding for Salesforce teams

Originally a term known only to niche developer circles, vibe coding has surged into the mainstream. Its significant impact on software development even led to it being named . Here’s why it’s taken the spotlight:

• Speed. Vibe coding is capable of accelerating development from ideation to build, which is particularly helpful for teams with a backlog of org improvements.

• Accessibility. As it uses conversational prompts, vibe coding breaks down technical barriers to entry. This means developers, admins and business analysts with limited deep coding and programming knowledge can become more actively involved in Salesforce code changes, helping to deliver a higher volume of updates more rapidly without needing to increase headcount.

• Developer productivity. Vibe coding can take care of those simple, routine, boilerplate tasks that take up a lot of valuable time, meaning you can reprioritize your team’s skillset to projects that deliver higher value or are more complex, such as strategic architecture, logic or system design.

• Salesforce integration. Vibe coding through Agentforce Vibes integrates with your org’s metadata automatically, so the AI agent knows your objects, fields and existing code. It also understands Salesforce schema and is less likely to get tripped up by some of the platform’s idiosyncrasies.

Agentforce Vibes is designed to accelerate developer productivity — letting teams build faster and offload repetitive coding work to AI, within the context of your Salesforce org.

Considerations and limitations of Agentforce Vibes

Vibe coding ������’t a replacement for engineering judgment. There are a few key considerations Salesforce teams should keep in mind if adopting Agentforce Vibes:

• Tech debt can increase. When Vibe Codey writes an Apex trigger or generates a Flow, someone on the team needs to be able to read it, understand it, and own it. The rapid introduction of AI-generated code significantly increases risk, if your team don’t understand the changes being made — from production incidents and costly downtime, to long-term .

• Usage limits restrict scalability. Each Salesforce org has a daily quota of premium requests, with additional usage handled by a lower-capacity fallback model. These limits can be consumed quickly by complex tasks, meaning teams need to prioritise how and when they rely on the tool.

• Contextual awareness ������’t foolproof. While Agentforce Vibes has awareness of your org, it can still misinterpret dependencies, conflict with existing automation, or suggest outdated APIs. It may generate code that passes initial checks but fails at runtime, or references fields and logic that don’t exist. These inaccuracies and hallucinations introduce real risk if not properly reviewed.

• Rigorous testing is a must. Even when code is generated quickly, it still needs to go through proper testing, validation, and deployment processes. AI can accelerate development, but it doesn’t replace the need for quality assurance.

The importance of governance for AI-generated code

Agentforce Vibes is a powerful tool, but with the rapid take-up of AI-generated code comes several risks and challenges.

The biggest problem is that it generates a lot of code, very quickly, in a way that can easily outpace the review processes your team has built around slower, more deliberate development. This means vulnerabilities can easily be introduced and could go unnoticed until release day — or worse, once it’s already in production.

And if your team already struggles to get visibility into your org’s metadata and dependencies, adding AI-generated code only compounds the problem. Agentforce Vibes can produce in minutes what would take a developer days, flooding an already complex org with new code, new dependencies, and new potential failure points. Ensuring deep system visibility through DevOps best practices and automated governance is the foundation you need before AI can safely add to your org at speed.

What about the Salesforce Trust Layer for governance?

Agentforce Vibes is covered by the , which governs what happens when the extension sends prompts to an underlying LLM. The Trust Layer ensures that nothing sent to the model is retained or used for training — given that Agentforce Vibes is restricted to sandbox environments, what’s in transit is largely code context and metadata rather than live customer data. That’s an important security control but it’s not a governance framework.

AI-generated code is still code: it can introduce bugs, break integrations, create security vulnerabilities, and conflict with existing automations. The Trust Layer has no mechanism to prevent this, such as enforcing code quality, testing requirements, or peer review processes that keep production stable. And Salesforce restricting Agentforce Vibes to sandboxes confirms that AI-generated code does need to be validated before it goes anywhere near a production org.

This is why DevOps and a robust governance framework is vital for teams looking to adopt AI-supported coding. Teams that can adopt Agentforce Vibes responsibly are those with a CI/CD pipeline that already has automated testing, static code analysis, and code review built-in. That is what makes it safe to move at the speed vibe coding enables. Without it, you’re not moving faster. You’re just accumulating risk you won’t see until it’s already in production.

How 91�Թ��� helps you govern AI-generated Salesforce code

91�Թ��� is purpose-built for Salesforce delivery and designed to handle the governance challenges of AI-generated code.

Automated quality checks to handle volume

As your team builds, governance can’t rely on individuals remembering to follow process. With �ұ𲹰������’s automated CI/CD pipelines, AI-generated code moves through the same build, test, and review stages as anything your team writes by hand.

Code Reviews is built directly into that workflow, enforcing automated quality gates consistently, and any code that doesn’t pass is blocked before it can cause problems downstream. Unlike generic code analysis tools or asking an AI to check its own output, �ұ𲹰������’s code review is Salesforce-native. It understands your org’s metadata, existing code, and configuration — as well as the specific quirks of the platform.

When AI is generating code at volume, manual UI testing doesn’t scale. Run UI tests automatically after every change to check that real user journeys still work — and block Apex deployments on unit test failures, so broken code can’t advance before it’s fixed.

Proactively monitor production performance

Even deployable code can behave unexpectedly in production. �ұ𲹰������’s observability tooling provides real-time visibility into Flow and Apex errors, org limits, and runtime issues as they happen, so you can catch problems early and link them back to specific deployments. And if something does go wrong, backup and restore lets you quickly roll back to a known good state with ease.

Move quickly and safely with Agentforce Vibes

The teams that get the most out of Agentforce Vibes will be those that use it to accelerate delivery while maintaining strong review, testing, and governance processes. 91�Թ��� enables both — helping you move faster without compromising stability, security, or auditability.

Catch up on our Scale AI Safely webinar to see how leading Salesforce teams are adopting AI responsibly, or speak to one of our DevOps experts for a tailored demo to see how 91�Թ��� can help you vibe code safely.

With observability tools that come with AI built in, teams can go beyond simply spotting issues. They can instantly understand them, prioritise them, and quickly take action without the usual time spent digging through logs or piecing together context.

In this post, we’ll explore what observability means in a Salesforce context, why it’s essential for proactively minimizing production incidents, and how the 91�Թ��� Agent helps you move from reactive monitoring to fast, confident resolution of Flow errors.

Monitoring vs observability: what’s the difference?

Observability is often misunderstood as monitoring. But they’re not the same and, for Salesforce teams dealing with complex orgs and fast-moving releases, the difference matters.

Monitoring flags when something’s gone wrong, usually based on pre-defined failure scenarios or thresholds, and sends you a notification. However, teams can often get overwhelmed with the volume of alerts and emails from Salesforce, especially when there’s no easy way to understand what caused the issue, how to prioritize them, or what you need to do next.

Instead, you end up spending valuable time digging through logs, chasing symptoms, and relying on users to tell you what’s gone wrong. Even then, it can be really hard to distinguish meaningful spikes from all the background noise, so there’s a risk teams either miss critical issues or end up chasing false positives.

“Flow error alerts came through email — and that alone was a challenge. You’d miss things, there was no context, no sense of the growing volume of errors. You were constantly backtracking.” — Jolene Mair, HackerOne Salesforce Applications Engineer IV

Observability, on the other hand, gives you clear visibility of the current state of your org, based on your org’s outputs — so you can spot and understand trends or issues as they happen and often before they’re reported by an end user. It gives you a head start in answering questions like:

• What exactly has gone wrong and where?
• Who’s been affected?
• Why has it happened?
• How do I fix it?
• How do we prevent it happening again?

By arming you with these insights, you’re in a better position to identify issues proactively, uncover root causes, and resolve problems efficiently. It moves you from reactive fixes to ongoing improvement in the robustness of your org, helping you catch issues early and leverage key insights to resolve them before they start costing your business money or creating end-user frustration.

Why Salesforce teams need observability

Observability is a key part of the DevOps lifecycle. It provides a continuous feedback loop, to strengthen your current org health and create a more stable platform — enabling your team to move from firefighting to proactive org management.

Up until now, the main focus for many Salesforce teams has been on building reliable deployment processes, as release day is often where the pain of change management is felt most acutely. As a result, observability hasn’t been as widely implemented in the Salesforce ecosystem.

The State of Salesforce DevOps 2025 found that 49% of Salesforce teams have no plans to implement observability tools. But without observability, issues often only come to light when an end user reports them, leading to disruption and costly system downtime. Teams that do have an observability solution were 50% more likely to catch bugs within a day and 48% more likely to fix them within a day, compared to teams without observability. This responsiveness is exactly why for Salesforce teams looking to implement a robust DevOps process that proactively safeguards their orgs.

Does Salesforce have native observability tools?

Salesforce has some tools for monitoring performance and errors, but they are scattered in different areas and have limitations:

• Free tools. Built-in tools like Debug Logs, Flow error emails, and Apex exception alerts help flag issues, but they’re reactive, disconnected, and often require significant effort to interpret and piece together.

• Salesforce Shield (paid add-on). Salesforce Shield adds deeper visibility through event monitoring and auditing, but is primarily focused on security and compliance, with added cost and complexity that can limit its use for day-to-day DevOps troubleshooting.

• Agentforce (AI-powered capabilities). Agentforce introduces AI into the Salesforce platform, but it’s broad in scope and not specifically designed to provide real-time, actionable insight into errors and system issues.

While these observability tools surface useful data, they still leave teams doing the heavy lifting to understand, prioritise, and resolve issues quickly.

91�Թ��� Observability: monitor the health of your org easily

When something breaks in Salesforce, the process of finding and fixing the issue should be simple. �ұ𲹰������’s Observability solution brings Apex and Flow errors, along with Salesforce org limits (such as daily API requests), together into a centralized, user-friendly dashboard with real-time updates. Here you can visually track your org’s health over time, letting you easily catch issues early, spot any trends quickly, and understand their impact at a glance. It also helps you categorise and prioritise fixes or make strategic decisions based on what has the biggest impact on your org health — without needing to sift through error emails or wait to find out about an issue from your end users.

Once you’ve identified the problems that need to be tackled, you can streamline debugging with deployment history mapping — quickly identify which release coincides with when the issue started occurring, for quicker root cause analysis. 91�Թ��� also lets you automatically create tickets in Jira or Azure DevOps Work Items, so you can start the fix process seamlessly. This arms your team with the information they need to pick up the task and work through the resolution.

Action Flow insights swiftly with the 91�Թ��� Agent

While observability enhances your visibility and insight into your org, there still often comes the challenge of team capacity. Being able to dedicate the resources needed to scope and build the fixes can be difficult.

That’s where the 91�Թ��� Agent can help. The Agent comes built-in to the Observability platform and feeds directly from the Flow metadata and metrics within your org. When a Flow error happens, it gives you instant insight into three core questions:

1. What is the error? Get a clear, concise overview of the Flow error at the click of a button. �ұ𲹰������’s Agent translates raw Salesforce error messages into easy-to-understand explanations, saving time and making this step accessible to both developers and admins regardless of their experience or knowledge level.

2. What caused this error? �ұ𲹰������’s Agent quickly identifies the most likely root cause of the issue, ranked by probability. These insights are based on the Flow’s metadata and known behavior — giving you logical, evidence-based answers without manual investigation.

3. What are potential fixes for this error? Rather than working out the next step yourself, �ұ𲹰������’s Agent suggests possible fixes with a single click, again ranked by likelihood. This arms your team with effective solutions, so they can focus on delivering a fix quickly.

So when a Flow stops working, the 91�Թ��� Agent helps you resolve the issue with:

• Speed. Cut down the time needed to diagnose, scope and resolve Flow issues with insights that instantly pinpoints them and suggests optimal fixes for a swift outcome.

• Accessibility. Clear, simple explanations on the what, where, why and how that anyone on the team can understand and act on, without needing to understand the complexities or background of the Flow in question.

• Intelligence. No guesswork or assumptions, just logical, deterministic answers based on a sound understanding of the Flow error and of the workings of your org.

This helps teams with limited capacity or resource constraints to focus time exactly where it’s needed, so Flow problems can be easily fixed with minimal upfront effort.

Stay one step ahead with the 91�Թ��� Agent in Observability

�ұ𲹰������’s Observability solution brings best practices to Salesforce teams, without the need for specialist setup or ongoing maintenance. It gives you enhanced visibility, insights and context to any issues encountered, helping you plan better, respond faster, and improve platform stability and business outcomes. And when combined with �ұ𲹰������’s Agent, you can also leverage that insight to give actionable solutions to Flow errors at speed.

Speak to one of our DevOps experts for a tailored demo to see how �ұ𲹰������’s Agent in Observability can streamline your Flow error handling, or .

This guide explains what solution design for Salesforce actually involves, walks through the end-to-end process, and shows how modern teams bridge the gap between planning and execution using platforms like 91�Թ��� to understand impact before making changes.

What is Salesforce solution design, and why does it matter?

Solution design is how you translate business requirements into technical architecture that actually works long-term. It’s not just writing down what stakeholders ask for. It’s figuring out why they’re asking, challenging assumptions, and designing solutions that fix the real problem — not just the symptoms. This becomes especially critical when implementing Salesforce across complex organizations.

Most Salesforce problems aren’t simple or isolated. These orgs typically involve tangled data models, flows, Apex triggers, security models, integrations, and a whole host of custom metadata. Solution design gives you a framework for making those decisions deliberately instead of reactively.

Without it, you end up with what teams call a “Franken-org” — a Salesforce instance stitched together from point solutions built in isolation. Over time, this creates brittle automation, duplicated functionality, blocked upgrades, and maintenance costs that keep climbing. Strong solution design prevents this by making sure every change fits into a coherent, scalable plan.

Step-by-step: the solution design process

Effective solution design follows a structured process where each phase builds on what came before. The goal ������’t just documentation — it’s creating a shared understanding of what needs building, why it matters, and how it fits into your broader architecture before anyone starts writing any code.

Step 1: ask the right questions

Strong solution design starts with rigorous discovery through workshops with business stakeholders, interviews, and job shadowing — seeing how users actually work rather than just taking their word for what they need. Key artifacts include stakeholder maps, detailed personas, and user stories written as “As a [persona], I want to [action], so that [objective]." Requirements should be assessed against standards like INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) to make sure they’re actionable and design-ready, which helps prevent scope creep later.

Step 2: map out the business process

Business process mapping translates abstract requirements into a clear view of how work actually flows through the organization before anything is configured in Salesforce. is a modeling approach that avoids the common pitfall of traditional swimlane diagrams — blurring who performs work with what work is performed. Instead, UPN separates concerns: activities describe what happens, resources show who does it, and arrows indicate when it happens. Best practices include using clear labels (like “Submit Quote” or “Approve Request”), limiting diagrams to eight to ten activities per screen, and using hierarchical drill-downs so high-level processes reveal detail only when needed.

Step 3: validate your requirements

Requirements validation is where stakeholders confirm that what you’ve documented actually reflects how the business operates and what the solution needs to deliver. Validation happens through structured “playback” sessions where you walk stakeholders through the documented requirements and process maps. Written sign-off matters more than verbal agreement, because you avoid any disputes later. Validated requirements act as a gate: until this step is complete, don’t progress to designing data models, automation, or integrations.

Step 4: match solutions and identify gaps

Solution matching determines which validated requirements can be satisfied using ����������ڴǰ�����’s out-of-the-box capabilities before considering custom builds. Standard features like Forecasting, Lead Assignment Rules, and approval processes are deeply integrated into the platform and continually improved. Leveraging these design patterns reduces maintenance overhead. Gap analysis then identifies the smaller set of requirements that genuinely need customization. Meeting 80% of a requirement using standard features often delivers greater business value than pursuing a fully custom solution for 100% coverage.

Step 5: design your data model

Data modeling defines the structural foundation of your org. A clear shows how objects and relationships work — how data gets stored, secured, and queried. The big decision is choosing between Lookup and Master-Detail relationships: Master-Detail enforces tight coupling where child records inherit security and get deleted with the parent, while Lookup provides looser coupling with independent ownership. Plan for standard objects first (Account, Contact, Opportunity, Case) since they come with built-in features custom objects lack. Keep field counts manageable — approaching 150+ fields on a single object signals you need to reconsider your design. For large data volumes, consider performance implications through custom indexes and proper configuration choices.

Step 6: define your security and sharing architecture

Security and sharing architecture defines how data visibility and access is controlled across your org. Use a “layer cake” model: start with Organization-Wide Defaults set to Private for least-privilege access, then expand visibility using Role Hierarchy, Sharing Rules, and Permission Sets. Field-Level Security protects sensitive data by hiding fields from unauthorized users. Design security early as a core architectural decision, not a retrofit.

Step 7: plan your integration architecture

Integration architecture defines how Salesforce exchanges data with the rest of your enterprise. Choose integration patterns deliberately: Request & Reply for synchronous interactions, Fire and Forget for asynchronous use cases, and Batch Data Synchronization for high-volume data movement. It’s common for teams to practice building for failure and design integrations they assume will break something. Other best practices include using Named Credentials to keep credentials out of code, versioning APIs to prevent breaking changes, and defining clear Systems of Record prevents “split brain” scenarios where multiple systems try to control the same data.

Step 8: prototype and test high-risk areas

Prototyping validates high-risk or complex aspects of a solution before committing to a full build. The goal is to “fail fast” by testing assumptions early — like discovering that a proposed Lightning Web Component is too complex or slow in a sandbox rather than after production deployment. Prototypes let stakeholders interact with proposed interfaces and provide concrete feedback on usability, especially valuable for custom UI, complex approval logic, or integrations where feasibility is uncertain.

Step 9: write a detailed Solution Design Document (SDD)

The Solution Design Document (SDD) is the authoritative blueprint that translates validated requirements into build-ready guidance. It specifies exact field and API names, data types, Flow logic, and Apex class structures where needed. A simple test: a developer should be able to implement the solution using the SDD without repeatedly seeking clarification. Core components include architecture diagrams, UPN business process flows, ERDs with object and field specifications, and a fully defined security model. Choose Flow as your default for new automations and avoid mixing automation tools on the same object. Document all design decisions and tradeoffs — when you chose Flow over Apex or a Lookup over Master-Detail, always explain why.

Step 10: review against architectural standards

The final validation step evaluates your solution design against established architectural standards before development begins at scale. This review ensures no common anti-patterns have been introduced — like hardcoded IDs, SOQL inside loops, or overly complex automation. The review covers both high-level design decisions and detailed implementation choices. ����������ڴǰ�����’s provides a practical lens for evaluation with its three pillars: Trusted (secure, compliant, reliable), Easy (intentional, automated, engaging), and Adaptable (resilient and composable). Official guidance and reference architectures are available through the . �ұ𲹰������’s Code Reviews can strengthen validation by applying Well-Architected managed policies automatically.

Common challenges, risks, and how to avoid them

As Salesforce orgs expand across multiple clouds and integrate with more systems, the challenge shifts from how to build to how to keep everything coherent. Team engagement with solution design becomes critical when managing complexity at scale. Here are the risks that show up most often in real-world implementations — especially in multi-cloud environments — and how intentional solution design helps you maintain focus and prevent them before they get expensive to unwind.

Multi-cloud data modeling and identity resolution

Multi-cloud Salesforce environments — spanning , , , and — create a challenge: the same customer often exists in multiple forms. A single person may appear as a Lead in Sales Cloud, a Subscriber in Marketing Cloud, and a User in Commerce Cloud. Without deliberate design, these records stay disconnected, fragmenting customer insight.

Salesforce Data 360 addresses this through identity resolution using exact matches and fuzzy logic. For example, a customer using emily.swift@gmail.com in-store and emily_swift85@outlook.com online looks like two separate people, even though the business needs to treat them as one. Effective solution design ensures this unification works by correctly mapping Source Objects to Data Model Objects. Get this right early to enable accurate reporting and consistent experiences across every cloud.

Integration patterns and master data management

In multi-cloud architectures, clear ownership prevents chaos. Define which system controls what — Salesforce Core for customer profiles, ERP for products and pricing, Data Cloud for behavioral data. Without this, you get conflicting updates and unreliable reporting. Integration patterns like Marketing Cloud Connect or Order Management then move data between clouds in a controlled way, keeping everything coherent as you scale.

Anti-patterns and technical debt

Anti-patterns are recurring design mistakes that look like solutions but create more problems than they solve. Unlike one-off errors, they’re patterns that teams repeat across projects because they seem to work in the short term. The cost shows up much later in the form of brittle systems, mounting technical debt, and orgs that get harder to change over time. Strong governance helps catch these anti-patterns before they become entrenched.

Common anti-patterns include:

Over-customization. Building custom objects, Apex, or UI components when standard Salesforce features already fit the job increases maintenance overhead and breaks compatibility with future platform enhancements.

Data silos and fragmentation. Systems implemented in isolation leave customer data fragmented across clouds, undermining reporting and personalization. Multiple systems trying to control the same data leads to conflicts.

Ignoring technical debt. Skipping proper error handling, hard-coding values, or building brittle integrations saves time today but costs more later. Obsolete automation like Workflow Rules and Process Builders accumulates when no one assesses whether they’re still active.

Poor data quality by design. Missing validation rules or inconsistent data models render analytics unreliable. Design validation into your architecture from the start.

Treating security as an afterthought. Bolting on sharing rules late instead of designing least-privilege access from the start creates security gaps and compliance risk.

Neglecting user adoption. Architecturally sound but operationally unusable systems fail in practice. Complex automation and cluttered interfaces drive workarounds outside Salesforce.

Implementing your solution design with 91�Թ���

Strong solution design sets the technical direction, but successful delivery depends on how well that design survives contact with real environments. This is where many well-architected solutions fail — not because the design was bad, but because teams lack visibility into dependencies, environmental drift, and release impact until changes are already moving. By the time issues surface, they’re costly to fix and disruptive.

91�Թ��� closes this gap by mapping the entire architecture of your org. Instead of designing in isolation, you get immediate insight into how proposed changes interact with existing metadata already present in your org. When defining security models, data structures, or integration patterns, you can see which components already exist, what depends on them, and how changes will propagate across environments. This helps you streamline your process and validate ideas before committing to a build.

This transforms solution design from a theoretical exercise into a build-ready discipline. You can validate that designs aren’t just well-structured but also deployable. Delivery teams move faster with confidence, knowing that dependency conflicts, missing components, and release risks are being identified early. The result is a smoother path from design to deployment — fewer surprises, fewer failed releases, and solutions that behave as designed when they reach production.

Org Intelligence: Design with full lifecycle visibility

Traditional solution design often happens in a vacuum. Architects document an ideal-state architecture without a clear understanding of what already exists in the org, how components are connected, or which dependencies will be affected by proposed changes. This disconnect is a major reason why well-designed solutions still fail during build or release.

�ұ𲹰������’s Org Intelligence changes this by providing instant, comprehensive visibility into your full Salesforce estate and metadata configuration — supporting solution design, validation, and delivery across the entire DevOps lifecycle, not just at release time. Here’s how:

Dependency analysis before committing to a design. Before finalizing an Entity Relationship Diagram or security model, Org Intelligence shows exactly what components already exist and how they are connected. For example, when proposing a new field on Account, architects can immediately see every Flow, Report, Dashboard, Apex class, and integration that references the Account object. This allows designs to work with existing dependencies instead of uncovering conflicts halfway through development.

Impact analysis as part of solution validation. Org Intelligence adds a critical feasibility layer — whether the design can be built and released without breaking existing functionality. Field utilization analysis reveals whether an “unused” object or field actually participates in automation that runs infrequently — such as a quarterly compliance Flow — preventing redesign decisions based on incomplete information.

Historical context for better architectural decisions. Org Intelligence surfaces change history, showing who created components, when they were introduced, and the context behind those changes. This insight helps architects avoid re-solving previously addressed problems, recognize patterns that worked well, and prevent repeating past mistakes — all while designing solutions that align with the org’s real operational history.

Validate design integrity across your release process

Solution design documents define what should be built, but your release process determines whether that design survives implementation. Without enforcement and verification, even well-written Solution Design Documents (SDD) drift as changes move across sandboxes and into production. Validating design integrity ensures that what developers build aligns with the architecture you approved — and that it can be promoted safely across environments.

Automated validation enforces architectural standards. Relying on manual reviews alone does not scale as delivery velocity increases. Static code analysis embedded in the CI/CD pipeline allows teams to automatically enforce the architectural principles defined in the SDD. Rules such as “no SOQL inside loops”, “no hardcoded IDs”, and “minimum test coverage thresholds” are checked before changes are promoted. The SDD sets expectations, and automated validation ensures those expectations are consistently met, regardless of who wrote the code.

Catch missing dependencies before promotion. Many release failures aren’t caused by bad design, but by incomplete deployments. Security and integration architectures often span dozens of metadata components — permission sets, field-level security, sharing rules, Flows, and connected apps. If even one dependency is missing, you won’t be able to deploy your solution to further environments. 91�Թ��� automatically detects missing dependencies before promotion, ensuring that the security model, automation, and integrations you designed arrive successfully in the target environment.

Rollback capability supports resilient architecture. Well-architected solutions account for recovery as well as success. Even with strong design and validation, complex systems can behave unpredictably. Rapid rollback to a previous, stable state minimizes disruption when issues arise, protecting users and business operations. Resilience ������’t an afterthought — it’s an architectural requirement, and your release process must support it.

Turn solution design into confident releases

The gap between design and deployment has always been a hard challenge to tackle. Architects plan in abstraction, developers build in isolation, and release failures expose architectural issues only after you’ve already spent time and budget. Closing that gap requires embedding release intelligence directly into the design process.

With purpose-built DevOps platforms like 91�Թ���, you can evaluate dependency impact before building, enforce architectural standards automatically, and validate that what gets released matches what you designed. The result is faster delivery with fewer regressions, less rework, and more trust in every release.

Ready to turn solution design into confident, repeatable releases? or book a demo with 91�Թ��� to see how leading Salesforce teams design and deliver with confidence.

What is Agent Script?

Agent Script is ����������ڴǰ�����’s new way of defining how an Agentforce agent reasons, acts and communicates — all in a single, portable text file.

Think of it as the instruction manual for your AI agent, blending prompt engineering and business logic. An Agent Script file tells the agent who it is, what it’s allowed to do, how to use Salesforce tools — all in one place. Importantly, this file is easy to read and edit by humans and agents alike, as well as being the shared source of truth.

Agent Script is central to what Salesforce calls “hybrid reasoning” — the idea that production-grade agents need more than just a capable LLM. They need deterministic rules, clear checkpoints, and tight control over what context the model sees at every step.

With Agent Script, you get:

• One source of truth. Your agent’s full configuration lives in a single, versioned file — not spread across dozens of screens.
• Human and AI collaboration. Because the format is clean, structured text, both builders and AI assistants can read, write, and reason about it natively.
• Precision control. You can enforce deterministic logic for routing, validation, and permissions, while keeping model reasoning for the moments where it adds value.
• Full portability. The file can move through code reviews, version control, and deployment pipelines just like any other piece of Salesforce metadata.

Deploying Agent Scripts with 91�Թ���

91�Թ��� makes it easy for you to deploy Agentforce metadata, and that includes support for Agent Scripts.

Agent Scripts compile down to Salesforce metadata with dependencies on other metadata types. Here’s how you can deploy your Agent Script metadata — and how 91�Թ��� makes sure you don’t miss any dependencies.

1. Compare source and target environments

First, select the environments you need to move the Agent Script between. In this example, the source environment is a developer org and the target is a Git branch. Using �ұ𲹰������’s default filter for Agentforce deployments will retrieve the metadata types you need to deploy an Agent Script. Hit Compare now.

In the comparison view you can see what’s new, changed and deleted. This Agent Script is under the New tab, which means it’s in the source but not the target environment. Clicking on any item shows how it compares between the environments, and you can dig into dependencies as well.

A note on versioning: When Agent Scripts are retrieved via the Metadata API they’re given a numerical suffix showing the Agent Script version. In the 91�Թ��� comparison, you’ll see the latest version from the source compared to the latest version in the target. Deploying an Agent Script creates a new version in the target org.

2. Select the changes to deploy

To deploy an Agent Script successfully, you need to deploy the related Bot Version, Einstein Bot, and Agent Planner Bundle (a friendlier label for the GenAIPlannerBundle metadata type).

If you were to miss a dependency at the comparison view, �ұ𲹰������’s automatic problem analysis would catch this for you. 91�Թ��� will recommend including the missed dependencies to make sure the deployment is successful.

3. Deploy (or commit) your Agent Script!

The next screen in 91�Թ��� shows a summary of your deployment. You can give the deployment a name and leave a note, which will make your 91�Թ��� deployment history easier to review (as well as becoming the commit name and message when you’re committing to Git).

If you’ve integrated with an issue-tracking tool such as Jira, you can attach the deployment here. When deploying to a Salesforce org, you can kick off a Salesforce validation from 91�Թ��� and check the deployment will succeed. When you’re ready, you can deploy or commit the changes — or schedule for later if needed for a release window.

Once you’ve successfully deployed or committed your Agent Script, �ұ𲹰������’s results page surfaces the most likely actions you’ll want to take next. In this case, you’d probably want to open a pull request next. But there are other options too, including full or partial rollback.

DevOps fundamentals for Agentforce success

To deliver success with Agentforce, your agents need to be built, tested, deployed and monitored like other Salesforce metadata. Deploying Agent Scripts with 91�Թ��� is just the start. The wider 91�Թ��� platform gives you an end-to-end process for the DevOps lifecycle, so you can innovate on the Salesforce platform with both speed and stability.

Get started with Agent Script

Don’t let deployment challenges hold you back from succeeding with Agent Script. to test out deploying your metadata in a few easy steps. And you can book a tailored demo with one of our DevOps experts to see how 91�Թ��� will help get your Agentforce implementation on track.

But what happens when data is permanently deleted? After 15 days, or when you hit the storage limit, records are automatically purged from the Recycle Bin.

In this guide, we’ll explore exactly what you can do at every stage of data deletion — from simple Recycle Bin restores to recovering from more serious data disruption. We’ll explain why native Salesforce tools only go so far and why a dedicated backup and recovery solution like 91�Թ��� is essential for true peace of mind.

Recovering from the Salesforce Recycle Bin

When you delete a record in Salesforce, it doesn’t vanish immediately. Instead, Salesforce performs a “soft delete”, marking the record as deleted and moving it to the Recycle Bin.

Every user has access to “My Recycle Bin”, which contains records they’ve personally deleted. Administrators and users with the “Modify All Data” permission can also access the “Org Recycle Bin” to view and restore any deleted records across the organization.

Restoring a deleted record is simple:

1. Go to the App Launcher, search for “Recycle Bin”, and open it.
2. From there, you can filter and sort records just like a standard list view.
3. Once you find the record — for example, a deleted Contact — simply select the checkbox and click “Restore”.

The record will reappear in its original state, with its data fields intact and most lookup relationships restored. Keep in mind that Salesforce only restores lookup relationships that haven’t been replaced.

Mass recovery from the Recycle Bin

Manually restoring a lot of records is obviously impractical. Thankfully, there are ways to restore a large batch of deleted records from the Recycle Bin in Salesforce:

• Using Apex (ALL ROWS keyword): In Apex code, you can query deleted records using the ALL ROWS keyword. This retrieves both active and soft-deleted records.

List<Account> deletedAccounts = [SELECT ID FROM Account WHERE IsDeleted = TRUE ALL ROWS];
System.debug(deletedAccounts);

You can run this code in the Developer Console’s Execute Anonymous Window (Ctrl + E), not in the Query Editor. From there, you can export record IDs and prepare them for restoration using tools like Data Loader.

• Using Data Loader: The most straightforward method for most admins is Data Loader’s Export All operation. By selecting Export All Records and filtering with IsDeleted = TRUE, you can export deleted records to a CSV file. Then, use Data Loader’s undelete() operation to restore them in bulk.
• Using Workbench: Workbench doesn’t support the ALL ROWS keyword directly, but you can achieve the same result by enabling the Include Deleted and Archived Records checkbox when running a SOQL query. This allows you to view deleted records and export their IDs for recovery.
• Using Salesforce APIs: For developers automating recovery, the REST API uses the queryAll endpoint, and the SOAP API uses the connection.queryAll() method — both serve the same purpose as ALL ROWS in Apex, returning deleted records for programmatic recovery.

These methods allow you to restore hundreds or thousands of records in one go, but they require some familiarity with SOQL, CSV manipulation, and data management tools. For organizations that need to recover large datasets quickly and safely — especially when relationships between objects must be preserved — a dedicated backup and restore solution like 91�Թ��� provides a more reliable, user-friendly alternative.

Why you can’t rely on the Recycle Bin for data recovery

There are two constraints to be aware of when it comes to the Recycle Bin: time and storage.

The time constraint is that deleted records remain in the Recycle Bin for 15 days before Salesforce automatically and permanently deletes them. After that point, the data is gone for good. In Salesforce Classic, admins can extend this to 30 days by enabling the “Extended Recycle Bin Retention” setting in Setup > User Interface — or by logging a case with ����������ڴǰ�����’s Feature Activation team. This option ������’t available in Lightning Experience.

The storage constraint is that the Recycle Bin can only hold data equal to 25 times your org’s data storage in megabytes. For example, a 10GB org has a Recycle Bin capacity of roughly 250,000 records. While that sounds generous, it can fill up faster than expected, especially after mass updates, integrations, or user errors. When the limit is reached, Salesforce automatically purges the oldest records, even if they haven’t yet surpassed the 15-day mark.

Once either of these constraints is exceeded, your records are permanently deleted — leaving a serious recovery gap that only a dedicated backup solution can fill.

Recovering data when the Recycle Bin ������’t enough

Once records are permanently deleted from the Salesforce Recycle Bin, they’re gone for good, and Salesforce doesn’t automatically protect you from this kind of data loss. Backing up and restoring data is your responsibility, so having a robust backup solution is essential for any organization.

Why metadata backups are also essential

You need to protect your Salesforce metadata too. Metadata defines the entire structure of your Salesforce org: the custom objects, fields, workflows, validation rules, and permissions that determine how your org functions and how data is stored. If that structure is lost or corrupted, your data backups become much harder to restore. For example, you can’t recover invoice records if the Invoice custom object they belong to no longer exists, and you can’t re-establish the right access controls if your permissions model has been wiped out.

Metadata is also constantly changing as admins and developers build out new features and configurations, which makes it especially vulnerable to unintended modifications or accidental deletions. Rebuilding a complex org’s metadata manually can take weeks or even months, causing significant disruption and cost.

How 91�Թ��� protects you from permanent data loss

91�Թ��� provides the protection and flexible recovery capabilities that organizations need to ensure continuous, resilient operations within Salesforce. Here’s how 91�Թ��� stands out with complete backup coverage for Salesforce.

Automated data and metadata backups

91�Թ��� offers full coverage by backing up both data and metadata. It supports 700+ metadata types, plus configuration data like CPQ configurations, Vlocity components, and Marketing Cloud settings. This comprehensive approach means you can restore records by first restoring the metadata if needed — nothing falls through the cracks during recovery.

With 91�Թ���, you can set up daily backups of your entire Salesforce org, as well as hourly high-frequency backups for your most critical objects. And if you need extra assurance before a risky change, you can back up on demand, providing flexibility to protect your data whenever necessary.

Off-platform storage

91�Թ��� stores your backups securely in AWS data centers in your chosen region, including the US, Canada, EU (Ireland), and Australia — the same highly trusted infrastructure that Salesforce relies on. This off-platform storage ensures that even if Salesforce experiences an outage, your backup data is safe and accessible, exactly when you need it most.

Point-in-time recovery

�ұ𲹰������’s backup solution offers point-in-time recovery, meaning you can browse historical snapshots of your org and restore it to any specific moment in time. For example, if you discover data corruption that occurred three weeks ago, you can restore your org to a clean state from before the corruption began — not just the most recent backup. This capability offers significant flexibility and ensures your data stays intact, even when issues arise weeks or months later.

Change visualization and alerts

With 91�Թ���, you can easily visualize how your org’s data has changed over the course of your backup history. This is especially helpful for tracking changes and spotting potential problems. 91�Թ��� also allows you to set up configurable smart alerts to notify you when unusual amounts of data have been changed or deleted. These alerts help you stay on top of any potential issues before they escalate, ensuring a proactive approach to data protection.

Security and compliance

Security is the top priority with �ұ𲹰������’s backup solution. All backups are encrypted both in transit and at rest, so your data is fully protected at every stage. 91�Թ��� also offers customizable data retention policies to match your specific compliance requirements. You can select your data residency and control team member permissions with fine-tuned settings. 91�Թ��� also maintains full audit trails of deletions, meaning your organization is compliant with data protection regulations.

Flexible restoration for every scenario

Data incidents can vary widely, so having flexible restoration options is crucial for addressing any level of data loss. 91�Թ��� offers a range of recovery methods to meet these diverse needs, ensuring you can restore your Salesforce data quickly and accurately, no matter the situation.

When an individual record is permanently deleted from the Recycle Bin, 91�Թ��� allows you to search across all historical backups to find that specific record. You can then choose to restore a version from any point in time when the data was correct. 91�Թ��� handles the re-insertion of the record into your org and ensures that relationships (like related Contacts, Opportunities, or Cases) are automatically preserved, so your data remains intact without manual intervention.

Protect your Salesforce data with 91�Թ���

Native Salesforce tools don’t provide comprehensive data protection, leaving gaps that could expose your organization to data loss.

�ұ𲹰������’s Salesforce backup solution transforms data recovery from a manual, error-prone nightmare into a streamlined, automated process. With automated backups for both data and metadata, off-platform storage ensuring availability even during Salesforce outages, and intelligent restoration that keeps relationships intact, 91�Թ��� offers the enterprise-grade protection your Salesforce org needs.

Don’t wait for a data disaster to realize the Recycle Bin ������’t enough. to see 91�Թ��� in action and understand how it can protect your Salesforce data.

The problem ������’t that this metadata exists — it’s that you can’t safely change anything until you know what depends on it. Salesforce gives you several ways to investigate, but none of them tell the whole story.

This guide covers how to search Salesforce metadata at scale. We’ll look at native tools and their limits, what the APIs can (and can’t) tell you, and how to get genuine dependency visibility across your Salesforce orgs using �ұ𲹰������’s Org Intelligence.

Why searching Salesforce metadata is important

Without proper metadata search, seemingly simple changes can break production. Here are the scenarios where searching metadata stops being optional — these are the moments when not knowing what’s connected to what costs you hours of troubleshooting, emergency fixes, or worse.

Retiring a custom field: Before you can delete a custom field, you need to remove every reference to it. Salesforce blocks deletion if anything still uses the field, but the real challenge is finding those references. A field might be buried in a Flow that calls another Flow, hidden in Apex logic written by someone who’s left the company, or referenced in a validation rule you forgot existed. Safe retirement means finding and removing every dependency first.

Searching Apex code: Setup doesn’t offer cross-codebase search — you’re expected to work locally in VS Code or Code Builder. Text search is essential for finding error messages, debug statements, hard-coded values, and dead code across classes that have accumulated over years.

Finding hard-coded IDs and URLs: Record IDs are environment-specific. An ID that works in a sandbox may not exist in production, or worse, point to something completely different. The same goes for instance URLs like . These need to be found and replaced before deployments or org migrations.

Cleaning up unused metadata: Every org accumulates clutter — fields no one uses, Flows that were replaced but never removed, Apex classes that haven’t run in years. Search helps find candidates, but safe cleanup requires checking dependencies too. A field with no data might still be referenced in a validation rule.

Uninstalling managed packages: Salesforce blocks uninstallation if anything references a packaged component — even an old email template. You need to find every SBQQ__ reference (or whatever the namespace is) before you can cleanly remove a package.

Security audits: Before release, scan for high-risk permissions like ModifyAllData that crept in during development, hard-coded API keys that should be in Named Credentials, and sharing rules that expose data to guest users.

Org splits and mergers: Hard-coded IDs, instance URLs, and email addresses will break when metadata moves between orgs. Search surfaces these so they can be replaced with dynamic alternatives like Custom Metadata or Custom Labels.

Does Salesforce have native metadata search tools?

Salesforce gives you several native ways to investigate metadata, but there’s no unified search feature. Instead, you get targeted tools — useful for quick checks, but with real limits on what they can surface.

For simple questions, they’re usually enough. But for anything involving scale, chained dependencies, or comprehensive metadata analysis, they’re a starting point at best.

The “Where is this used?” tool

is ����������ڴǰ�����’s most familiar dependency tool. You’ll find it on custom field detail pages in Setup — click it and you get a list of components that reference that field, with links where possible.

The tool covers layouts, validation rules, formula fields, Apex, Flows, Lightning components, and some reports. For quick, low-risk changes, it’s a reasonable first check.

The limits are worth knowing. It only works for custom fields and caps results at 2,000. It also won’t reliably show you managed package references in subscriber orgs, and it can’t follow the chain — so if a Flow calls another Flow that uses your field, you won’t see that connection. Some report relationships and complex Apex patterns slip through too.

It’s a reasonable starting point for quick checks, but if you’re planning anything more than a minor change, you’ll want a fuller picture of what’s connected.

The Metadata API

For comprehensive, repeatable metadata operations, ����������ڴǰ�����’s Metadata API is the foundational tool. It’s designed for bulk retrieval and deployment of configuration, and it underpins source control, CI/CD pipelines, and modern DevOps workflows.

Teams use it to retrieve metadata as structured XML files that can be versioned, compared across environments, and deployed in a controlled way.

That said, it’s worth setting the right expectations. The Metadata API ������’t optimized for interactive search or dependency analysis — it’s built for moving metadata around, not exploring it.

For more targeted inspection, Salesforce provides the Tooling API, which exposes metadata as queryable objects via SOQL. Dependency relationships are available through the MetadataComponentDependency object, but there are caveats. It’s been in Beta since Summer ’20 with no GA date in sight, ������’t covered under standard Salesforce support agreements, caps results at 2,000 records per query (100,000 total), and excludes reports entirely — those require Bulk API 2.0. Large orgs also need to keep an eye on API consumption.

In practice, teams layer these tools. The Metadata API handles bulk operations, the Tooling API supports interactive queries, and dependency data — used cautiously given its beta status and limits — informs impact analysis. ����������ڴǰ�����’s DevOps Center now abstracts much of this complexity for clicks-and-code teams, while platforms like 91�Թ��� add comparison, rollback, testing automation, and governance on top.

Salesforce DX

Salesforce DX is ����������ڴǰ�����’s modern development toolchain, designed to make metadata retrieval, search, and deployment repeatable and automation-friendly. At its core is the Salesforce CLI, which lets developers interact with an org by running commands instead of clicking through Setup.

For metadata search, the CLI is typically used to pull metadata locally so it can be inspected with standard development tools. Commands like sf project retrieve start download selected metadata as XML files (in source format), while sf project generate manifest --from-org <orgname/alias> creates a complete package.xml listing all the metadata types available in the source org. This makes it practical to retrieve large, complex configurations without manually enumerating components.

Once metadata is local, search becomes straightforward. Editors like Visual Studio Code allow global text search across all files, making it easy to find error messages, API names, or hard-coded IDs. Regex support enables pattern-based searches — useful for detecting 15- or 18-character record IDs or environment-specific URLs that would be difficult to locate through the UI.

The CLI also supports incremental workflows. Source tracking keeps tabs on what’s changed between environments, reducing the need to repeatedly retrieve entire orgs. For teams comfortable with Git and the command line, this approach offers transparency, repeatability, and speed.

The Tooling API for targeted searches

The Tooling API solves a specific problem: how to inspect and query metadata interactively, without downloading an entire org. It’s designed for fine-grained access to development artifacts and is especially useful when you know what you’re looking for and want fast answers.

Unlike the Metadata API, which works in bulk and file-based operations, the Tooling API exposes many metadata components — Apex classes, triggers, validation rules, Flows, custom fields — as queryable objects. This lets you ask focused questions like “Which Apex classes contain this text?” or “Which validation rules reference this field?” and get results directly from the org.

This makes the Tooling API ideal for interactive tooling, custom scripts, and IDE features. Many Salesforce developer tools, including VS Code extensions and browser-based IDEs, rely on it behind the scenes to power search, navigation, and real-time inspection.

It’s worth noting that the Tooling API is optimized for targeted queries, not full-org analysis, and it doesn’t expose every metadata type. For understanding relationships between components, it’s often paired with the Dependency API (also part of the Tooling API), which provides structured reference data — though with the same beta status and query limits mentioned earlier.

In modern workflows, the Tooling API complements the Metadata API: one enables fast, precise searches; the other supports bulk retrieval and deployment. Together, they form a practical foundation for exploring and managing Salesforce metadata without relying on manual Setup navigation.

The Dependency API: mapping metadata relationships

Understanding how Salesforce metadata is connected is often more important than finding where a string appears. That’s where the Dependency API comes in. Exposed through the Tooling API via the MetadataComponentDependency object, it provides structured relationship data showing which components reference other components.

This API answers questions like “What uses this field?” or “Which components will be impacted if I change this Apex class?” Instead of relying on text matching, it models dependencies explicitly — making it far more reliable for impact analysis than searching XML files or code alone.

But it’s important to understand what it can and can’t do. The Dependency API remains a Beta feature, has been in preview for several years, and ������’t covered under ����������ڴǰ�����’s standard support agreements. It only returns direct dependencies, so if you need to trace deeper chains — a field used in a Flow that’s called by another Flow — you’ll need to query recursively. It also enforces strict query limits and excludes reports and dashboards, which require separate Bulk API-based analysis.

Because of these constraints, the Dependency API is best used as one input, not a single source of truth. Teams typically combine it with bulk metadata retrieval, targeted Tooling API queries, sandbox testing, and higher-level tooling that automates dependency traversal.

When used appropriately, the Dependency API provides valuable structural insight. But in modern Salesforce environments, comprehensive dependency mapping requires layering multiple approaches.

�ұ𲹰������’s Org Intelligence: advanced metadata search

Org Intelligence gives you instant visibility into your Salesforce org’s metadata — components, dependencies, permissions, and change history — without repeatedly querying APIs, exporting files, or navigating Setup pages.

By eliminating the one to two weeks many teams spend exploring an unfamiliar org before real work begins, Org Intelligence turns metadata discovery into an instant, team-wide capability rather than a specialist task.

Dependency visualization and impact analysis

91�Թ��� builds and maintains its own dependency graph, going beyond ����������ڴǰ�����’s native dependency data to surface multi-level relationships. You can see chains like a field used in a Flow, triggered by another Flow, invoked by Apex — all in a single view.

This turns impact analysis into a repeatable process. Before making a change, you can see the full blast radius, reducing deployment failures and last-minute surprises.

Org Intelligence also includes an interactive Flow Navigator. Click through Flow logic step by step, with AI-generated explanations you can reuse for documentation and reviews.

Searching and filtering metadata

Org Intelligence makes it easy to locate and understand metadata without navigating dozens of Setup pages or writing API queries.

Search is component-focused, not text-based. Find a specific Email Template, Flow, custom field, or permission set, then immediately see how it’s used elsewhere in the org. Filter by metadata type, last modified date, or who made the change — useful when investigating recent issues or preparing a release.

Cross-checking automation takes seconds. See where a field is referenced across Flows, validation rules, Apex, and other logic without jumping between Setup sections or running multiple API calls. Permission visibility shows which profiles and permission sets grant access to a component, instantly answering “who will be affected by this change?”

Every component includes change history: when it was created, last changed, and by whom. This answers “what changed before this broke?” without digging through Setup or Git logs.

AI-powered assistance with 91�Թ��� Agent

91�Թ��� Agent adds a conversational layer on top of Org Intelligence. Ask natural-language questions like “Which Apex classes don’t have test coverage?” or “What does this Flow actually do?” and get answers grounded in your actual org metadata, not generic Salesforce guidance.

When the Agent references a component, it’s clickable — taking you directly to its dependencies, permissions, and change history. This makes exploration feel easy and interactive, not frustrating.

For developers, the Agent can generate starter artifacts like test class scaffolding or documentation summaries. Because it’s tightly integrated with Org Intelligence, responses stay accurate and current.

Identifying technical debt and unused metadata

Org Intelligence also helps teams systematically uncover unused metadata. By analyzing its dependency graph, 91�Թ��� highlights components with no incoming references — fields, Apex classes, or automation no longer used anywhere in the org.

This goes beyond simple inactivity checks. Combine dependency insights with change history and ownership to understand why a component exists and whether it’s safe to remove. Built-in problem analyzers surface risks early, reducing guesswork and over-reliance on the knowledge of one person — causing a single point of failure.

The result: a leaner org with faster tests, simpler deployments, and lower long-term maintenance costs — without requiring every decision to run through a single architect.

Streamline metadata search in your org with 91�Թ���

Salesforce gives you multiple ways to search metadata — from quick native checks, to APIs, to full local retrieval with Salesforce CLI. Each approach has its place. But as orgs grow, these methods become time-consuming, fragmented, and dependent on deep technical expertise.

91�Թ��� Org Intelligence changes that. Your entire team gets instant access to dependencies, permissions, change history, and technical debt indicators — all in one shared, continuously updated model of the org.

Faster decisions. Safer changes. Fewer surprises at release time.

Ready to move from manual metadata hunting to confident, organization-wide visibility? Book a demo or and see how 91�Թ��� brings clarity to your Salesforce orgs.

But as teams feeling the pain of unfulfilled AI promises know only too well, technology alone doesn’t guarantee value. It’s bringing technology to bear on the right problems, and in the right way, that creates progress.

There are a lot of companies shoehorning AI into their products for marketing’s sake. They’re using AI where a deterministic solution would be the better choice for consistency and predictability. They’re defaulting to AI, even though natural language doesn’t provide the most intuitive UX for every task. Ultimately, these products aren’t adding value to the customer, which damages trust in AI and reduces appetite for experimentation.

At 91�Թ���, LLMs have changed the problems we can solve, but they haven’t changed our philosophy for solving them. We start from the user’s Job To Be Done, search for the right solution unconstrained by what competitors do, and back it up with engineering that ships twice daily and iterates fast. This approach has helped us build products our customers love, and it’s how we’re creating genuine value with AI now.

Building AI products that actually add value

From our own experience and watching the market, we’ve noticed the pattern for companies making their customers successful with AI. There are three traits that are prerequisites for delivering real value with AI products.

1. Deep domain expertise translated into AI performance

The companies building AI products that customers actually adopt have mostly spent years understanding their market: the businesses they sell to, the personas within those organizations, the jobs those personas are trying to do, which problems are genuinely painful versus just plain annoying, and how value is created and captured.

These companies don’t just have expertise. They have valuable assets in an AI context: data models that encode domain-specific relationships, algorithms that solve specific sub-problems with precision, integrations that provide contextual information, and historical data that enables better prompting and evaluation. These assets can be exposed as tools to LLMs, providing capabilities and context that would take years to build from scratch.

2. Deliberate focus on well-defined problems

A deep understanding of the problem space goes hand in hand with a deliberate focus on that domain. Generic AI tools that can be applied broadly only offer shallow capabilities. Domain-tailored solutions built on deep expertise are designed to solve the problem in view.

Without domain tailoring, AI places heavy demands on users: vigilance, understanding the model’s limitations, knowing which problems it’s actually suited to, and which incantations are required to generate the outcome you’re after. Domain-tailored AI shifts that burden to the vendor, making value immediately accessible.

The difference shows up in time to value: generic AI initiatives have, for many companies, delivered no measurable ROI. Domain-tailored solutions create value almost immediately.

3. A product culture that obsesses over customer outcomes

AI creates an explosion of ideas. Every possible feature we could build is a solution to a problem, but not all problems are equal. Good products emerge from teams that think about opportunity cost — teams that identify which features actually create value and have the discipline to say no to everything else.

The possibilities of AI bring the product culture of companies into sharp focus. Companies that have historically shipped features because they could, or because competitors had them, will continue to struggle, regardless of the underlying technology. These teams will build AI features that may look good in demos, but fail to solve the problem in real-world scenarios.

The companies with strong product cultures — who always ask “What is the customer trying to achieve?”, “How might we best achieve that?”, and “How will we know if this works?” — will build the AI-powered solutions that customers actually use.

�ұ𲹰������’s AI trajectory: what we’ve built and what we’re delivering now

91�Թ��� has a decade’s experience working with thousands of Salesforce teams to build a product that solves their challenges. Over time, 91�Թ��� has evolved to support the complete DevOps lifecycle, helping teams deliver the right changes to production, more reliably and more frequently, so they can respond more quickly to changes in their business.

DevOps is ultimately in service of helping our customers be as agile as possible, and that larger goal remains our focus as we develop and release AI products.

We’re not rushing out shallow AI functionality across the whole platform in a uniform way. Instead, we’ve focused on specific, well-defined problem areas. The extent to which we lean on AI, and the way we use AI, depends on the job. Where problems are best solved using traditional, deterministic methods, that’s the approach we take. These solutions may then become tools consumed by an LLM, or provide constraints on an LLM’s output in another task.

In every case, we start by deeply understanding the Job To Be Done — the outcome our customers need and the obstacles that stand in their way. Then we build the solution that we believe most effectively solves the problem.

Observability

We launched Observability in Q2 2025 to help teams quickly identify issues in production — before they become full-blown production incidents — and get all the information they need to fix them quickly.

As we saw traction, the next high-leverage problem became clear: even with a wealth of information about what’s happening in your org, making sense of it is still hard. Going from a behavior in production to root cause analysis and solutions ������’t trivial.

LLMs are well-suited for this type of problem. We’re just about to release a change that brings Observability together with the 91�Թ��� Agent, helping you accelerate root cause analysis and generate recommended fixes with out-of-the-box queries.

Org Intelligence

Starting work on an org you didn’t build means understanding what’s in there, how it all fits together, and the potential impact of any changes you might make. That’s essential context, and getting it takes time.

We released Org Intelligence in Q3 2025, massively cutting the time it takes to understand an org’s structure and plan changes safely.

We had existing capabilities in 91�Թ��� that made this straightforward. Dependency tracking, which we’ve used in comparisons, commits and deployments, is an easily extensible, completely reliable way to quickly identify dependencies between different metadata types. Org Intelligence built on top of this foundation.

The next Job To Be Done then emerged: how can I safely change X to get result Y? What will be impacted if I delete Z? A conversational interface is a natural fit for this problem, and the deterministic solution underneath informs the context of the LLM, generating better results. So we exposed the 91�Թ��� Agent in Org Intelligence, armed with that data. The agent performs reliably because it’s grounded in context provided by a deterministic analysis of the org.

Automated Testing

UI testing is powerful, but getting value from it has historically been hard. Many teams struggle to get tests set up in the first place, and those that do often find the maintenance burden unsustainable. Tests break when Salesforce changes, failures pile up, and the suite gradually falls into disrepair until it’s easier to ignore than fix.

This is a whole problem that, in our view, wasn’t the right one to solve until LLMs gave us new capabilities. LLMs changed the equation: they made setup and adoption much easier, made it simpler to import tests from legacy platforms, and easier to self-heal in the presence of changes.

Automated Testing is now in pilot and will be GA in Q1 2026. You click through the expected user journey while 91�Թ��� records it and converts it into a test using AI, removing the setup friction that’s held teams back from getting their critical paths under test.

Autonomous Delivery

Looking ahead to Q2, the 91�Թ��� Agent will gain the ability to autonomously implement certain changes on your behalf — the small, well-defined tasks that never get prioritized because they’re not worth the context switch. It handles the toilsome work so your team can focus on complex projects without interruption.

From DevOps to delivering change

Our customers know us best for DevOps. But what you’re really looking for is more change per unit effort: greater organizational agility. DevOps is one part of that solution. To make change to production, you have to be able to repeatably and reliably deliver those changes — it’s non-negotiable. But it’s only one part.

When 91�Թ��� started, most teams building on Salesforce were losing time to manual comparisons and deployment processes. As teams adopted 91�Թ���, our solution gave them that time back for higher-leverage work. LLMs have created this scenario again. There’s a new class of tasks that consume a lot of energy, but suddenly no longer deserve the time you spend on them.

So we’re expanding. DevOps remains fundamental, but we’re building beyond it. LLMs excel at ambiguity and interpretation; deterministic systems excel at precision and predictability. Real workflows need both, so we’re combining them, using each where it’s genuinely stronger. And we’re moving fast — every quarter brings new capabilities.

You won’t find copycat AI features in 91�Թ���. You’ll find solutions to problems that actually hold back your agility, built with the same discipline and customer focus that’s defined 91�Թ��� from the beginning.

To see an example in action, explore Org Intelligence and discover how AI performs when it’s grounded in real expertise. And if you haven’t already, sign up to our newsletter to hear about new releases first.

Salesforce does have a few native tools that can help. Setup Audit Trail records changes made in Setup, giving you a timeline of administrative and configuration updates such as permission changes, validation rules, and sharing settings. Field History Tracking focuses on the data itself, showing when tracked fields on records change, who made the change, and what the old and new values were.

Together, these features form the starting point for auditing in Salesforce. In this guide, we’ll look at what each one captures, where their limits are, and how teams can build on them to support stronger compliance, security, and day-to-day governance.

Setup Audit Trail: Tracking configuration changes

is ����������ڴǰ�����’s built-in record of administrative changes in your orgs. It provides a read-only log of who did what, and when, at the configuration level, making it a useful starting point for security reviews, compliance audits, and troubleshooting unexpected behavior after a release. The feature is org-wide, enabled by default, and requires no setup.

Setup Audit Trail focuses on metadata and security changes, not record data. It answers questions like “Who modified this validation rule?”, “When were login policies updated?”, or “Who scheduled an org-wide data export through the Data Export Service?”

It doesn’t track individual report exports or detailed user activity. For this, you’ll need . Setup Audit Trail also doesn’t capture field-level before-and-after values, and Salesforce only retains entries for a rolling window of around 180 days unless you export them manually.

What Setup Audit Trail captures

Setup Audit Trail records many of the configuration and security changes that shape how your org behaves in production. This includes common setup updates such as record type changes, custom object and field creation or deletion, automation edits, and some page layout changes. Coverage is broad but not exhaustive — whether a change appears in the trail depends on the setup area and how the change is made.

Setup Audit Trail historically captured updates to Workflow Rules and Process Builder, but . Existing automations continue to function, but Salesforce no longer provides customer support, bug fixes, or enhancements for these tools. is now ����������ڴǰ�����’s primary and preferred declarative automation platform, and its configuration changes are tracked in the audit trail. Approval process changes continue to be logged as well.

The trail also captures a wide range of security and access-related updates. This includes changes to password policies, session settings, login IP relaxations, network access rules, and identity configuration such as Single Sign-On. You’ll also see certain high-risk administrative actions, like org-wide data export and backup requests made through the Data Export Service — entries that often come up during audits or security reviews.

How much detail you get depends on the action. Audit trail entries typically show the timestamp, the user who made the change (and any delegate user), the setup area involved, and a short description of what happened. Some updates, such as certain profile or permission changes, may show values changing from X to Y. Most complex metadata changes don’t. An entry like “Modified validation rule” tells you that something changed, but not what changed inside the rule.

Understanding the retention and display limits

Salesforce retains Setup Audit Trail data for 180 days (six months). After that, entries are permanently deleted and can’t be recovered or extended using native Salesforce functionality.

The retention period clock starts ticking as soon as the change is made, not when someone looks at the audit trail. A configuration change made on May 1, for example, is gone for good after October 28, whether or not anyone ever reviewed it.

It’s also important to distinguish retention from visibility. In the Salesforce UI, the Setup Audit Trail shows just the 20 most recent entries at any given time. Older changes can still exist in the 180-day window, but they’re hidden from view unless you export them. If you’re relying on the UI alone, you’re seeing a very narrow slice of what’s actually happening in your org.

How to access and export the audit trail

In Salesforce Lightning, navigate to Setup using the gear icon in the top-right corner. In the Quick Find box, type “View Setup Audit Trail” and select the result. You’ll see a table displaying the 20 most recent administrative changes in reverse chronological order, with columns for Date, User, Action, Section, and Delegate User.

Access is limited to users with the View Setup and Configuration permission. This is included by default in the System Administrator profile, but not in standard user profiles, so access tends to be tightly controlled.

When you export the audit trail, Salesforce generates a CSV and stores it temporarily in the , a separate Setup page. From there, you can download the file to your local machine for safekeeping or delete it if you no longer need it. If you do nothing, Salesforce automatically removes exported files after 72 hours.

The CSV mirrors what you see in the UI and doesn’t add much extra context. Timestamps are recorded in your org’s default timezone, and users are listed by display name rather than user ID. That’s often enough to answer basic “what changed and when” questions, but it can fall short when you’re trying to piece together a full audit trail or investigate changes over time.

Field History Tracking: Monitoring data changes

While the Setup Audit Trail focuses on how your org is configured, shows what’s happening to the data inside it. It works at the record level, logging changes whenever a tracked field’s value is updated on an individual record. This makes it a go-to tool for answering questions about real business activity, such as why an Opportunity Amount increased, when an Account Owner was reassigned, or who closed a Case prematurely.

The big difference between Setup Audit Trail and Field History Tracking is that Setup Audit Trail tells you who modified the validation rule and Field History Tracking tells you who changed the field value that triggered it. If users suddenly can’t save Opportunities, Setup Audit Trail helps identify recent configuration changes. If leadership asks why revenue forecasts shifted, Field History Tracking shows exactly which records changed and when.

Unlike Setup Audit Trail, Field History Tracking is not enabled by default. You have to switch it on for each object and field, and Salesforce enforces a 20-field limit per object. Deciding what to track — and what to leave out — is a trade-off every team has to make.

Retention and storage constraints

Salesforce retains Field History Tracking records for around 18 months in the UI and up to 24 months when accessed via the API. After that, the data is automatically removed and can’t be recovered using standard Salesforce features.

If Field Audit Trail is enabled, those limits no longer apply. Instead, retention is controlled through configurable policies, allowing you to keep field history for significantly longer periods to meet audit and compliance requirements.

Field History Tracking data also doesn’t count toward your org’s data storage limits, which makes it useful for auditing without adding pressure to your storage allocation.

Which objects and fields support Field History Tracking?

Most standard objects — including Account, Contact, Opportunity, Case, and Lead — as well as all custom objects, support Field History Tracking in Salesforce. Yet, certain field types can’t be tracked, including formula fields, roll-up summary fields, auto-number fields, and system fields like Created By or Last Modified By.

Step-by-step setup for Field History Tracking

Enabling Field History Tracking in Salesforce requires access to Setup and appropriate configuration permissions (typically Customize Application). Tracking must be configured separately for each object and applies only from the moment it’s enabled — Salesforce can’t retroactively capture historical changes.

Here’s how to enable Field History Tracking in Lightning Experience:

1. Go to Setup → Object Manager.

2. Choose the object you want to track (e.g., Account, Opportunity, Case, or a custom object).

3. In the Details tab of the object you selected, click Edit.

4. Scroll down to the Object Features section, then click on the Track Field History check box.

5. Open Fields & Relationships, then click Set History Tracking.

6. Choose the fields to track. For most standard field types, Salesforce records both old and new values. For multi-select picklists and text fields over 255 characters (including Long Text and Rich Text), Salesforce records that the field was edited, but does not store the actual values. You can track up to 20 fields per object (standard and custom combined).

7. Click Save.

After enabling tracking, add the [Object Name] History related list to page layouts via Setup → Object Manager → Page Layouts. Without this step, Salesforce continues capturing history in the background, but users won’t see tracked changes on record pages.

91�Թ��� Change Monitoring: Enhanced visibility for DevOps teams

����������ڴǰ�����’s native audit tools provide essential baseline coverage, but they weren’t designed to support modern DevOps workflows with multiple environments, frequent releases, and long-term compliance requirements. As orgs scale, teams need visibility that goes beyond short retention windows, limited detail, and manual exports — without replacing the native audit mechanisms already in place.

�ұ𲹰������’s Change Monitoring extends ����������ڴǰ�����’s native audit trail by continuously tracking metadata changes across environments and over time. Rather than focusing on individual events, it captures complete configuration snapshots, allowing teams to . That context is what makes the difference when you’re investigating incidents, governing releases, or preparing for audits.

Change Monitoring works alongside Setup Audit Trail and Field History Tracking, filling in the gaps around retention, detail, and accountability — and giving teams confidence that no configuration change slips through unnoticed.

How Change Monitoring strengthens your audit trail

Where ����������ڴǰ�����’s Setup Audit Trail is limited to a fixed 180-day window, 91�Թ��� stores metadata snapshots without a built-in expiry. That means you can investigate incidents or demonstrate long-term compliance patterns months or even years after a change was made, not just while it’s still visible in the UI.

Coverage goes well beyond core metadata. 91�Թ��� tracks complex configurations like Salesforce CPQ components, Industries (Vlocity) DataPacks, Lightning record and app pages, and Flows, with clear before-and-after diffs that show exactly what changed. For developers, each monitoring run also includes automated static code analysis, helping surface security, performance, and code quality risks early.

Just as importantly, Change Monitoring shows where changes came from. It distinguishes between updates deployed through 91�Թ��� Pipelines and changes made directly in Salesforce via the UI, APIs, or other tools. That makes it far easier to spot unauthorized production changes, enforce change control, and maintain clear DevOps accountability.

Org Intelligence turns change history into answers teams can act on

Change Monitoring gives teams a complete, long-term record of how their Salesforce orgs change over time. Org Intelligence builds on that foundation by helping teams actually use that information in their planning and development.

Org Intelligence helps your team explore your org’s metadata quickly, and understand the current state of play in order to plan new or improved features. A key part of Org Intelligence is the 91�Թ��� Agent, an AI agent built on �ұ𲹰������’s metadata analysis expertise. 91�Թ��� Agent lets teams ask questions about their org’s metadata and get clear answers, grounded in a deep understanding of your org.

Instead of manually combing through audit logs, diffs, and snapshots, teams can ask things like which Flows changed before an incident, whether a security setting was modified outside an approved deployment, or how a configuration evolved across environments over time.

It works across environments and time periods that ����������ڴǰ�����’s native audit tools don’t cover. It doesn’t replace data-level auditing or reporting. Its focus is metadata — how your org is built, how it’s changed, and how those changes relate to each other.

Where enhanced monitoring and insight really pays off

When something breaks in production — a validation rule starts firing unexpectedly or a Flow stops behaving — native tools can confirm that a change occurred. 91�Թ��� shows what changed.

Instead of assembling evidence manually for compliance and audit requirements, teams can lean on long-term configuration history, clear change attribution, and proof that quality gates were enforced as part of approved deployments. The result is less time spent preparing for audits and more confidence in the answers you give.

Maintain complete visibility across your org

Setup Audit Trail and Field History Tracking provide essential visibility into configuration and data changes. But, as orgs mature, their limitations become more obvious: fixed retention windows, inconsistent detail levels, and no native rollback or long-term comparison capabilities.

For teams scaling their DevOps processes, managing multiple environments, or operating under strict compliance frameworks, identifying changes ������’t enough. You need context, history, and control.

91�Թ��� Change Monitoring and Org Intelligence extend ����������ڴǰ�����’s native audit capabilities with long-term visibility, deeper metadata insight, and clear change attribution — giving teams the context they need to investigate issues, prevent drift, and release with confidence.

or book a demo to see how leading Salesforce teams maintain full visibility into how their orgs change.

This post walks through that journey, from the fundamentals of continuous integration and continuous delivery to global multi-org pipelines, and explores what it takes to scale without leaving anyone behind.

Why scaling CI/CD is challenging for Salesforce teams

Salesforce ������’t like other CRMs, and the challenges of scaling your CI/CD pipeline reflect that. Teams who try to apply generic DevOps tools and practices often hit friction that slows down their development process — instead of accelerating it.

The metadata model complicates everything

����������ڴǰ�����’s metadata model introduces complexity that most software development platforms don’t have. Org-level dependencies, the order of execution for triggers and automation, and the sheer variety of metadata types all create deployment risks that standard CI/CD tools aren’t built to handle.

A custom field might reference a record type that doesn’t exist in your target org. A Flow might depend on an Apex class that hasn’t been deployed yet. Profile permissions might reference objects from managed packages. These interrelated dependencies mean that a release failing ������’t a question of if — it’s a question of how often, and how quickly you can recover.

The declarative vs programmatic governance gap

As teams scale, the gap between declarative admins and programmatic developers widens. Admins may be building Flows and page layouts directly in a sandbox while developers are working in VS Code and committing Apex to version control. Both are creating valuable changes, but they’re often governed by different rules, tools, and workflows.

Without a shared deployment process, teams lose consistent review, traceability, and control over what moves between environments. This governance gap causes much more friction at scale. A small team can coordinate through conversation on Slack or Teams, but a team of 20 folks working across time zones will need access controls, approval gates, and pipeline configurations that enforce consistency without creating bottlenecks.

What good looks like: DORA benchmarks

Before diving into solutions, it’s worth understanding what high-performing Salesforce DevOps teams look like. The DORA (DevOps Research and Assessment) metrics provide a useful, industry-recognized benchmark by measuring deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time. These metrics aren’t just theoretical — they align with organizational performance. Teams that do well on DORA metrics ship features faster, experience fewer outages, and report higher job satisfaction. We’ll explore how to measure and use these metrics later in this post.

Build vs buy for scalable Salesforce CI/CD

When teams decide to scale their CI/CD capabilities, they face a fundamental question: should they build their own tooling or invest in a purpose-built DevOps platform? We’ve written extensively about this decision in our build vs buy guide.

DIY tooling: the hidden costs

Standard automation tools like GitHub Actions, Azure Pipelines, Jenkins, or Bitbucket Pipelines can orchestrate Salesforce deployments. They’re familiar to developers, often already in use for other platforms, and the basic setup is well-documented.

Beyond that starting point, teams taking the DIY approach can find themselves facing significant hidden costs:

• Maintenance burden: Salesforce releases three major updates per year, each potentially introducing new metadata types and API changes. Someone has to keep your deployment scripts current — and that someone is usually a developer who could be building features instead.
• Deployment reliability: 80% of Salesforce teams say their CI builds regularly fail. When deployments fail, developers must manually investigate and unblock automation — defeating the purpose of CI/CD in the first place.
• Operational overhead: What takes 90 hours to build with generic tools can take 30 minutes with a purpose-built solution — and that’s before accounting for ongoing maintenance, troubleshooting, and the knowledge debt when the engineer who built your pipeline moves on.
• Limited Salesforce awareness: Generic tools don’t understand Salesforce metadata. They won’t catch missing dependencies, suggest fixes for common deployment blockers, or handle the complexity of deploying Profiles and Permission Sets.

DevOps solutions: avoiding tool sprawl

The alternative is a unified platform built specifically for the nuances of Salesforce DevOps. Purpose-built solutions offer pre-built integrations with version control systems like GitHub, GitLab, Bitbucket, and Azure DevOps, along with intelligent dependency analysis that catches issues before deployment. Some will even offer support to both declarative admins and pro-code developers in the same workflow, with built-in static code analysis, automated tests, and compliance checks — plus complete visibility across your entire release pipeline.

The goal is to avoid the sprawl that comes from stitching together different tools for CI/CD, testing, backup, and monitoring. Each additional tool adds integration complexity, learning curves, and potential points of failure across the whole stack.

A proven setup that scales

Whether you’re just starting with DevOps or you’re ready to expand to multi-org deployments, the same core pipeline practices apply. Getting these right early — following Salesforce CI/CD best practices from the start — creates a foundation that grows with your team.

Source-driven development and repo structure

The first principle is source control as your single source of truth. Every change — whether it originates in a sandbox or in an IDE — should flow through version control before reaching production. For teams still working org-first, adopting a source-driven approach transforms how you collaborate and track changes.

Once source control becomes the system of record, how you organize your repository starts to matter. For larger teams, consider organizing metadata by feature or functional area rather than metadata type. This makes it easier to understand what a feature branch contains and reduces the risk of merge conflicts when multiple projects are in flight.

Multi-org and multi-team pipelines

Simple pipelines flow linearly: sandbox → staging → production. That works well for smaller teams, but as teams scale, adding in more people and environments, pipelines become tangled. You might have a UK team and a US team contributing to the same codebase, long-term projects running alongside business-as-usual development, external partners or consultants working in their own sandboxes, or multiple production orgs serving different regions or business units. Distributed Salesforce teams face particular challenges that require careful planning.

At this point, your pipeline needs flexibility. You need to handle multiple sources of change, keep environments in sync, and back-propagate hotfixes from production without chaos. 91�Թ��� Pipelines addresses this by visualizing your entire development process, automating complex deployment workflows, and enforcing review standards across environments. Each team can operate independently while the pipeline keeps orgs synchronized and prevents overwrites. For teams with multiple production orgs, this becomes essential infrastructure.

For major implementations that run alongside your main pipeline — Data Cloud rollouts, partner-led projects, or large customization efforts — you’ll need a strategy to keep them in sync without blocking everyday releases. The key is to keep these projects isolated but fed with regular updates from production, so they don’t drift out of sync and create painful merges at release time. Managing long-term projects within your Salesforce CI/CD pipeline requires deliberate planning but prevents significant pain later.

Environment strategy

Your sandbox strategy has cascading effects throughout your CI/CD pipeline. Most teams need:

• Developer sandboxes: Ideally one per developer, refreshed regularly. This is where individual work happens before it enters the shared pipeline.
• Integration environment: Where multiple features come together for initial testing. Conflicts surface here rather than in UAT.
• UAT/staging: Where stakeholders validate changes before production. Should mirror production as closely as possible.
• Production: Your live environment. Changes reach here only after passing all quality gates.

Scratch orgs offer an alternative for source-driven development, providing fresh environments that can be spun up on demand. The choice between scratch orgs and sandboxes depends on your team’s workflow and technical requirements.

For each environment, establish clear conventions: naming standards, refresh cadences, who has access, and what triggers a deployment. Consistency here prevents the drift that leads to failed deployments and manual intervention.

Environment variables and approvals

As pipelines mature, security becomes increasingly complicated. Credentials should never live in code or deployment scripts. Instead, use environment variables for org-specific configuration, secure credential storage for API keys and tokens, approval gates that require designated reviewers before production deployments, and audit trails that log who deployed what, when, and why. These access controls aren’t just good practice — they’re often required for compliance checks in regulated industries. Building them into your pipeline from the start is far easier than retrofitting later.

Branching strategies: which one is right for you?

It might not be obvious straight away, but your branching strategy also has to scale with your team. Choosing the right Git branching strategy depends on your team’s size, release cadence, and tolerance for complexity. Let’s unpack some of the most popular options.

Trunk-based development

Trunk-based development keeps things simple: all developers work from a single main branch, creating short-lived feature branches that merge back quickly — often multiple times per day.

Pros: Continuous integration happens naturally, merge conflicts stay small and manageable, and the main branch is always close to production-ready. This approach also works well with automated tests and quality gates.

Cons: It requires discipline and reliable CI/CD, unfinished features need feature flags, and you have less control over what ships when.

Release branches

Release branches decouple feature development from the release schedule. Teams merge completed features into a release branch, stabilize it, then ship to production.

Pros: You get clear control over what’s included in each release, time for dedicated QA and bug fixes, and easier coordination of releases across teams.

Cons: Longer-lived branches increase merge conflict risk, can slow down delivery of urgent fixes, and mean more branches to manage and track.

Gitflow

Gitflow adds structure with dedicated branches for features, releases, hotfixes, and development. It’s comprehensive but complex.

Pros: Clear separation of concerns, support for parallel development streams, and a well-documented approach that’s widely understood.

Cons: High process overhead, potential delays to integration and feedback, and often overkill for Salesforce projects.

How 91�Թ��� Pipelines supports your branching strategy

91�Թ��� Pipelines supports different branching strategies, so you can implement the approach that best fits how your team works.

By default, Pipelines uses an expanded branching model designed to balance DevOps best practice with the realities of Salesforce development. This means feature branches for individual work items, long-lived environment branches that represent each stage of your pipeline, and promotion branches that handle the transition between environments. Each environment has its own CI job monitoring for changes, and pull requests enforce review policies before changes can progress.

For enterprise teams managing large-scale releases, Pipelines also offers native Gitflow support as a first-class option. You can bundle multiple features into a single release branch, then move that release through environments — from dev to test to staging to production — as a single unit of change. This is particularly valuable for teams with a set release cadence who need to combine features, run comprehensive testing, and release in larger, fully validated chunks.

Whichever model you choose, your releases benefit from �ұ𲹰������’s usual seamless validations, automation, and governance.

PR policies and quality gates

Quality gates are how teams make sure those standards are applied consistently. This means requiring at least one approval before merging, validating that changes can deploy to the target org, running static code analysis to catch code quality and security issues before they enter the pipeline, enforcing minimum test coverage for Apex changes, and ensuring security scans pass before production. These gates shouldn’t slow things down — they should catch issues early when they’re cheapest to fix. Automated scanning and validation mean developers get feedback in minutes, not days.

Testing strategy for speed and safety

Automated tests are the foundation of reliable deployments, especially as Salesforce CI/CD pipelines scale. But testing in Salesforce presents unique challenges that require a layered approach — and understanding Salesforce testing best practices alongside effective test automation strategies will help you build a robust safety net as your team scales. Here are the non-negotiable tests you and your team should be carrying out:

Unit tests

Salesforce requires 75% code coverage for Apex, but coverage doesn’t necessarily equal quality. Well-written unit tests verify business logic rather than just lines of code, use meaningful assertions that catch actual bugs, run fast enough to execute on every deployment, and don’t depend on specific data in the org. �ұ𲹰������’s automated unit testing runs your Apex tests on a schedule, alerting you when tests start failing — before those failures block a deployment.

Static code analysis

Static code analysis catches issues that tests might miss: security vulnerabilities, code complexity, naming convention violations, and performance concerns. This is a crucial step for ensuring all your contributors are releasing changes that are consistent with your own standards and not building up technical debt.

91�Թ��� Code Reviews automatically scans every pull request, acting as built-in quality gates and blocking non-compliant code from entering your pipeline. It doesn’t just scan Apex, but also Flows, LWCs, Agentforce, Visualforce and metadata configurations. This deep understanding of Salesforce provides much more accurate results than Apex-only tools, and is particularly valuable when reviewing AI-generated code that often misunderstands the quirks of ����������ڴǰ�����’s architecture.

Integration and automated testing

Unit tests verify components in isolation. Integration tests verify that components work together in a real Salesforce environment — that data triggers correctly cascade through related objects, Flows and Apex work together as expected, and external integrations behave correctly. These tests typically run against a dedicated sandbox as part of CI jobs.

End-to-end UI tests validate complete business processes through the user interface. They’re slower and can be more brittle than unit tests, but they catch issues that other test levels miss. 91�Թ��� integrates with UI testing platforms like ACCELQ, Provar, and Eggplant, triggering test suites after successful deployments. Results flow back into 91�Թ��� for complete visibility across your testing strategy.

What to avoid when scaling your CI/CD pipeline

Scaling your CI/CD practices requires discipline. Some common antipatterns undermine even well-designed pipelines.

Long-lived feature branches that persist for weeks or months accumulate merge conflicts, drift from main, and become increasingly difficult to integrate. When they finally merge, they bring risk and disruption.

The fix: keep feature branches short-lived, break large features into smaller increments, and merge to main frequently using feature flags to hide incomplete work.

Skipping environments under pressure — deploying directly to production without going through staging or UAT — might save time in the moment, but it wastes far more time once a bug reaches production.

The fix: trust your pipeline. If environments are too slow, invest in making them faster rather than bypassing them.

Manual interventions accumulate technical debt. Every time someone manually fixes a deployment or edits metadata directly in an org, those changes don’t get tracked, can’t be rolled back, and create drift between environments.

The fix: if your pipeline can’t handle something, extend the pipeline. Don’t work around it.

Neglecting quality gates often starts as a shortcut — skipping tests or reviews to move faster under pressure. That speed disappears as soon as a bad deployment reaches production and teams are forced into firefighting.

The fix: implement automated tests, security scans, and static code analysis from the start. Make quality non-negotiable.

How 91�Թ��� helps teams scale their CI/CD pipelines

91�Թ��� is built specifically to handle the complexities of Salesforce deployments at scale. While generic DevOps tools require extensive customization and ongoing maintenance, 91�Թ��� provides reliable deployments out of the box — over 100 problem analyzers catch issues before they cause failures, and teams using 91�Թ��� achieve a 99% deployment success rate compared to roughly 50% with native tools.

Complete pipeline visibility

91�Թ��� Pipelines gives you complete visibility across your development process, tracking pull requests, automating promotions, and keeping environments synchronized. Everyone — from admins to developers to release managers — can see what’s in flight and what’s blocking progress. Whether developers are working in VS Code or admins are building in sandboxes, 91�Թ��� provides workflows that meet people where they are. No one gets left behind as your DevOps maturity grows.

Flexible branching that evolves with your team

Your branching strategy needs to scale with your team. 91�Թ��� Pipelines supports multiple approaches — from the expanded branching model, to native Gitflow support for enterprises managing large-scale, coordinated releases. You can start simple and evolve your approach over time without reworking your entire pipeline.

Long-term project support

Major implementations don’t fit neatly into your day-to-day release cycle. �ұ𲹰������’s long-term project functionality lets you run parallel workstreams — like a Data Cloud rollout or a partner-led implementation — without blocking your BAU pipeline. Projects stay isolated but receive regular updates from production, so they don’t drift out of sync and create painful merges at release time.

Continuous Delivery Rules

Once your pipeline is mature, you’ll want to automate even more. Continuous Delivery Rules let you define trusted conditions — such as “validations passed”, “tests succeeded”, or “code reviewed” — and 91�Թ��� automatically promotes changes once those conditions are met. This eliminates manual steps that slow down releases while still respecting your compliance and approval processes. No more waiting for someone to click “Promote” once all checks have passed.

Multi-org at scale

For teams managing multiple production environments, �ұ𲹰������’s layered modules separate shared metadata from org-specific customizations. Define a global core baseline, then grant flexibility to regional or departmental teams. When changes are approved in the core layer, they cascade automatically to dependent layers — maintaining consistency without sacrificing local autonomy.

Built-in quality and security

91�Թ��� Code Reviews shifts quality and security left — catching issues earlier before they escalate. Every deployment is automatically scanned for bugs or code quality issues, ensuring they meet the latest Salesforce guidance, OWASP standards, and Well-Architected principles. Combined with autofix functionality, which reduces review bottlenecks, teams can achieve consistency and governance, at scale.

DORA metrics and reporting

With DORA metrics built into the platform, you can track your DevOps performance over time, demonstrate ROI to stakeholders, and identify bottlenecks as they emerge. See deployment frequency, lead time for changes, and more — all without building custom dashboards.

To see how all of �ұ𲹰������’s platform works in practice, watch how Ergon scaled their Salesforce DevOps with 91�Թ���, or check out our webinar on succeeding at scale: how large teams can implement CI/CD and move faster.

Ready to scale? Start your journey today

The path from your first CI job to enterprise-grade release automation doesn’t mean a complete overhaul — it requires sustainable steps forward. By embedding good DevOps principles early, you create a foundation that grows with your team and adapts to whatever challenges come next.

91�Թ��� is built to meet you wherever you are on that journey. Whether you’re automating your first deployment, implementing Pipelines for your growing team, or orchestrating releases across global multi-org architectures, you’ll have the tooling, visibility, and support to succeed.

Ready to see what scalable Salesforce CI/CD looks like? of 91�Թ��� — no credit card required, nothing to install in your orgs. You’ll get full access to Pipelines, automated testing, code reviews, and everything else covered in this post.

Prefer a guided walkthrough? Book a tailored demo with our DevOps experts to discuss your specific requirements and see how 91�Թ��� can transform your release process.

Org intelligence solutions give Salesforce professionals a deeper understanding of existing org functionality, so they can plan confidently, reduce rework, and deliver higher-quality releases first time. This article explores what org intelligence means in practice, why it matters at every stage of the Salesforce DevOps lifecycle, and how you can introduce these solutions into your own workflow.

What is Salesforce org intelligence?

Salesforce environments grow organically over time, so org configurations, automation, metadata, and the relationships between them often become difficult to see without digging into multiple Salesforce DevOps tools or environments. This makes it hard for teams to understand the impact of a change or even what already exists.

In most orgs, the information you need is scattered. Some of it sits in Setup, some in Flows or Apex, some in old sandboxes, and some in the heads of people who were around when a feature was first built.

Org intelligence delivers that context together in a single, unified source of truth: a connected, continuously updated view of your Salesforce org that shows structure, dependencies, usage, and risk before and during change. Instead of piecing together orgs one component at a time, teams can see exactly what functionality is already in place and how parts of the org depend on each other. This helps users with any role — developers, admins, architects, technical leaders — build a reliable understanding of the org to make good decisions, and confident changes.

The Salesforce DevOps lifecycle

The Salesforce DevOps lifecycle describes how work moves through plan, build, validate, release, operate, and observe. Rather than a straight line, it’s a continuous loop, where decisions made early shape what happens later, and what teams learn in production feeds back into the next round of change.

Each stage has a different focus. Planning turns business needs into technical intent. Build and validate focus on implementing and checking those changes. Release is about safely moving them into production. Operate and observe are where teams run the org day to day, respond to issues, and understand how changes behave in the real world. Together, these stages are how Salesforce teams deliver value iteratively and safely.

The challenge is that gaps in understanding don’t stay contained to one stage. Limited visibility during planning shows up as rework during validation, blocked releases, or unexpected behaviour in production. Missed dependencies and legacy configuration become harder to untangle as work progresses through the lifecycle.

Org intelligence supports the lifecycle as a whole by providing a shared, accurate understanding of the org at every stage. Instead of compensating for missing information, teams work from the same view of org structure, dependencies, usage, and risk.

That shared context matters everywhere — but it has the greatest impact when teams are deciding what to change in the first place.

Common challenges in change planning

As orgs get more complex, even the most experienced technical users can find it difficult to predict how planned changes will behave. That complexity usually leads to three persistent problems that show up across the DevOps lifecycle:

• Long discovery. Teams often spend days digging through existing org metadata and automation just to understand an org’s structure and how a feature behaves today. This slows down early planning, especially in enterprise Salesforce development where teams are juggling global, complex orgs.
• Finding issues late-stage. Hidden dependencies are one of the most common sources of rework. A change looks safe until it reaches QA or deployment — and suddenly a test fails or a package doesn’t validate because something else relied on a field or a workflow.
• Accumulated tech debt. Unused fields, legacy Flows, old triggers, and duplicated automation accumulate over time. Without a way to see the scale of the problem, tech debt becomes harder to track and harder to address.

How org intelligence streamlines the plan stage

Salesforce teams often encourage a “shift left” approach because the earlier you can find a potential problem, the easier and cheaper it is to fix. But investing in the ‘plan’ stage of the DevOps lifecycle is how teams can avoid costly rework. This is the stage when teams translate business or user requirements into technical work.

Org intelligence solutions give teams the full context upfront. Instead of starting with a blank canvas, teams can see the functionality that’s already in place, rapidly understand bi-directional relationships and how different pieces of metadata depend on each other, and carry out thorough impact analysis. That means no more discovering a hidden automation during testing or learning about an unexpected dependency during deployment.

For teams working in the Salesforce platform across complex enterprise environments and business processes, this level of deep visibility becomes essential.

How org intelligence improves delivery across the DevOps lifecycle

The impact of org intelligence goes beyond quicker, easier planning — its benefits are felt across your entire release process:

• Quality improves even as teams move faster. The State of Salesforce DevOps 2025 report found that improving change quality is the area businesses value most about DevOps. By understanding the org upfront, teams avoid introducing errors and reduce the amount of rework they need to do later. That translates into higher-quality releases and more predictable delivery even when accelerating development.
• A better handle on technical debt. Technical debt can be largely invisible until it starts to cause performance issues or even failures in production. Org intelligence helps teams understand what’s unused, what’s risky, and what’s slowing down performance. That makes monthly cleanup cycles and permission reviews much more effective.
• Faster onboarding for new team members. New developers, admins, and architects can carry out org discovery rapidly, and easily see how components fit together rather than relying on siloed knowledge or reverse-engineering configuration manually.
• Quicker resolution of production errors. When something breaks unexpectedly, teams don’t have hours to trace back through automation or dependencies. Org intelligence gives support and engineering teams a direct view of how functionality is linked, making incident diagnosis and resolution faster and more reliable.

Bringing org intelligence into your workflow

Most Salesforce teams rely on a mix of tools and manual investigation to understand their orgs. Salesforce Optimizer, and ����������ڴǰ�����’s Tooling API dependency data, and built-in metadata and setup views (like Setup, Flow Builder, and the Schema Builder) all offer useful insights, but none provide the full context on their own.

AI-powered tools are also emerging, but reliability depends on having deep, structured Salesforce metadata awareness and org-specific context available. Without that, outputs can be incomplete or misleading.

What’s missing is a complete, contextual view of the org that plugs directly into the team’s existing DevOps workflow. That’s what true org intelligence aims to provide: a clear understanding of how the org is structured, how changes might behave, and where risks or opportunities sit across the environment.

Getting started with org intelligence tools

Introducing org intelligence into your process doesn’t require a major shift. It should enhance and improve your existing workflow. Here are some best practice approaches for layering org intelligence into your development processes:

• Establish a baseline view of your org. Start by enabling org intelligence on your production org and using the initial indexed view as a shared baseline. This creates a continuously updated reference for org structure, dependencies, permissions, and recent changes — giving teams a reliable starting point for planning and cleanup.
• Review metadata before planning a change. Before beginning work on a new feature or refactor, use org intelligence to check upstream and downstream dependencies, and recent change history. This helps avoid unexpected behaviour later in the release cycle.
• Use insights to inform code review, test planning, and deployment prep. Accurate dependency information, usage insights, and change context support more effective code reviews, guide targeted testing, and reduce deployment failures. This detail gives reviewers and release managers the information they need to make confident decisions.
• Track tech debt and permissions on a regular cadence. Understanding unused metadata, complex automation chains, and permission structures allows teams to take an iterative approach to clean-up. Monthly reviews prevent issues from accumulating and keep the org easier to maintain.
• Support incident response and root-cause analysis. When something breaks in production, org intelligence helps teams quickly identify which components are involved, what changed recently, and where to focus investigation. This shortens time to resolution and reduces reliance on siloed knowledge.
• Easily and regularly review permissions. Ensure least-privilege access by using org intelligence to understand how profiles and permission sets are used in practice, where excessive access has crept in, and which permissions are no longer needed. Regular reviews help teams stay aligned with security best practices, reduce unnecessary risk, and maintain a clear, auditable permission model.

Over time, this becomes part of how the team works — a natural step during planning, governance, and release management.

91�Թ��� Org Intelligence, built for confident planning

91�Թ��� Org Intelligence is designed to support the decisions Salesforce teams make before and during change. It gives teams a clear, shared understanding of what already exists in their org, so planning work starts from reality rather than assumptions.

Instead of jumping between Setup pages or relying on incomplete snapshots, teams can explore their metadata in one place and see how components relate to each other and how they’ve evolved over time. That context makes it easier to answer practical planning questions early: whether similar functionality already exists, what else a change might touch, and where risk is likely to sit.

Understanding dependencies is central to that planning work. For any given component, Org Intelligence shows both what it depends on and what depends on it. When a team is considering a change to a field, Flow, or Apex class, they can quickly see the potential downstream impact and factor that into scope, sequencing, and test strategy — before development begins.

Org Intelligence also helps teams plan with a clearer view of automation and access. By making relationships between metadata and permissions easier to follow, teams can anticipate knock-on effects, involve the right stakeholders earlier, and avoid last-minute surprises during validation or release.

The 91�Թ��� Agent supports this planning process by allowing teams to ask natural-language questions about their org and get answers grounded in real metadata and dependency context. That makes it easier to explore unfamiliar areas of the org, validate assumptions, and move from requirements to well-informed technical decisions.

Because Org Intelligence is built directly into �ұ𲹰������’s DevOps workflow, this context stays available as work progresses — carrying planning decisions forward into build, validate, release, and beyond.

Plan and deliver Salesforce changes with confidence

Before testing or deployment, the plan stage is where requirements are translated into concrete changes — and where teams have the biggest opportunity to improve release outcomes. If teams can’t see what already exists in production, planning becomes guesswork, and the surprises arrive later when they’re harder to fix.

91�Թ��� Org intelligence gives you the missing context up front: what’s in the org today, how it’s all connected, and what a change is likely to touch, so you can plan with confidence and deliver more predictable releases.

Book a demo to see how quickly you can have Org Intelligence making a difference in your development workflow, book a demo.

That’s the reality of working in a complex org. Changes are rarely isolated, and it’s easy to miss a dependency when you’re focused on delivering the next release. You test what you know about, deploy with confidence, and only find the issue when something breaks in production.

Metadata analysis removes that uncertainty. You need to see what exists in your org, how components are connected, where dependencies sit, and what the impact of a change will be before you deploy it. In this guide, we’ll look at how metadata analysis helps reduce deployment risk by exposing the relationships that are easy to overlook.

Three critical deployment risks without metadata analysis

Deployment failures disrupt your business. They waste time, lower stakeholder confidence, and delay project deadlines. Without thorough metadata analysis before a Salesforce deployment, you’re opening the door to three major risks:

Missing dependencies cause deployment failures

Salesforce deployment errors frequently happen when a component references another item that ������’t included in the deployment package. For example, attempting to deploy a Flow that references a custom field not present in the deployment will result in a deployment error.

Thankfully, �ұ𲹰������’s deployment solution has problem analyzers that will catch missing dependencies and prompt you to include them in your deployment package. But it’s even better to be aware of these dependencies long before deployment, and factor those implications into the plan and build stages of the DevOps lifecycle.

Unknown dependencies create production incidents

Failing to spot the implications of dependencies doesn’t just lead to deployment failure. Sometimes a “successful” deployment can cause even more problems, if the changes you deploy cause regressions in production.

In interconnected Salesforce orgs, seemingly simple changes can trigger a cascading impact across multiple systems. For example, modifying a “Customer Tier” picklist field on the Account object. This single field might be woven throughout your entire system:

• Reports filter or group accounts by tier — executive dashboards suddenly show incorrect data
• Dashboard components display those reports, resulting in weekly business reviews that present misleading metrics
• Flows check tier values for routing logic, so now high-value accounts get misrouted to the wrong teams
• Apex triggers reference tier for discount calculations — pricing logic fails silently
• Validation rules enforce tier-based data quality, so legitimate records can’t save
• Page layouts display tier differently by profile — UI becomes inconsistent across users
• Permission sets control field-level access, so users lose visibility to critical data
• External integrations read tier values via API, which means marketing campaigns target the wrong customer segments

Getting a full understanding of dependencies and impact ������’t easy within Salesforce. The button in Salesforce shows some references but only supports custom fields, omits managed-package components, caps results, and can’t trace deeper flow logic or integration pathways.

Without comprehensive dependency analysis, you operate on guesswork, testing what you remember instead of what actually exists. Manual investigation doesn’t scale — checking one field’s dependencies consumes a lot of time. A deployment package with dozens of components becomes impossible to verify thoroughly, increasing the risk that something unexpected breaks in production.

Hidden technical debt compounds over time

Technical debt in Salesforce accumulates quietly, component by component, until your org becomes difficult to maintain, risky to modify, and performs poorly for end users.

• Unused components accumulate: Custom objects built for cancelled projects or fields for pilot programs that never took off can remain in the system indefinitely. Each unused component adds cognitive overhead for every future developer and admin.
• Obsolete automation ������’t replaced by newer alternatives: Your org might have workflows built with and — automation tools Salesforce retired and are no longer supported as of December 31, 2025. Orgs often have dozens or hundreds of automations that should migrate to Flow. Without systematic analysis, you can’t identify which are actively used versus those that have been abandoned from previous implementations.
• Redundant applications multiply across teams: Different departments often install separate packages to solve similar problems, such as marketing, sales, and service teams all installing different email tools. While each may address an immediate need, together they introduce unnecessary complexity, inflate licensing costs, and increase the risk of conflicts across the system.
• Ghost code lingers in your system: Apex classes and triggers built by long-departed developers serve no current purpose yet often remain in production. Test classes for deleted functionality add execution time and complexity during deployments and utility classes for features deprecated years ago create false dependencies.

The business impact of unresolved technical debt scales over time:

• Org performance degrades as unnecessary components consume resources
• Development costs increase as teams navigate avoidable complexity
• New team members face steeper learning curves during onboarding
• Security vulnerabilities hide in unmaintained code

Metadata analysis enables prioritization by helping distinguish between what’s just untidy and what’s actually harmful. An unused field on a rarely-accessed object creates minimal harm, whereas an obsolete Process Builder automation executing on every Opportunity update creates ongoing performance degradation and maintenance risk. Knowing the difference lets you focus cleanup efforts where they matter most.

Accelerate metadata analysis with �ұ𲹰������’s Org Intelligence solution

Metadata analysis shouldn’t take weeks of manual investigation. �ұ𲹰������’s Org Intelligence solution provides comprehensive visibility into your Salesforce org’s architecture and dependencies, turning the complex task of understanding your metadata into a straightforward, automated process.

Org Intelligence quickly helps you:

• Find metadata in your org. Not sure what you’re looking for? Ask the 91�Թ��� agent how things work in your org, and it will surface the relevant metadata items for you.
• Understand what metadata does. Get AI-generated explanations of all your metadata in seconds, and save to your documentation library in 91�Թ���.
• Get the history of your org. See who created metadata items, who last edited them, and when.
• Identify all dependencies. Dig into all the relationships across your org so you can understand the implications of every change you make.
• Visualize metadata. 91�Թ��� renders your Flows the way they look in Flow Builder, helping you to explore and analyze in the way that makes most sense.

Many Salesforce teams dedicate a block of time entirely to org exploration and metadata analysis, understanding what exists, mapping component connections, and determining who built what. Org Intelligence massively accelerates this reconnaissance phase, supporting the plan and build stages of your DevOps lifecycle with proactive analysis before you make any changes.

Understand your org’s metadata in minutes

Metadata analysis has evolved from an advanced practice to a fundamental requirement. As orgs grow more complex, housing hundreds of integrations and thousands of metadata components, manual tracking becomes impossible. Invisible dependency webs lead to deployment failures that disrupt business operations, production incidents that damage credibility, and teams paralyzed by fear of breaking critical systems.

Full metadata analysis and insight gives teams the confidence they need to deliver the right changes, safely, and at pace. What may have typically required weeks of manual investigation can now happen in minutes. Complete architectural visibility transforms deployment planning from guesswork into confident, data-driven decisions.

Ready to eliminate reconnaissance sprints and deploy with confidence? Start your to see first hand how Org Intelligence helps you understand your org’s architecture. Or book a demo to chat with one of our DevOps experts about how teams use 91�Թ��� to master their metadata and achieve reliable Salesforce delivery.

AI should empower teams to move faster and focus on creating business value, not slow them down with new uncertainty. With strong DevOps foundations, teams are now confidently using AI where it makes sense, keeping humans in the loop, and measuring the real impact across their workflow.

Why artificial intelligence matters in DevOps

AI matters in DevOps because it’s already being applied across the software development lifecycle. The tools that support code generation, testing, and deployment increasingly have AI capabilities built in, shaping how development and operations teams work and make decisions. Ignoring that shift means missing opportunities to deliver faster and with more confidence, but adopting it blindly risks eroding the trust, security, and control that businesses depend on.

How AI is changing Salesforce development

Salesforce is regularly incorporating more AI into the software delivery on the platform. From the way users build apps and write code to how data is understood and decisions are made, AI now underpins more of the core functionality than ever before. That shift is showing up not only in new tools like Agentforce Vibes, bringing “vibe coding” to the platform, but also in the way Salesforce is now framing its products as Agentforce-led experiences rather than standalone clouds. AI in Salesforce ������’t a single feature or add-on anymore. It’s becoming part of the platform’s foundation, powering intelligent automation, contextual recommendations, and smarter tools for both developers and admins.

In our State of Salesforce DevOps Report 2025 we found that the vast majority of Salesforce teams are investing in AI in some way. 86% said they would be exploring new use cases for AI in 2025, and 37% said they would be optimizing existing AI-enabled processes.

The question ������’t whether to use it, but how to apply it safely, measure its impact, and keep the right guardrails in place so every change, human or agent-made, moves through a reliable DevOps process.

The benefits of using AI in DevOps

AI in DevOps won’t look the same for every team. The right balance depends on your team’s skills and how ready your company is to embrace AI. The important thing is to find the approach that genuinely improves your deployment process.

�ҴǴDz�����’s 2025 found that, of the 90% of survey respondents who reported using AI at work, more than 80% believe it has increased their productivity. Some of the main benefits of AI are making DevOps processes faster and unlocking new possibilities. By automating repetitive tasks, it can boost productivity by freeing teams to focus on creative problem-solving and architectural decisions.

Applied to the right problems, and paired with deterministic solutions, AI tools will:

• Accelerate non-deterministic tasks that couldn’t be automated before
• Democratize DevOps by lowering the barrier to entry through natural-language prompts
• Free up developer time for higher-impact work
• Reduce the time and cost of delivery

AI tools and use cases for DevOps

Not every part of the DevOps lifecycle benefits from AI in the same way. Some tasks are best handled by rule-based automation while others lend themselves to agentic automation. And there will always be moments that need human expertise and oversight. The key is knowing when to use which.

Org Intelligence

In Salesforce, one of the hardest challenges is understanding how metadata, automation, and dependencies interact. AI-driven analysis, in tools like �ұ𲹰������’s Org Intelligence, can now do much of that heavy lifting automatically. Instead of relying on human intuition to predict downstream effects, AI can model how one change will influence another and help teams understand and control the complexity of their environments. By mapping relationships, highlighting redundant automation, and revealing potential risks before deployment, Org Intelligence gives teams a level of visibility that used to take days of manual work to achieve.

Development

Salesforce developers are increasingly using tools like GitHub Copilot, Cursor, and to turn natural-language prompts into code suggestions. These tools can suggest code completions as you type and even generate documentation or unit tests. In the Salesforce ecosystem, that means Apex, Lightning components, and Flow logic can all be produced faster and with fewer repetitive steps.

AI technologies can also enhance collaboration. Features like �ұ𲹰������’s improve daily workflows by giving reviewers clear, concise summaries of what’s changed and why, so they can understand the intent of a release without combing through every line of code. By adding this layer of intelligence directly into the development process, 91�Թ��� makes review cycles faster, decisions clearer, and teamwork smoother.

Testing/QA

Generative AI can produce realistic test data, propose new test cases, and predict where regressions are most likely to occur. Agentforce for Developers (formerly ) provides an AI-assisted development environment that can automatically generate unit tests for Apex and Lightning Web Components based on your existing code. It understands the structure of your project and creates meaningful test coverage using natural-language prompts. Alongside test generation, tools like Salesforce use generative AI to analyze runtime behavior and flag performance anti-patterns early, helping teams catch scalability risks before they ship.

Beyond ����������ڴǰ�����’s native tools, AI-powered tools like GitHub Copilot help developers generate tests automatically as they code. The same prompt-first approach is starting to flow into UI testing too. Letting teams describe end-to-end behavior in plain English and have the test scripts take shape from there.

Deployment

As AI starts to show up in production features, teams need to deploy AI agents through the same reliable release path as everything else. 91�Թ��� makes deploying AI agents a smooth part of your existing DevOps process. You can deploy and manage agent configurations and tests just like any other metadata, with the same visibility, auditability, and control. This means teams can explore AI-driven functionality without needing new tools or risking the reliability of their delivery process.

Observability

Another important aspect of DevOps is visibility into system health. Salesforce (part of the Salesforce Shield suite) uses machine-learning models to compare user activity to historical baselines and flag what it regards as abnormal behavior. Third-party tools like and use machine learning models for incident management processes like anomaly detection and suggesting or even automating remediation steps.

What are the challenges and risks of using AI in Salesforce DevOps?

AI brings with it new challenges that DevOps teams have to manage carefully. As well as accelerating development, it can just as easily amplify existing risks around security, quality, and control. Like any DevOps automation, it won’t fix problems; it magnifies whatever you already have, good or bad.

Here are some challenges and risks to keep in mind:

• Security and compliance: AI increases the risk of exposing sensitive org metadata or customer data in prompts or model inputs, especially when using public AI tools. Agentforce is protected by the , which enforces encryption, data isolation, and compliance for AI interactions inside Salesforce.
• Trust, errors and hallucinations: Even within ����������ڴǰ�����’s ecosystem, AI tools can produce confident but incorrect outputs like misconfigured permissions, flawed automation logic, or references to non-existent metadata. These “hallucinations” can lead to deployment failures or hidden security flaws if not carefully validated.
• Team readiness and confidence: Salesforce teams are still learning where AI fits in their delivery process. Admins and developers may have very different levels of familiarity with generative tools, prompting strategies, or model limitations. Many worry about job displacement or loss of control. In GitLab’s 49% of respondents said they fear AI will replace their current role within the next five years.
• AI model fit and use cases: Not every AI model understands Salesforce context. General-purpose models, like , are trained on large volumes of public code, not specifically on ����������ڴǰ�����’s Apex language, Flow metadata, or platform constraints. As a result, they can generate logic that looks correct but violates governor limits, skips CRUD/FLS security checks, or misconfigures automation.
• Review gaps in AI-accelerated pipelines: Salesforce pipelines already include high levels of automation, and AI tends to increase that level further by speeding up the delivery of changes. The problem ������’t automation itself, but when teams automate ahead of maturity, or speed up one part of the lifecycle without strengthening the others, changes flow through with too little scrutiny. AI-generated code changes should be matched by a robust review and validation tool like Code Reviews as an approval gate to ensure AI augments decision-making rather than replacing it.
• Tool sprawl: Introducing separate AI assistants for each stage can fragment visibility and weaken oversight. If QA, security, and development teams all rely on different AI tools, critical issues in metadata or configuration can go unnoticed until they reach production environments. Good governance is what counters that. Fewer, well-chosen tools that integrate seamlessly into the pipeline make it easier to define consistent policies, apply them everywhere, and see what’s happening end to end. A consolidated platform gives teams one trusted view of change and clearer accountability.

Implementation roadmap

AI in Salesforce DevOps works best when it’s introduced deliberately, not as a wholesale change, but as a gradual enhancement to how teams already deliver. Implementing AI should remove friction and free people to focus on building business value.

Start small and iterate

Begin with narrow, well-understood use cases where AI can make clear improvements — such as generating pull-request notes, analyzing dependencies, or writing test cases. These early wins help teams build trust in the technology while keeping risk low. Once the value is proven, you can expand into more complex or agentic automation, guided by the same DevOps principles you already follow.

Keep a human in the loop

Even the best AI needs oversight. Deterministic code review should do routine tasks like validation at speed, while people stay accountable for the system — setting guardrails, watching outcomes, and stepping in when intent or risk needs judgement.

Governance guardrails

A clear governance framework defines how AI tools are used, how outputs are reviewed, and what standards every change must meet before deployment. These guardrails don’t slow teams down — they give them confidence to move faster, knowing every change is traceable, tested, and compliant.

Review and accountability

As AI becomes more involved in creating and modifying changes, deterministic code review becomes one of the most important safeguards. Code analysis tools like �ұ𲹰������’s Code Reviews are a vital quality and compliance check. Every change, whether human- or AI-created, is scanned, scored, and reviewed against your team’s own standards, giving you a clear view of security, maintainability, and technical debt.

Upskilling and culture change

Adopting AI successfully is as much about people as it is about tools. Teams need space to experiment and learn — to understand how to prompt effectively, interpret AI feedback, and recognize when manual control is still the right call. This shift is cultural: empowering developers to choose when to use rule-based automation, agentic automation, or hands-on work based on the complexity and risk of each task.

Consolidate your toolchain

As AI becomes part of every stage of the development cycle, you can end up with multiple tools. Bringing everything together on a single DevOps platform like 91�Թ��� embeds AI safely within the pipeline: Org Intelligence gives teams a clear view of dependencies and change risk before deployment, while 91�Թ��� Agent automates analysis and deployment checks without exposing sensitive metadata to external systems.

Measurement and ROI

Track baseline DevOps metrics like lead time, deployment frequency, and change failure rate, then compare them after introducing AI-assisted steps. Look for ways AI can improve efficiency in developer workflows — speeding up manual processes like dependency checks, PR reviews, and test creation — while also lifting release success rates and reducing rollbacks.

AI built in where it makes sense

AI in DevOps is most powerful when it’s built directly into the platform that teams already rely on. That’s why 91�Թ��� embeds AI in the DevOps lifecycle — not as separate add-on tools, but as part of the same pipeline you use to plan, build, and validate your deployments.

From Org Intelligence to Agentforce deployment support, every feature is designed to make delivery processes safer, smarter, and more predictable, without adding friction or risk.

See how 91�Թ��� can help your team deliver faster, safer releases with AI built in. Want to see it in action? Book a tailored demo to explore how teams are incorporating AI into their Salesforce DevOps workflows, or

At 91�Թ��� we’re committed to building powerful products designed to solve these challenges head-on. We’re introducing native Gitflow support directly into Pipelines, along with a suite of new automation and governance capabilities built specifically for the world’s largest and most complex Salesforce teams.

With this release, 91�Թ��� gives enterprises the control, flexibility and predictability they need to deliver Salesforce changes at scale — without sacrificing speed or global alignment.

Introducing native Gitflow support in Pipelines

For enterprise teams managing dozens or hundreds of developers, Gitflow ������’t just a branching strategy — it’s essential infrastructure. But until now, Salesforce DevOps tools have struggled to support Gitflow cleanly, forcing teams into rigid workflows or brittle processes they can’t truly scale.

�ұ𲹰������’s native Gitflow support in Pipelines gives teams a first-class branching and release management experience, purpose-built for large orgs. You can now:

• Bundle multiple features into a single release branch
• Move releases through environments seamlessly from dev → test → staging → production
• Maintain alignment across global teams using a consistent release model
• Adopt the branching strategy that best fit your team, evolving at your own pace

And because Gitflow is built on �ұ𲹰������’s already powerful Pipelines UI, your releases will still benefit from seamless validations, automation, governance and visibility.

PR Queuing: predictable and conflict-free delivery

Large teams often hit a bottleneck when multiple developers try to merge or deploy at once. Manual coordination creates a “race to click”, and even small timing differences cause conflicts and delays.

With PR Queuing, 91�Թ��� removes that friction entirely. Instead of piling into a release branch at the same time, changes enter a managed queue. 91�Թ��� will automatically:

• Sequence merges and promotions safely
• Validate each change in order
• Remove guesswork and contention

Your team can expect reliable, predictable delivery at scale — even when hundreds of changes are flowing through your pipeline each week.

Hyper-automation with Continuous Delivery Rules

Enterprise teams need speed, but they also need governance. Continuous Delivery Rules strike exactly that balance. They allow teams to define trusted conditions — such as “validations passed”, “tests succeeded”, or “code reviewed” — and 91�Թ��� automatically promotes changes once those conditions are met.

This eliminates manual steps that slow down releases while still respecting the organization’s compliance and approval processes. Key benefits include:

• Automatic movement of changes after approval
• Streamlined release cycles with no manual intervention
• Consistent enforcement of organizational governance

CD Rules automate the slow, manual steps that hold enterprise releases back — speeding up delivery while keeping governance front and center.

Empowering admins with the 91�Թ��� Chrome Extension

Admins play a crucial role in all Salesforce teams, but historically they’ve lacked the visibility and workflow alignment developers rely on. The new helps close that gap. Admins can now:

• Track changes directly from the Salesforce UI
• Minimize context-switching between Salesforce and Git
• Work in sync with established CI/CD workflows

This extension helps enterprise teams standardize practices across every function — finally bringing developers, admins and release managers into the same delivery rhythm.

Global consistency with Layered Modules

As enterprises scale, the challenge ������’t just speed — it’s alignment. Distributed teams often need freedom to customize their Salesforce environments, but a lack of control at the core can lead to drift, rework or compliance risks.

91�Թ��� allows you to define a shared global core baseline while granting flexibility to regional or departmental teams. When changes are approved in the core layer, they cascade automatically to dependent layers — preserving autonomy without sacrificing governance.

This architecture is purpose-built to help global enterprises:

• Maintain consistent standards to reduce duplication and drift
• Govern changes across regions
• Scale safely and efficiently

Layered Modules gives enterprises a clear way to maintain global alignment while still supporting the autonomy of individual teams.

Why do these updates matter for enterprise Salesforce teams?

With native Gitflow support, PR Queuing, Continuous Delivery Rules, the new Chrome Extension and support for Layered Modules, 91�Թ��� provides:

• Predictable and conflict-free delivery
• Flexible branching and release models
• Automation that respects compliance
• Standardized workflows across all roles
• Global alignment without slowing teams down

91�Թ��� is built for scale — and this release reinforces our mission to provide the world’s most capable and most flexible Salesforce DevOps platform.

Get started with 91�Թ���

The new features — including native Gitflow support, PR Queuing, Continuous Delivery Rules, the and Layered Modules — are available today for all 91�Թ��� customers.

To learn more about how these capabilities, and all the other areas of 91�Թ��� can transform your enterprise delivery strategy, start your , or book a tailored demo of 91�Թ��� today.

Unlike other Salesforce products with per-user pricing, Data 360 charges based on how much data you use. This can make budgeting for Data 360 unpredictable, especially if you’re used to fixed licensing models.

Timelines also vary. A simple setup might take a few weeks, but larger enterprise projects can stretch over several months. Your implementation timeline depends on how complex your setup is, how clean your data is, and what resources you have available.

In this article, we’ll break down the cost model and each stage of Data 360 implementation to help you plan realistically. You’ll see how consumption credits work, what factors push costs up, and what to expect across each phase — from setup and identity resolution through to activation. You’ll also learn which architecture choices have the biggest impact on how long the implementation process takes, so you can plan properly and avoid delays that disrupt your schedule or budget.

What is Salesforce Data 360?

Salesforce Data 360 (rebranded from Salesforce Data Cloud at Dreamforce 2025) is ����������ڴǰ�����’s platform for bringing all your customer data together in one place. It connects data from your CRM and external systems, unifies it into reliable profiles, and makes it easy to segment, analyze, and activate that data across the rest of your Salesforce stack. In practice, Data 360 gives teams a single, trusted view of every customer — and the tools to turn that data into real outcomes.

Understanding Data 360 costs

works differently to per-user pricing models. Instead of predictable per-user licenses, there are three factors: consumption credits that track every action, data storage fees based on how much you store, and optional add-ons for advanced features.

Understanding these three areas will help you plan accurate budgets, but because the model is consumption-based, you’ll need to monitor usage closely to avoid unexpected costs.

The three components of Data 360 pricing

Your bill combines three main charges, each calculated separately:

• Consumption credits are the foundation of your costs. They track every operation in Data 360, bringing in data from external sources, unifying customer profiles across systems, running queries and calculations, and publishing segments to other platforms. You purchase these credits in shared pools, which can be used across all features — there’s no separate pricing tied to individual actions.

• Data storage is charged at a each month. This covers everything stored in Data 360, from raw data to unified profiles. Storage costs are predictable — 10TB will cost $230 monthly.

• Premium add-ons unlock extra capabilities at fixed annual prices. ($60,000/year) lets you partition data by brand or region. ($60,000/year for one connection) supports cross-org connections. ($600 per connection) provides secure network links.

How consumption credits work

You buy in bundles of 100,000 for $500 (with discounts if you’re on an enterprise plan). Every action in Data 360 uses credits — but some tasks use barely any, while others are much more expensive. That’s why monitoring usage is so important.

At a high level, Salesforce groups credit usage into three main areas:

• Connect and Harmonize: covers bringing data into Data 360 and turning it into usable customer profiles.
• Analyze and Predict: is the credit spend for generating insights and running AI over your unified data.
• Act: is the cost of activating your data into downstream systems and real-time use cases.

Three buying models for consumption credits

Salesforce gives teams three commercial models for purchasing consumption credits, depending on how predictable your usage is.

• Pre-purchase. You commit to a set number of credits upfront for the full contract term, usually at the lowest price per credit. Your credit balance decreases as you consume services throughout the year. This model suits teams with consistent, high-volume workloads.

• Pay-as-you-go. There’s no upfront commitment — you simply pay monthly for what you use. The rate per credit is higher, but you get maximum flexibility. Teams exploring Data 360, running proofs of concept, or handling seasonal peaks often start here to benchmark their usage.

• Pre-commit. A hybrid option. You agree to a minimum annual spend (unlocking better pricing) while still having the freedom to scale beyond it. This is typically negotiated directly with your Salesforce account executive, and works well for teams that expect growth but don’t yet have fully stable workloads.

In practice, organisations with predictable, always-on data processing typically benefit most from pre-purchase, while teams still validating their Data 360 strategy often opt for pay-as-you-go before committing.

Self-serve calculations vs. Salesforce guidance

Your Data 360 costs will ultimately be set with your Salesforce account executive, but some elements are easy to estimate yourself. can also give you a ballpark figure for credit usage.

For anything beyond that, you’ll need to speak with your Salesforce account executive. They can advise on volume discounts, pre-commit pricing options, and architectural decisions that impact cost — such as whether slower batch ingestion is worth the lower credit consumption compared to streaming.

Monitoring consumption to avoid budget surprises

shows near real-time credit usage across all categories. Review it weekly to catch which operations are using the most credits, whilst keeping your monthly billing statement as your official source. You’ll often find things you didn’t expect — like a test segment refreshing every hour, or a calculated insight set to stream when it doesn’t need to be.

, Salesforce Data 360 now offers free ingestion of structured Salesforce data from supported internal clouds, including those used by Agentforce apps. With these common CRM sources no longer consuming credits, most of your spend now shifts to non-Salesforce feeds, data transformations, and any high-frequency processing you have running.

It can be tricky to keep track of where your Data 360 credits are being consumed. Some connectors are especially powerful — for example, the YouTube connector can quickly ingest entire playlists — but certain settings, like enabling captions, can burn through tokens much faster than expected. Teams may suddenly find a connector failing with no credits left, simply because a setting was left on.

To avoid budget surprises:

• Use ����������ڴǰ�����’s Digital Wallet to review near-real-time credit usage across all categories.
• Review your wallet weekly to spot highest-consuming operations (e.g., hourly test segments, streaming when batch would do).
• Always treat your monthly billing statement as the official record of what you’ll be charged.

Steps and general timeline for implementing Data 360

Rolling out Salesforce Data 360 follows a clear set of phases, but timelines can vary widely depending on your data quality, the number of systems you’re connecting, and how many people you have working on the project.

Three things shape your timeline more than anything else:

• How many data sources you have — and how clean they are
• The level of technical support available (admins, analysts, data engineers)
• The scope of what you want to achieve, from simple segmentation to full identity resolution across systems

Planning

Every successful implementation starts with discovery. This is where you define your use cases, map out the systems involved, and agree on your data governance policies.

Key decisions include:

• Whether to use an existing Salesforce org or provision a new one
• Which data sources to bring into Data 360 first
• Your identity resolution approach
• Governance, privacy, and security requirements

This phase brings multiple teams together. IT provides access and credentials, marketing outlines segmentation needs, sales identifies activation points, and compliance validates policies like GDPR or CCPA. Skipping this stage usually causes delays later — teams often end up reworking their data model or rewriting matching rules once they discover gaps.

Data connection and ingestion

Connecting data is usually the longest part of a Data 360 rollout. Even with ����������ڴǰ�����’s large library of pre-built connectors, each source still needs manual configuration. For Salesforce CRM, that means selecting objects and fields, mapping them to the Customer 360 Data Model, setting up permission sets, and choosing sync frequency.

For external systems like , , or , setup involves authentication, network access, IP allowlists, schema mapping, and planning the initial historical load.

Data quality is often the biggest blocker. Expect to hit issues like inconsistent formats, missing values, duplicate records with conflicting fields, or custom objects that don’t map neatly across systems. Most teams underestimate how much time they’ll spend on data cleanup.

Data modeling and harmonization

Before Data 360 can do anything useful, your raw data needs to be mapped into the . That means aligning your source fields to core objects such as:

• Individual (people)
• Account (companies)
• Engagement (interactions)
• Sales order (transactions)

You’ll also need to build calculated fields or transformations to standardize inconsistent values — things like phone number formatting, deriving lifetime value, handling nulls, or merging similar fields from different sources.

These choices have a direct impact on every downstream feature. If email fields aren’t mapped cleanly, identity resolution won’t work. If engagement data is incomplete, your segments won’t return the results you expect. Some teams build test segments early to confirm their model supports real use cases.

Identity resolution configuration

Identity resolution is where duplicate records are merged into unified profiles. You’ll define matching fields, configure exact or fuzzy matching, set source priorities, and decide how conflicting values should be handled.

This process is rarely perfect on the first try. Teams typically:

1. Build initial rules

2. Test them on a small dataset

3. Review the match rates and errors

4. Refine the rules

5. Test again at larger scale

What works in a small sample often behaves differently with millions of records. Over-aggressive matching can merge different people, while overly strict rules leave duplicates unresolved. Differences in data quality between systems also add complexity.

Testing and validation

Before go-live, you need to check everything works:

• Unified profiles should contain the correct fields
• Segments should return accurate counts
• Activation should send data correctly to target systems

Use test segments with known expected values. For example, if you know there are 10,000 customers who purchased last month, your segment should reflect that. If it doesn’t, you’ve found a data issue.

Run at least one full end-to-end activation workflow — check field mappings, freshness, and error handling. Performance testing is also important: segments that run instantly on small datasets may slow down or fail entirely when scaled to millions of profiles.

Deployment and enablement

This is the go-live stage. You’ll roll out Data 360 to users, assign permissions, create monitoring dashboards, set up alerts for data usage, and document definitions so everyone has a shared understanding of how data flows through the system.

Training should match the role, for instance:

• Marketers learn how to build and activate segments
• Analysts focus on exploring unified data
• Admins are responsible for maintenance and monitoring

Change management is critical. Users need to understand what data is available, how frequently it updates, and how to use it effectively. You’ll also need ongoing processes for monitoring data quality, reviewing usage, tracking segment performance, and resolving issues.

These phases often overlap — you might start modeling before ingestion is fully complete or configure identity resolution using partial datasets. But rushing usually backfires. Cutting corners creates technical debt that slows everything down.

Managing Data 360 configurations as your implementation matures

Data 360 ������’t a one-and-done setup. As your implementation grows, you’ll refine identity resolution rules, add new data sources, create new segments, and adjust activation flows. Unless you have a structured deployment process, these changes quickly pile up — and you’ll start to see configuration drift and unpredictable behavior.

Why Data 360 changes need version control

Data 360 introduces over 30 new metadata types into your Salesforce org, spanning everything from data streams and connectors to identity resolution rulesets, calculated insights, formulas, data model objects, activation targets, and segment definitions. And these aren’t static assets — they evolve constantly.

Small changes have wide impact:

• Updating a match rule can reshape every unified profile.
• A tweak to a calculated insight can change the results of downstream segments.
• Adjusting activation schedules alters how data flows into tools like Agentforce Marketing.

Without version control, it’s almost impossible to track what changed, who made the change, or why behavior suddenly shifted.

Spreadsheets and manual tracking simply don’t scale. They may work in the first few weeks, but once you’re managing dozens of data streams, hundreds of segments, and multiple team members contributing changes, you lose visibility fast.

Things get riskier when several people are working at once. One person updates identity rules while another edits a calculated insight — without a deployment process, those changes can collide or override one another.

Data 360 needs the same level of governance and version control as Apex, Flow, or any other critical Salesforce metadata. It’s the only way to keep configurations stable as you scale.

How 91�Թ��� simplifies Data 360 deployments

91�Թ��� handles Data 360 metadata through , which means you can deploy your Data 360 configuration alongside the rest of your Salesforce metadata. You can compare environments, push updates through a controlled release pipeline, and track every change in Git with full end-to-end visibility.

One of the biggest blockers for teams working with Data 360 is that many components — including Data Streams, Data Model Objects, Data Lake Objects, and Calculated Insights — can’t be deployed as standalone metadata. Salesforce requires them to be packaged inside a , which acts as a container for related Data 360 metadata.

91�Թ��� handles this for you, so you don’t need to manage the packaging rules yourself. Here’s what the workflow looks like in practice:

Easy discovery of Data Cloud components

In the comparison screen, you can use the dedicated Data Cloud tab to quickly filter and select all relevant Data Cloud metadata. Most Data Cloud components must be deployed inside a Data Kit.

Automatic handling of dependencies

When you retrieve a DataPackageKitDefinition, Salesforce doesn’t automatically include the components inside it. Using �ұ𲹰������’s pre-set Data Cloud filters helps ensure all the required dependent metadata types are selected. If anything is still missing, �ұ𲹰������’s problem analyzers flag the gaps so you can add the dependencies before validation.

Straightforward validation and deployment

Once your package looks good, 91�Թ��� walks you through validation, then deployment to the target environment — treating your Data Kit and Data Cloud components just like any other metadata bundle.

Optional automatic activation

Perhaps the biggest win: 91�Թ��� can activate your Data Kit automatically after deployment. On the final summary screen, just enable Activate Data Kits after deployment and 91�Թ��� will take care of the post-deployment activation step in the target org — removing yet another piece of manual effort that typically trips teams up.

Together, these capabilities let teams release Data 360 updates alongside Agentforce Sales changes, Agentforce Marketing configurations, and custom code — all through a single, end-to-end pipeline with complete visibility.

This matters because errors in Data 360 are costly. A broken identity rule can create duplicate profiles, and an incorrect activation can push bad data into marketing. With version control and automated deployments, you can avoid these pitfalls and keep delivering at speed — without sacrificing control.

Build confidence in your Data 360 implementation

Implementing Data 360 takes serious time and money. With usage-based pricing, it’s important to keep an eye on consumption to avoid unexpected bills at the end of the month.

The best way to stay on track is to understand what each stage involves. Your planning and architecture choices shape everything that follows. Connecting and cleaning data usually takes longer than expected. Identity resolution needs to be tested and refined multiple times. Testing and user enablement take time and can’t be rushed.

A Data 360 project doesn’t have a fixed endpoint. Business needs will shift, new data sources will be added, and matching rules will need regular updates. Long-term success depends on setting up a flexible foundation that can evolve with your org.

Want to see how 91�Թ��� helps manage Data 360 deployments? Book a demo to explore how teams handle Data 360 metadata alongside their wider Salesforce DevOps workflows, or .

In this post, we’ll explore the key challenges of UI testing in Salesforce and share practical solutions to help you build stable, maintainable test automation. We’ll also see why traditional automation frameworks often fail and how platforms designed specifically for Salesforce, like 91�Թ���, can turn testing from a bottleneck into a competitive advantage.

What is automated UI testing?

Automated UI testing involves creating scripts or tests that simulate how a real user interacts with an application’s user interface (UI). In the case of Salesforce, automated UI tests are not written inside the platform itself. They’re created and maintained outside of Salesforce using specialized testing frameworks or tools.

Here are a few examples of the types of tools you can use:

• �ұ𲹰������’s Automated Testing solution uses AI-powered screen recording and scriptless test creation to make stable UI testing accessible to any team member, without the maintenance overhead of traditional tools.

• Code-based frameworks like , , or allow you to write tests using programming languages such as Java, JavaScript, or TypeScript. These tests are usually stored in the same repositories as your Salesforce metadata or other project assets, versioned in systems like GitHub, Bitbucket, or Azure DevOps (ADO).

• is ����������ڴǰ�����’s open-source framework for UI test automation, built to handle the platform’s unique component structure. You define “page objects” in JSON files within your project repository and the UTAM compiler converts these into Java or JavaScript classes, which your tests call to interact with the UI.

• Third-party tools like Provar, ACCELQ, Testsigma, Tricentis, and Keysight Eggplant offer a more user-friendly approach to UI testing. These platforms let you create tests in their own UIs or simplified scripting environments. Many of these tools also support version control, so your test definitions can live alongside your Salesforce metadata or deployment scripts. Because the vendor platforms handle much of the underlying setup and execution, you write less custom Apex or automation code and can focus on validating how your Salesforce processes behave for users.

Once written, automated tests are typically executed against a Salesforce org, which could be a sandbox, scratch org, or another test environment. In �ұ𲹰������’s CI/CD pipelines, you can set these tests to automatically trigger after each deployment.

Common challenges when automating UI tests in Salesforce

Let’s unpack the most common obstacles teams face when automating UI tests in Salesforce and the impact they can have on the stability and reliability of your test suites.

Dynamic element IDs and locators

Salesforce doesn’t assign stable, predictable names to UI components like buttons or fields. Instead, it generates temporary identifiers that change. For example, an identifier like 60:220;a may become 90:220;a. If your automated test relies on finding a specific element by its ID, it will immediately fail because that identifier has changed. This can make it difficult to write reliable tests that consistently interact with the correct elements.

Salesforce doesn’t provide a built-in way to add stable test identifiers to its standard components, like the data-testid attributes commonly used in web development. Developers can include custom attributes in their own Lightning Web Components (LWCs), but not in ����������ڴǰ�����’s managed or out-of-the-box ones.

On top of that, is built on a deeply nested page structure, where UI components like buttons and fields are often contained within multiple layers of other elements. This can make it difficult to craft precise selectors that target a specific element. If you write a test to click a button, your selector might unintentionally match multiple buttons on the page due to the way the page is structured. This means your tests might fail, interact with the wrong elements, or cause other unexpected behavior. Tools like UTAM, Provar, and ACCELQ tackle this challenge with metadata or model-based locators instead of brittle, direct selectors.

Shadow DOM and Lightning Web Components

Modern Salesforce pages are built using , which rely on the web standard. The Shadow DOM encapsulates components so their internal HTML, CSS, and logic are hidden and don’t interfere with anything outside the component. That encapsulation exists to keep pages stable and predictable: a component’s styles and markup can’t be accidentally overridden by the rest of the page, and the component can change internally without breaking whatever uses it.

For testers, this creates problems. An automated test can see that a component exists, but it can’t directly access the buttons or fields inside it because they sit behind the Shadow DOM boundary. Some components only load after interaction, such as clicking a tab or scrolling a section into view, so tests need to wait for them to appear before they can interact. Salesforce also uses iframes to render pages and some third-party apps, which means tests have to switch into the correct frame before they can work with the content inside it.

Automation tools handle these challenges in different ways. Selenium usually needs custom JavaScript to reach elements inside the Shadow DOM, while Playwright supports Shadow DOM natively, reducing the maintenance burden and complexity of test scripts.

Frequent platform updates

Salesforce rolls out three major updates every year (Spring, Summer, and Winter) automatically to all orgs, along with periodic patches and critical updates. These updates can change how pages and components behave, which means even a stable test suite can start failing after a new release.

To help with this, Salesforce offers a , where teams can refresh or create sandboxes to get new features and updates before other environments. This early access gives teams a chance to test and validate their processes, including automated UI tests, before the changes go live. Unfortunately, these can contain early-stage bugs and temporary inconsistencies in metadata or Lightning components, which can cause false test failures or deployment issues between preview and non-preview environments. UI tests, in particular, can be fragile if the release introduces layout or DOM adjustments that Salesforce later patches during the preview phase.

Because of this release cadence and the challenges of sandbox preview, teams need to continuously monitor Salesforce updates and adjust their test automation to stay reliable. The rapid pace of change adds ongoing maintenance work and makes long-term test stability a constant challenge.

Complex page loading

Salesforce pages don’t load all at once. When a Lightning page opens, the browser first loads the layout, then initializes the Lightning components, and finally runs background calls to pull in data. Because of this, your automated tests can’t just assume the page is ready the moment it appears, they need to wait until everything has finished loading and is actually usable.

A common problem is that a test might find a button on the page that may not be fully interactive because their associated JavaScript code is still running in the background. The button exists in the DOM, but it ������’t ready to be clicked yet, so the test fails.

To deal with this, automated tests need to be able to wait for all related processes, like JavaScript execution or data loading, to be completed. Without that kind of synchronization, even well-written tests can break for no obvious reason.

Multi-org variations

Each org, from development to production, can have its own configuration, custom fields, page layouts, and permission sets, which makes it tough to build UI tests that run reliably across environments. Even small differences, like a hidden field or a stricter validation rule, can cause a test to fail.

Every custom object, field, workflow, or Lightning component adds more moving parts. A process like lead conversion might follow dozens of possible paths, depending on user roles or business rules, so a single test can’t easily cover every scenario.

Declarative tools like also add “hidden logic” behind the scenes. These automations can update records or call external systems without anything changing in the UI, meaning your tests may pass even while a background error goes unnoticed.

Test data management

Automated UI tests only work if they run against data that looks and behaves like the real thing. If your tests use records called “Test User” or “ABC Company,” you won’t trigger the same validation rules, Flows, or automation your users hit every day. That means your tests might pass, even though the real experience would break.

Privacy laws like GDPR and CCPA mean you often can’t just copy production data into a test environment. Instead, you need anonymized data that still acts like your live records and is realistic enough to trigger the same logic, without exposing sensitive details.

����������ڴǰ�����’s helps anonymize data in sandboxes, but it’s limited when you need more control over how records relate to each other.

�ұ𲹰������’s data masking, in-place masking, and sandbox seeding tools go further by preserving relationships between objects — like Accounts, Contacts, and Opportunities — so your tests can run against realistic, connected datasets. This lets you safely test real user flows and automation without risking sensitive information.

User profiles and permissions

����������ڴǰ�����’s UI changes depending on who’s logged in. Page layouts, buttons, and fields all vary by profile, record type, or permission set. A test that passes when run as a System Administrator might fail for a standard user, simply because the element it’s looking for ������’t visible or accessible.

Cross-browser consistency

Salesforce supports all major browsers, Chrome, Firefox, Safari, and Edge, but each one renders pages slightly differently. These small differences can affect automated interactions, especially in areas like modals, buttons, or responsive layouts.

Best practices to ensure stable UI testing automation

To reduce flakiness and keep your UI tests reliable across Salesforce updates, it helps to follow a few established best practices. Here are some practical ways to build a more stable and reliable UI test suite.

Use the page object model

The Page Object Model (POM) is a widely-used design pattern in software testing. Using this model for Salesforce UI testing, you create a corresponding class in your test code for each page or reusable component. This class acts as a centralized library, storing all the necessary information about how to find and interact with elements on that page.

The POM makes your test suite easier to maintain, read, and reuse. When Salesforce updates the DOM or changes a button label, you only need to update one Page Object instead of fixing every individual test. Well-written tests using this pattern are easier to follow, reading more like real user workflows than technical scripts. And because you can build Page Objects for standard Salesforce components, like record forms or related lists, you can reuse them across multiple tests, keeping your framework cleaner and more consistent.

The POM pattern works with frameworks like Selenium, Playwright, Provar, and ����������ڴǰ�����’s own UTAM framework is built around the same idea. If you’re managing multiple environments, make sure your Page Objects can handle org-specific variations like custom fields or layouts. That’ll help your tests stay stable wherever they run.

Use smart locator strategies

When writing automated UI tests for Salesforce, it’s crucial to locate elements the way a user would interact with them, rather than relying on the random identifiers Salesforce generates behind the scenes. For example, instead of targeting an internal identifier like j\_id0:j\_id1:j\_id2:saveBtn, write your tests to find the “Save“ button by its label, name, or accessibility attributes.

To further improve stability:

• Work with development teams: Add stable data-testid attributes to custom Lightning Web Components. You can’t do this for ����������ڴǰ�����’s built-in components, but it’s a simple, one-time step that makes your custom elements much easier to test.
• Consider metadata-aware tools: Tools like Provar or ACCELQ identify elements by their Salesforce API names (for example, Account.Primary\_Contact\_\_c) instead of the DOM structure. Those names stay stable even when Salesforce updates the interface.
• Build fallback strategies into your test framework: Have your tests try a primary locator first, then a backup if it’s not found. That way, your tests won’t fail over a minor UI change or label tweak.

Design for ����������ڴǰ�����’s architecture

Designing your testing framework with ����������ڴǰ�����’s unique architecture in mind involves considering how your tests handle timing. Rather than relying on fixed pauses, use intelligent wait strategies that monitor for specific conditions, such as checking whether the Save button is clickable. This approach keeps tests efficient and more reliable, reducing unnecessary delays and false negatives.

Build your tests in small, reusable pieces so failures are easy to trace — you’ll know which step broke, not just that something failed. And once you’ve built a stable suite, connect it to your CI/CD pipeline so tests run automatically after every deployment.

How 91�Թ��� helps you automate Salesforce UI testing

Built for Salesforce, 91�Թ��� simplifies the testing process by embedding UI testing in the full DevOps lifecycle.

�ұ𲹰������’s Automated Testing: built-in, AI-powered UI testing

91�Թ��� Automated Testing works as a standalone solution for UI test automation, making test creation easy for everyone. Better still, for customers using the full 91�Թ��� platform, Automated Testing is built into the DevOps process. Automated Testing empowers Salesforce teams to create their own tests:

• Scriptless/AI-powered screen recording — no coding required
• Understands Salesforce-specific complexity (Lightning, Shadow DOM, dynamic elements)
• More resilient to Salesforce releases than brittle locator-based tools
• Role-based testing that mirrors real user profiles and permission sets
• Native integration into 91�Թ��� Pipelines, working alongside 91�Թ��� Code Reviews

Seamless integration with third-party testing platforms

91�Թ��� also offers smooth integrations with leading testing platforms like Provar, ACCELQ, Testsigma, Keysight Eggplant, and Tricentis. Integrated tests are automatically executed after a successful deployment, making sure that every change is validated without the need for manual intervention or extra configuration.

Once tests are executed, results are displayed in �ұ𲹰������’s Pipelines and CI job dashboard. This provides full visibility across the testing pipeline without needing to switch between different tools or interfaces.

Unified testing across the DevOps lifecycle

91�Թ��� simplifies testing by bringing together automated unit and UI testing in one workflow, reducing the complexity of managing separate tools at different stages.

Unit tests run directly in 91�Թ���, with a full history of results and coverage reports to help you spot recurring failures and track quality over time. You can to run outside working hours and enforce coverage thresholds so only well-tested code moves forward.

UI tests fit right into the same release process. By combining scheduling, coverage gates, and integrated test orchestration, 91�Թ��� gives you a single, reliable testing workflow that keeps your DevOps lifecycle running smoothly.

Easily create UI tests and release with confidence

Explore �ұ𲹰������’s Automated Testing solution to see how easily your team can overcome their Salesforce UI testing challenges. and experience full testing capabilities with no commitment. Or book a demo to see how 91�Թ��� can address your specific testing needs with a personalized walkthrough.

In this guide, we’ll break down what Salesforce org intelligence platforms are, what makes them powerful, and how they go beyond the capabilities of native Salesforce tools. You’ll also learn how �ұ𲹰������’s Org Intelligence strengthens DevOps workflows, reduces deployment risks, and gives you the clear, actionable metadata insights needed to keep your org healthy and scalable.

What are Salesforce org intelligence platforms?

Salesforce org intelligence platforms, occasionally referred to as change intelligence platforms, are specialized third-party solutions that help teams understand the full scope of what’s in their orgs, how components are connected, and how changes will impact other parts of their system. This level of insight is critical for maintaining stability and speed in modern Salesforce DevOps practices.

Instead of teams spending days or weeks manually exploring the org before any development begins, org intelligence platforms remove this manual research that often slows down development and release planning. This faster understanding empowers teams to move from investigation to productive development quickly, anticipating the effects of change and deploying with greater confidence and safety.

Core capabilities of Salesforce org intelligence platforms

Org intelligence solutions give the insight necessary to move fast without losing control of your Salesforce environment — here’s how:

• Comprehensive metadata visibility: Org intelligence platforms make your Salesforce environment searchable and explorable, surfacing components — often spanning hundreds of distinct metadata types — in one unified view. This enables developers and admins to instantly locate existing functionality, understand how the org is structured, and identify what’s already been built before starting new work.
• Dependency analysis: These platforms provide bi-directional dependency mapping. Teams can see exactly what each component relies on and what relies on it. This holistic view helps teams assess risk accurately and prevent deployment failures before any code is written.
• Contextual documentation: Org intelligence platforms help you build a living knowledge layer around your configuration. Documentation, ownership, and analysis are stored in context, directly tied to org components. This eliminates fragmented information scattered across spreadsheets, wikis, or personal notes — ensuring institutional knowledge stays accessible even as teams evolve.

Combining these solutions empowers Salesforce teams to innovate confidently while maintaining stability, compliance, and trust.

How org intelligence addresses planning challenges in Salesforce DevOps

In the Salesforce DevOps lifecycle, the ‘plan’ stage is where initial discovery happens — defining what to change, why, and how those changes will affect the rest of the org. It’s also where high-value insights can prevent costly mistakes later in the pipeline.

Salesforce org intelligence platforms streamline this phase significantly by addressing the most common planning frustrations Salesforce teams face every day:

• Finding existing functionality: Without clear visibility, teams often rebuild features that already exist. Org intelligence platforms provide comprehensive metadata search that lets developers and admins quickly find similar components, reuse proven patterns, and avoid duplicate implementations.
• Understanding dependencies: Bi-directional dependency mapping reveals how components connect — what depends on them, and what they depend on. This visibility helps accurately estimate change scope, assess risk, and prevent unexpected breakages.
• Identifying technical debt: Over time, orgs accumulate unused, untested components. Org intelligence highlights issues such as Apex classes without coverage, orphaned metadata, or obsolete Flows, helping teams prioritize and remediate technical debt strategically.
• Change reliability and system stability: When dependencies, permissions, and existing configurations are opaque, a small change can cause cascading failures that compromise org integrity. By surfacing all relevant dependencies and relationships upfront, org intelligence tools enable architectural decisions to be made with full awareness of their downstream effects, avoiding downtime or unexpected failures.
• Permission analysis: Understanding who has access to what supports both change impact analysis and compliance. These platforms make it easy to see which users or profiles have access to specific metadata, ensuring permissions are properly configured and highlighting unnecessary or heightened access levels.
• Understanding inherited metadata: Legacy configurations built by former developers can take days to interpret manually. Org intelligence visualizers transform that effort into minutes, revealing logic flows and dependencies that native Salesforce tools obscure.
• Documentation gaps: Manual documentation rarely keeps up with rapid development cycles. Org intelligence tools automatically generate contextual documentation tied to the org’s structure, keeping knowledge current and accessible.
• Change history context: Knowing when components were created, modified, and by whom adds valuable context. This helps identify subject matter experts, trace the origins of issues, and understand recent changes that may have introduced risk.
• Onboarding acceleration: With full visibility into metadata, dependencies, and history, new hires can quickly grasp how the org operates. Structured and thorough exploration reduces ramp-up time from weeks to days.
• Architectural guidance: Teams can see how similar functionality was implemented in the past, promoting consistent design patterns and better alignment with existing architecture.

Org intelligence replaces manual, spreadsheet-driven tracking with live, automated insight. Fields, permissions, and dependencies are documented dynamically and kept up to date, giving teams immediate clarity on each component’s purpose, history, and relationships.

With that understanding, teams can design changes that minimize regressions, reduce duplicate configurations, and support compliance — using visibility to inform decisions rather than relying on trial and error.

Do native Salesforce org intelligence solutions exist?

Salesforce does offer some analytics and metadata visibility products, but they aren’t an equivalent to org intelligence solutions:

• is a user productivity feature designed to help sales teams manage Leads, Contacts, and Accounts more efficiently. It prioritizes records based on activity metrics such as recent interactions, engagement levels, and follow-up needs.
• gives single-direction insight into the dependency relationships between components in your org.
• (formerly Datorama) helps marketing teams analyze campaign and channel performance.
• delivers sales pipeline visibility for forecasting and deal insights.
• Tableau extends ����������ڴǰ�����’s capabilities with robust data analytics.
• helps service teams track contact center KPIs and agent efficiency.
• captures a chronological log of configuration updates for governance purposes.
• offers a visual map of data structures across objects and fields.

While these tools provide pieces of insight into the functioning of your org, they can’t give you the full picture of how all the metadata in your org ties together.

When it comes to complete org intelligence, the most powerful solutions today are third-party platforms built specifically for Salesforce. Tools like �ұ𲹰������’s Org Intelligence are purpose-built to provide the complete metadata insight Salesforce teams need. These solutions give organizations the ability to explore every component in their environment, understand dependencies, track changes, and make informed decisions long before deployment.

91�Թ��� Org Intelligence: instant org clarity for planning and building

�ұ𲹰������’s Org Intelligence delivers the deep visibility and analysis capabilities Salesforce teams need to plan and build changes with confidence. By bringing together comprehensive metadata search, dependency mapping, and intelligent visualization, it allows teams to fully understand their org’s architecture before making any modifications. �ұ𲹰������’s Org Intelligence eliminates the typical “reconnaissance” phase many teams spend simply trying to figure out how their org is structured — enabling you to move from exploration to execution far more quickly.

Org Intelligence by 91�Թ��� gives teams instant clarity, speeds up planning and development, and ensures every change is made with confidence in its impact.

Let’s look at the analysis and insight available to you with �ұ𲹰������’s Org Intelligence:

• Comprehensive metadata visibility: A unified interface displays all metadata types in one place. Teams can instantly search, filter, and explore components interactively, ensuring they’re always up-to-date with the current state of the org.
• Dependency analysis: Detailed dependency maps show both “referenced by” and “depends on” relationships. This bi-directional view helps teams understand exactly what components could be affected before any development begins.
• Permission and security visibility: Insight into which profiles and permission sets have access to any given metadata component. This helps teams identify relevant stakeholders, understand component importance, and maintain strong governance and compliance practices.
• Flow Navigator: A powerful visualization tool designed specifically for Salesforce Flows. Teams can explore automation logic interactively, clicking through each step to see how elements connect. 91�Թ��� Agent can describe what a Flow does and how it’s built, to quickly understand inherited Flows and support onboarding.
• Change history tracking: Maintain comprehensive audit trails for each component, showing who created it, when it was last modified, and what changed. This provides the contextual history and critical information needed for effective troubleshooting.
• 91�Թ��� Agent: Ask natural-language questions such as “Which Apex classes don’t have test classes?” or “Do we have a new Contact flow?” and receive context-aware answers drawn directly from the org’s metadata and dependencies. As well as intelligent suggestions of changes you could action e.g. technical debt that can be remediated.

Enable your team to plan in minutes, not weeks

Salesforce org intelligence is essential for teams managing complex environments filled with thousands of metadata components and countless integrations. With full visibility into dependencies, permissions, and change history, 91�Թ��� helps teams rapidly identify the right solutions faster and anticipate impacts before building.

Ready to transform your Salesforce planning and eliminate weeks of org discovery time? Start your today or book a demo with our experts to see how 91�Թ��� helps you understand your org’s architecture and deliver change safely.

This guide breaks down the main options for UI testing in Salesforce, including ����������ڴǰ�����’s own UTAM framework and several third-party tools that 91�Թ��� integrates into the DevOps process. These integrations let you turn UI testing into an automatic quality gate every time you deploy. By the end of the guide, you’ll know how to choose and implement a solution that gives you stable, automated testing that fits your team’s tools, skills, and budget.

Understanding Salesforce UTAM: the native solution

is ����������ڴǰ�����’s open-source solution for tackling the specific UI testing problems that come with the Lightning Experience. It’s built around the Page Object Model (POM), a common testing pattern that creates reusable representations of pages or components in the UI. In standard POM, you write code to define page elements and interactions. With UTAM, you describe page-object definitions in JavaScript Object Notation (JSON), and then compile them into Java or JavaScript classes your tests call. UTAM works alongside frameworks such as or , which handle running those tests in the browser.

This declarative method helps solve two major problems in Salesforce UI testing:

• Maintenance: When Salesforce updates the DOM during one of its three yearly releases, you only need to update the relevant JSON file. You’re not searching through dozens or hundreds of test scripts. This makes test maintenance faster and more efficient.
• Shadow DOM access: (LWCs) use the Shadow DOM, which hides their internal structure. Standard tools can’t access these parts of the UI. UTAM has built-in support to navigate through the Shadow DOM, removing the need for custom solutions.

UTAM helps avoid issues with unstable element IDs by allowing developers to define components using stable CSS selectors and attributes. This across Salesforce updates, while still targeting the specific elements needed for accurate automation.

A UTAM use case: writing effective tests for Lightning Experience

is ����������ڴǰ�����’s modern UI, powered by the Lightning Component Framework, which supports both Lightning Web Components and the older Aura Components. UTAM works across multiple Salesforce interfaces, but it’s especially effective here.

Best practices for testing in Lightning Experience with UTAM

• Keep a single source of truth: UTAM uses JSON page objects to define buttons, fields, and components. You define each item once. If Salesforce changes, you update the file — not every test. This keeps your tests consistent and cuts down on errors from repeating the same definitions in multiple places.
• Avoid fragile IDs: Lightning often creates new element IDs on every load. Instead, use labels, roles, or data-test attributes that you define. These stay the same across updates, while dynamic IDs break test stability.
• Handle hidden components: Many LWCs are placed inside Shadow DOMs. UTAM can access these directly, reducing the need for complex scripts or browser-specific workarounds.
• Wait for the page to be ready: Some tests use fixed pauses to give the page time to load, but these static waits are unreliable — pages don’t always take the same amount of time. UTAM enables test authors to actively design wait conditions into their page objects using so actions only happen when elements are ready. This makes your tests more reliable and avoids issues from slow network speeds or delayed page elements.
• Build reusable pieces: Lightning pages are made from nested components. UTAM mirrors this setup, letting you create small reusable definitions and combine them to build larger tests. It keeps your test logic clean and scalable.
• Test your custom components: For your custom LWCs you can author a UTAM JSON page-object definition alongside the component; the UTAM compiler turns it into testable classes, letting you treat the custom component similarly to built-in ones.

The open-source ecosystem: choosing your approach

UTAM doesn’t run tests on its own — it works alongside a test execution framework. You’ll need UTAM to handle page objects, and a separate framework like or to actually run the tests.

Working with UTAM and test frameworks

For JavaScript projects, a common setup is to use UTAM together with WebdriverIO. The wdio-utam-service package connects UTAM with WebdriverIO, letting your test scripts use UTAM methods while WebdriverIO handles all browser interactions. For Java projects, UTAM can be paired with Selenium WebDriver, which provides the same browser automation layer for Java-based environments while UTAM manages the page-object model.

Alternative open-source approaches

You can also build your own UI testing setup without UTAM, using general-purpose frameworks:

Selenium-based setups give you full control, but come with heavy maintenance. You’ll need to build your own page objects, manage wait conditions, and work around Shadow DOM limitations. Salesforce updates can also affect locators or page structure, requiring maintenance to keep tests stable.

is another option, especially for modern apps. Built by Microsoft, it offers:

• Built-in support for Shadow DOM, so it can access nested components without extra setup
• Automatic wait handling to reduce test flakiness
• Faster performance than traditional Selenium setups

Still, both Selenium and Playwright require strong technical skills, and neither includes the Salesforce-specific features UTAM provides. Without UTAM’s model-based structure, you’ll need to handle all the unique Salesforce behaviors on your own.

The commercial landscape: purpose-built solutions

Commercial Salesforce testing platforms solve key problems that open-source frameworks often can’t — especially around test maintenance and ease of use. Every tool listed here integrates with 91�Թ���, allowing teams to run automated UI tests as part of their deployment process.

91�Թ��� acts as the orchestrator for these tools. While the testing platforms handle test creation and execution, 91�Թ��� makes sure they’re properly connected to your release workflow. This means tests run automatically as part of each deployment, with clear logs of every run. You can track test history, spot trends in failures, and ensure tests are never left out of the process.

Provar

Provar connects tests to Salesforce metadata rather than relying solely on fragile DOM elements. This makes tests more stable when the UI changes, since they reference the underlying objects and fields rather than visual layout.

extends this stability to LWC by supporting locators that automatically detect and traverse Shadow DOM boundaries. Once configured in the , Provar automatically generates the necessary paths, reducing the need for manual scripts. Non-technical users can build tests through the Test Builder, while advanced users can extend them with SOQL or Apex.

ACCELQ

ACCELQ offers AI-driven no-code test automation that lets teams build and maintain complex tests without writing code. As an official Salesforce ISV partner, ACCELQ stays in sync with ����������ڴǰ�����’s release cycle. Shadow DOM handling is managed automatically in most cases, removing much of the manual setup required in open-source tools. ACCELQ supports UI, API, and backend testing in a single platform, allowing teams to manage all testing from one place with minimal complexity.

Testsigma

Testsigma provides a low-code approach to Salesforce UI testing, allowing teams to create automated tests in plain English without writing code. It supports dynamic element handling and integrates closely with Salesforce Lightning components to maintain test stability across updates. As one of �ұ𲹰������’s built-in integrations, Testsigma tests can be automatically triggered after each successful deployment, helping teams continuously validate their key user journeys as part of the CI/CD pipeline.

Keysight Eggplant

Keysight Eggplant uses a different method: AI-powered image recognition and computer vision instead of traditional code-based scripts. It builds a digital twin — a visual model of your application — and runs test flows that mimic real user journeys.

Because it tests what’s on screen rather than the underlying code, Eggplant bypasses Shadow DOM issues. It’s particularly suited for end-to-end journeys that cross Salesforce, desktop apps, mobile interfaces, or even PDFs. This is especially useful in regulated industries where testers can only validate systems through the user interface, not by accessing the source code.

Tricentis

Tricentis focuses on full-process testing, not just Salesforce in isolation. It’s built to validate entire workflows that stretch across systems like Salesforce, , , and others. Tricentis uses model-based and AI-assisted locators to make tests more resilient to UI changes, and it includes pre-built components for common Salesforce actions like record creation. Tests are codeless by default but can be extended with JavaScript for more advanced use cases. In 91�Թ���, you can execute tests in Tricentis Test Automation for Salesforce using an outgoing webhook that calls Tricentis’ public REST API at the end of a CI or deployment run.

Transform UI testing with integrated DevOps

Salesforce testing has moved well beyond basic record-and-playback tools. Modern tooling handles complex challenges like Shadow DOM, dynamic element IDs, and frequent platform updates. Choosing between UTAM’s developer-centric model and more user-friendly third-party platforms will influence how effectively your team keeps up with rapid releases.

Continuous delivery works best when testing, deployment, and monitoring are fully connected. Teams that integrate UI testing directly into their DevOps process can release faster, encounter fewer issues in production, and work more efficiently.

91�Թ��� integrates with popular UI testing frameworks and lets you trigger them automatically during deployments, ensuring quality checks are consistently built into your release pipeline. That means UI tests are built into your release workflow, with fewer tools to manage.

: Get 30 days of full access to the platform, with no credit card needed. That includes automated unit testing, UI testing integrations, and hands-on support to help you get results quickly.

Book a demo: See exactly how 91�Թ��� can streamline your Salesforce testing. Get a walkthrough based on your current challenges, how to connect your existing tools, and what steps reduce test maintenance over time.

Changes to your Salesforce org should be tested, because even small updates can have unexpected effects. Automated UI testing helps you catch any issues early, before users or revenue are impacted.

This guide shares practical strategies for building UI tests that flag issues caused by org customizations or new Salesforce releases. Whether you’re starting from scratch or dealing with a brittle test suite, you’ll find clear steps to create stable tests that protect your most important Salesforce processes and features.

What is Salesforce UI testing and why do you need it?

UI testing answers a critical question: when users interact with your Salesforce application, does it behave the way they expect?

Your Salesforce org is built around your business. The Flows, custom fields, page layouts, and validation rules you’ve set up all work together to create something tailored to you. No two orgs are the same. Every time you make a change, even a seemingly small one, there’s a risk of unintended consequences.

Most regression issues arise from changes in the UI. Salesforce evolves three times a year with major releases. These updates often introduce subtle changes in how components render, how elements are structured, or how new features interact with existing customizations. UI testing is the most reliable way to catch these regressions where they’re most likely to appear and confirm that your business-critical processes still work the way users expect.

Failures and regressions stall your entire business. Sales reps can’t quote. Agents can’t fix issues. Users can’t get work done. UI testing validates that your critical business processes — converting leads, creating cases, generating quotes — continue working correctly after you make changes.

How is UI testing different from static code analysis and unit tests?

Other testing methods focus on the internal workings of your org. Static analysis checks code quality, security, and performance. It tells you if an Apex class is inefficient, or if a Flow has poor error handling. Unit tests confirm that individual pieces of code or logic run correctly in isolation. They’re essential for developers, but don’t cover how those pieces work together in the UI.

UI testing, by contrast, works at the user level. It simulates someone logging in, clicking buttons, filling out forms, and running Flows to verify that the whole process functions in practice. That’s why UI testing is indispensable in Salesforce: it validates not just the technical health of your org, but the real-world workflows your business depends on.

Manual vs. automated UI testing

You can approach Salesforce UI testing in two ways: manually clicking through your org before each release, or automating tests that run on demand. Each has its place, but understanding the trade-offs helps you build a testing strategy that scales with your org.

Manual testing in Salesforce environments

Most Salesforce teams start with manual testing. Before releasing changes, someone (often an admin) clicks through the application, creating test records, filling out forms, checking that buttons work, and verifying that everything looks right.

This usually happens in sandboxes — development, partial, or full copy — where changes can be tested safely before they reach production. Larger teams often add a staging or UAT org, where business users confirm that end-to-end processes still work. And once changes are deployed, a limited smoke test in production is common: running through a few critical paths with test data to make sure nothing broke.

But this process can quickly become overwhelming. Testing one workflow across multiple profiles, browsers, and record types takes hours, with the same steps repeated again and again. The repetition makes mistakes inevitable: after the tenth run of a lead conversion, subtle changes like a new validation message or shifted field are easy to miss.

As your org grows, manual testing becomes impossible to scale. More objects mean more screens to check, automations create hidden dependencies, and integrations add failure points you may not even know exist. You’re left either spending days on exhaustive tests or releasing without full confidence.

This bottleneck slows delivery. Manual testing still has value for user-centric checks — like whether a layout feels intuitive or error messages make sense — but consistency and speed require automation.

Automated UI testing in Salesforce environments

Automated UI testing transforms your quality assurance from a bottleneck into an accelerator. Tests running automatically in your CI/CD pipeline are carried out on every commit, eliminating the human errors that creep in during repetitive manual testing. And it’s scalable — automated tests can run across multiple browsers simultaneously, validate multiple user profiles in parallel, and execute your entire test suite in minutes, not days.

What to test: core UI testing checkpoints

Your testing time is limited, so focus it where failures hurt most. These checkpoints cover the critical areas that protect your users and keep your business running smoothly after every change.

General UI and UX validation

Automated tests can confirm that pages load cleanly, fields render in the right place, labels stay legible, and core interactions (buttons, links, dropdowns, tabs) behave as expected. Include coverage across multiple browsers and devices so you don’t miss failures in the environments your users actually rely on. Reports and dashboards are especially critical — automation should verify that data and charts display accurately and that filters work properly.

Configuration and business logic

Salesforce runs on custom configurations. Automated tests should validate field behaviors (required fields, formulas, picklists, number formatting), plus the rules that control data entry. Validation rules need to both enforce quality and deliver helpful error messages. Don’t skip the edge cases — boundary values, unexpected formats, and rare combinations often reveal hidden issues. And if you’ve got multiple rules in play, check that they work together cleanly without clashing or blocking each other unexpectedly.

Page layouts need to flex based on who’s using them. Sales reps should see opportunity fields that service agents don’t. Record type layouts, related lists, and action buttons should also adapt to each profile.

For Lightning Web Components and Flows, automated checks should confirm that components render without errors, guide users through steps as designed, and fail gracefully when something goes wrong. As not all runtime errors surface in the UI, pairing automated checks with observability tools ensures you capture hidden Flow faults or JavaScript exceptions that don’t display on-screen. Together, this gives you both surface-level confidence and deeper assurance that your automations are resilient.

Security, accessibility, and performance

UI testing should also extend beyond functionality to cover the foundations of a trustworthy org: security, accessibility, and performance. On the security side, tests need to verify that sharing rules, field-level security, and permission sets work as intended so sensitive data stays tightly controlled. Accessibility checks confirm that the platform is usable for everyone — keyboard navigation should be reliable, screen readers must parse the interface correctly, and visual elements should meet for contrast and clarity. Performance testing ensures the experience remains fast and reliable: complex page layouts should load quickly, dashboards must refresh smoothly even with heavy datasets, searches should return accurate results without delay, and bulk actions need to complete without stalling or timing out.

Layers of UI testing in Salesforce

The strongest UI test suites layer different types of checks to cover both critical paths and broader scenarios:

• Smoke tests: Small, fast checks for essential workflows like lead conversion, case creation, or quote generation.
• Regression tests: Broader suites that confirm existing functionality still works after new changes or Salesforce releases.
• Cross-browser tests: Ensure layouts and interactions behave consistently across Chrome, Firefox, Edge, Safari, and mobile browsers.
• Cross-profile tests: Validate that different Salesforce profiles or permission sets see the right layouts, fields, and actions.

The role of UI testing in end-to-end (E2E) testing

As Salesforce is highly declarative, lots of the platform’s behavior ������’t written in Apex code you can unit test — it’s built with point-and-click configuration: Flows, validation rules, approval processes, page layouts, and permission models. These only fully come together in the user interface. A Flow might look correct in isolation, but its actual impact is only clear when a user triggers it by filling out a form or clicking a button. This means UI testing is key for end-to-end (E2E) testing in Salesforce.

An end-to-end test in Salesforce usually means simulating a real workflow, like “convert a lead, create an opportunity, generate a quote.” This runs through multiple parts of the platform: UI forms, record-triggered automations, integrations, and backend Apex. The only way to validate that all those layers work together is to follow the same path a user would — through the UI. Where unit tests validate a single Apex class in isolation, and integration tests check that components work together, E2E UI tests verify entire business processes from start to finish.

Easy implementation of UI testing with 91�Թ���

�ұ𲹰������’s AI-powered Automated Testing solution gives your Salesforce team an intuitive way to create their own automated UI tests. You just need to click through the test workflow, while 91�Թ��� records the journey and creates the test for you. You can also describe what’s needed to the 91�Թ��� Agent using natural language prompts. This removes the barrier to entry for UI testing — no scripting and automation expertise needed.

Build UI testing into your DevOps lifecycle with 91�Թ���

In a mature DevOps process, UI testing ������’t something added at the end — it’s built into the process. A complete DevOps solution embeds UI testing directly into your DevOps lifecycle so every deployment is automatically validated against the workflows users rely on most. With UI testing woven into the lifecycle, teams deliver faster and with less risk.

�ұ𲹰������’s CI/CD Pipelines transform testing from a manual checkpoint into an automated quality gate with embedded UI testing for every change deployed between environments. Testing becomes inseparable from deployment. You can’t accidentally push untested changes to production because the pipeline enforces quality gates automatically.

91�Թ��� also connects with other Salesforce testing platforms like ACCELQ, Keysight Eggplant, TestSigma, and Provar to trigger automated UI tests after a successful org deployment. Once configured, they’ll then run continuously, giving you confidence that every promotion has already met your quality standards. The pipeline visualization keeps everything crystal clear, showing which environments hold which versions, the test status at each stage, and exactly where issues are blocking.

Flexible webhooks

For teams using other tools, �ұ𲹰������’s webhook system will trigger automatically on deployment success or failure, so your pipeline can react in real time. 91�Թ��� integrates with Selenium via webhook or , triggering tests immediately after CI jobs complete. It also supports invoking Provar tests via a webhook that triggers a custom Jenkins job. And teams using Tricentis Testim can by configuring a webhook to their Testim REST API.

Your webhook payloads include all necessary context — which org, what changed, deployment status — allowing receiving systems to trigger appropriate test suites. Configure return webhooks to pull results back into 91�Թ���, creating unified visibility across your entire toolchain.

Cross-functional collaboration

91�Թ��� lets everyone see the same pipeline status, UI test results, and deployment progress. When tests fail, Slack alerts notify the team channel, Jira tickets update automatically, Microsoft Teams posts include failure details, and email notifications reach stakeholders. This immediate feedback allows devs to respond quickly. Admins understand exactly what’s being tested and why. Business users see quality gates protecting their critical processes.

Quality shifts from being QA’s responsibility alone to something the entire team owns. When testing is embedded in everyone’s daily workflow — not isolated in a separate phase — quality improves naturally. Your team catches issues early, fixes them quickly, and delivers confidently.

Ready to streamline your Salesforce UI testing?

Automated UI testing is essential if you want to ship Salesforce changes with speed and stability. Explore �ұ𲹰������’s Automated Testing solution today to see how easily your team could democratize test creation, cut testing times, and increase confidence in every release.

or book a personalized demo to discuss your team’s specific challenges. Our Salesforce DevOps experts will show you exactly how 91�Թ��� addresses your testing needs.

In this article, we’ll break down how Salesforce Data 360 works, what makes it powerful, and why it’s becoming the foundation for AI-driven customer engagement. You’ll see how it solves the problem of data silos and how it connects with tools like Agentforce to create more personalized, efficient agentic interactions.

We’ll also explain why Data 360 matters for modern businesses, and how 91�Թ��� helps teams deploy, manage, and version-control Data 360 configurations safely and easily. With the right setup, teams can innovate faster without sacrificing trust or stability.

What is Salesforce Data 360?

is a hybrid data lakehouse platform that unifies customer data from multiple sources and activates it directly within Salesforce in near real time. It combines the best of two worlds — the flexible, large-scale storage of a data lake and the structured, query-ready performance of a data warehouse.

Data 360 operates on two levels. First, it serves as the foundational infrastructure connecting and accelerating data movement across all Salesforce Clouds. Second, it functions as a standalone product that organizations can license to ingest, unify, and activate their data from external systems — CRM, ERP, marketing platforms, or external data lakes.

Unlike traditional databases that merely store information, Data 360 transforms business data into Salesforce metadata-driven objects, bringing it natively into the Salesforce metadata model. Teams can access, analyze, and act on unified data through familiar Salesforce interfaces — no complex data translations required.

Behind the scenes, Data 360’s open architecture uses technologies like and to store and organize data efficiently across cloud environments such as . This standards-based approach allows enterprises to scale to petabytes while maintaining flexibility and performance.

How Data 360 differs from data lakes and warehouses

A data lake and a data warehouse aren’t the same thing, even though the terms are often used interchangeably.

• A data lake stores massive amounts of raw data in its original form.
• A data warehouse organizes data into structured, queryable formats for reporting and analytics.
• Salesforce Data 360 unifies customer data from various environments to power near real-time engagement.

Traditional data warehouses are Online Analytical Processing (OLAP) systems designed for historical analysis, typically updating in scheduled batches. But, modern cloud data warehouses — like Snowflake and Databricks — have evolved to support near real-time data ingestion and processing, enabling more responsive analytics. Despite these advancements, they’re still primarily designed for analytical workloads rather than operational engagement.

While warehouses are built for analysis, Data 360 extends that by making unified data usable in day-to-day Salesforce operations. It doesn’t replace warehouses; instead, through zero-copy architecture, it integrates with them, making warehouse data actionable in Salesforce without duplicating or moving the data. This bridges analytical depth with operational speed — turning static data into dynamic customer intelligence.

The evolution from CDP to an enterprise platform

Salesforce Data 360 began as the Salesforce Customer Data 91�Թ��� (CDP) — a marketing-focused solution for unifying first-party customer data. Before that, it evolved from a Data Management 91�Թ��� (DMP) designed to manage third-party advertising data.

In 2022, Salesforce rebranded the technology as Genie, highlighting its new capability to process data in real time. As the platform matured, the transition to Data Cloud reflected its expanded mission: serving as the data backbone for the entire Salesforce ecosystem, not just marketing.

This evolution was driven by ����������ڴǰ�����’s own challenges — integrating data across acquisitions like , , and — and by the rise of generative AI.

Today, Salesforce Data Cloud has been rebranded yet again to Data 360 and stands as a complete enterprise solution that delivers a single, actionable view of every customer, connecting hundreds of systems to power consistent, intelligent experiences across all channels.

How Salesforce Data 360 works

Salesforce Data 360 connects customer data from CRMs, marketing platforms, websites, commerce engines, ERPs and more. It ingests data from these sources, transforms it into ����������ڴǰ�����’s Customer 360 data model, and keeps it current through powerful identity resolution logic.

The Customer 360 data model

At the heart of Salesforce Data 360 is the Customer 360 Data Model — a standardized framework that helps bring customer records, transactions, and interactions from diverse sources into a consistent structure. It acts as a shared language for your data, making it easier for systems across your organization to understand and work together.

Administrators can map incoming fields from any source directly to this shared model. That means less time spent cleaning and aligning data, and more time acting on it. The model supports both structured data — like records and tables — and unstructured data such as documents or emails, so nothing important gets left behind.

Because it’s fully extensible, teams can add custom objects and fields to match their unique business needs, while still benefiting from ����������ڴǰ�����’s built-in consistency and reporting standards. The result is a reliable data foundation that powers accurate analytics, meaningful automation, and trusted AI across every Salesforce Cloud.

How Salesforce Data 360 handles data processing

Data 360 organizes incoming data through a structured processing pipeline made up of several object types:

• Data Stream / Data Source Objects (DSOs): temporary ingestion points where data from connected systems, live streams or files enters Data Cloud.
• Data Lake Objects (DLOs): storage containers that preserve the data in its native schema, enabling traceability and further processing.
• Unstructured Data Lake Objects (UDLOs): can store non-tabular content such as documents or logs.
• Data Model Objects (DMOs): virtual views that align incoming data to ����������ڴǰ�����’s standardized Customer 360 Data Model for consistent access and reporting.
• External Data Lake Objects (EDLOs): metadata links that connect Data 360 to external data warehouses or lakes without duplicating data, enabling true zero-copy integration.

These layers allow Salesforce Data 360 to continuously ingest, unify, and activate data at massive scale, enabling near real-time engagement across the Salesforce ecosystem.

Identity resolution engine

The identity resolution engine in Salesforce Data 360 turns scattered data points into a single, reliable customer profile. Configurable match rules identify which records belong to the same person — using exact, fuzzy, normalized, or compound logic across connected systems.

When different sources hold conflicting information, reconciliation rules decide which value to trust, based on factors like source reliability, recency, or completeness. The result is a single, “golden record” that combines every known interaction and attribute for each customer.

This unified profile becomes the foundation for personalized engagement, analytics and AI-driven actions across the Salesforce ecosystem.

Key features of Salesforce Data 360

Here are some of the core features that make Salesforce Data 360 such a powerful platform for managing customer data:

Data connectivity and ingestion

Salesforce Data 360 gives teams flexibility in how they connect and ingest data. With more than 200 connectors, it links seamlessly to Salesforce Clouds, major databases, cloud storage platforms, and popular SaaS tools. Real-time streaming APIs capture customer interactions as they happen — from web and mobile apps — while batch processing efficiently handles large historical data sets from systems like Snowflake or BigQuery.

For complex enterprise architectures, MuleSoft supports enhanced integration patterns, moving data reliably between on-premise and cloud systems. Developers can also use the Ingestion API to design custom pipelines that connect proprietary or industry-specific sources. Whether you’re streaming live event data or syncing bulk records, Data 360 keeps every system aligned and every dataset up to date.

Data transformation and preparation

Once data is ingested, Salesforce Data 360 makes it easy to shape and prepare that data for analysis or activation. gives admins a no-code way to design transformations, merges, and filters without touching SQL. Formula fields handle inline calculations and conditional logic, enriching data in real time.

Built-in preparation tools standardize formats, normalize values, and run quality checks before data is unified — cutting down on manual cleanup. For streaming data, transformations apply instantly as events flow through the system, keeping insights current and consistent across every channel. Complex data engineering becomes a clear, visual process that both technical and business teams can manage confidently.

Segmentation and audience building

Salesforce Data 360 includes an intuitive segment builder that lets marketers and analysts define audiences without writing code. With drag-and-drop controls, teams can build and layer segments for precise targeting across campaigns.

Waterfall segmentation determines which audience a customer belongs to when overlaps occur, ensuring each profile appears in the most relevant group. And with , teams can describe the audience they want in plain language — and let the platform build it automatically. The result is faster, smarter targeting and fewer manual hand-offs between data and marketing teams.

Insights and intelligence

Data 360 turns unified data into near real-time intelligence. Teams can define calculated insights — metrics like customer lifetime value, purchase frequency, or engagement scores — directly within the platform. Streaming insights refresh these metrics continuously, using rolling time windows to reflect what’s happening right now.

For deeper analysis, Data 360 connects to predictive models through Einstein Studio or external Machine Learning services, and enables fast retrieval of insights for operational use. These capabilities power instant recommendations, personalization, and reporting across Salesforce.

Zero copy

One of Data 360’s most forward-thinking features is its zero-copy architecture, which changes how data is shared across systems. Rather than duplicating or migrating data, Data 360 enables direct access and querying of external data platforms so you can activate insights without moving every dataset.

This bidirectional integration means you can use your existing data investments without building redundant Extract, Transform, Load (ETL) pipelines. Minimizing duplication and keeping data current, governed, and cost-efficient.

Data governance tools built into Salesforce Data 360

Salesforce Data 360 includes a rich suite of built-in governance, privacy, and security tools — let’s unpack them.

Data protection capabilities

let organizations with multiple brands, regions, or business units manage everything in one place — without losing control. Teams can work independently while sharing the same underlying data architecture. Access is managed through a layered security model across objects, fields, and records, giving admins fine-grained control over who can see or edit specific data.

Data 360’s AI-powered data classification automatically identifies and tags sensitive fields, helping teams stay on top of compliance and keep regulated information in check.

Dynamic data masking can hide or obfuscate sensitive values based on user roles and policies. For data at rest, Shield 91�Թ��� Encryption uses tenant-specific root keys, while Data 360’s Bring Your Own Key (BYOK) and External Key Management (EKM) options — including AWS KMS — give enterprises even greater control over encryption keys without having to maintain them in Salesforce.

Compliance and privacy

Salesforce Data 360 includes built-in tools to help organizations stay compliant with global privacy standards like GDPR and CCPA. Its consent management framework captures and enforces customer preferences around communication and data sharing across all of your connected systems.

To make meeting regulatory requirements easier, Data 360 automates key data-subject-rights workflows — including requests for access, deletion, export, and processing restrictions — all handled through the Salesforce Consent API.

Security and compliance teams can gain deeper visibility with and related add-ons, which track user activity, flag anomalies, and generate audit reports.

For secure data exchange, enables encrypted, point-to-point communication between Salesforce Data 360 and external data platforms without crossing the public internet. And with policy-based governance automation — generally available from September 2025 — admins can define and enforce consistent data-handling rules across all connected sources. Together, these features create a flexible governance framework built to scale securely and stay ahead of evolving compliance needs.

Real-world use cases of Salesforce Data 360

Salesforce Data 360 helps organizations turn disconnected systems into customer-ready insight. By bringing all data together, teams can act on information instantly — improving efficiency, personalization, and the customer experience, regardless of the industry they’re in.

• Retail: Brands combine online browsing, in-store transactions, loyalty activity, and social engagement into one profile. When a shopper abandons a cart or posts feedback, automated Flows trigger timely responses — from personalized offers to VIP outreach — driving conversion and long-term loyalty.

• Financial services: Banks and insurers unify data from accounts, investments, mortgages, and digital channels to identify buying signals. Insights trigger actions such as automated loan pre-approvals or proactive financial recommendations, improving satisfaction and cross-sell performance.

• Healthcare: Providers connect Electronic Health Records (EHRs), patient portals, wearable data, and social insights in Salesforce Data 360 to build a single, trusted patient view. Near real-time updates power automated reminders and personalized care journeys — helping teams deliver better outcomes, reduce missed appointments, and strengthen patient engagement.

• Manufacturing: Data 360 unifies IoT sensor readings, service contracts, and inventory systems to predict equipment issues before they happen. These predictive insights minimize downtime, shorten delivery cycles, and strengthen customer trust — all powered by data intelligence.

Powering Agentforce with Data 360

Data 360 provides the unified data foundation that helps Agentforce agents generate accurate, context-aware responses — turning AI from a generic assistant into an intelligent, trustworthy business partner.

Agentforce uses Salesforce Data 360 to access a unified customer context that spans sales, service, marketing, commerce, and even external data platforms through zero-copy federation. This feature allows near real-time queries across , , , and using advanced query pushdown techniques, so data can be accessed live without duplication or latency.

The foundation for intelligent AI

Salesforce Data 360 serves as the grounding layer that gives Agentforce factual, contextually accurate information. By providing a unified, customer view, Data 360 helps Agentforce reduce AI hallucinations and generate responses that align with actual customer history and business data. Without Data 360, Agentforce still functions using existing Salesforce CRM data and connected sources, but its ability to leverage a complete, multi-source context is limited.

Trust and security for AI

Trust and security remain central to ����������ڴǰ�����’s AI design. As of October 2025, zero data retention policies ensure that customer data used by Agentforce’s large language models is never stored or reused for model training. Permission enforcement ensures that Agentforce only accesses data authorized by ����������ڴǰ�����’s field-level security and role-based access controls.

Data masking is now , this change was made to preserve contextual accuracy in planner and action workflows. Salesforce mitigates this by expanding its partnership with Anthropic: all Claude-based models now operate fully within ����������ڴǰ�����’s virtual private cloud, ensuring that even unmasked contextual data never leaves the trusted environment.

Every interaction with Agentforce is fully audited — including prompts, responses, toxicity scores, and user feedback — and stored securely in Data 360 for governance and compliance visibility.

How 91�Թ��� supports Salesforce Data 360

Salesforce Data 360 introduces an entirely new layer of complexity to CRM management — bringing in dozens of new metadata types, JSON-based configurations, and dynamic, near real-time components that evolve faster than most traditional Salesforce features. For DevOps teams, this makes deployment, version control, and governance more challenging than ever. 91�Թ��� bridges this gap, giving teams the tools they need to deploy, manage, and secure Data 360 configurations with confidence.

The deployment challenge

Unlike traditional Salesforce environments, Salesforce Data 360 adds more than 30 new metadata types, covering everything from data streams and model objects to segmentation rules and activation targets. These configurations are often built with complicated dependencies, meaning a missing component can block deployments or cause production failures.

Because metadata-only sandboxes can’t preview real data, teams often struggle to test identity resolution logic or segmentation behavior before pushing changes live. And with Data 360’s rapid release cadence, definitions for identity resolution rules, calculated insights, and data streams evolve frequently, making manual tracking difficult.

The stakes are high: a single misconfigured deployment could inadvertently deactivate live data flows or exclude thousands of customers from active journeys. As Data 360 becomes a critical driver of personalization and AI, ensuring that deployments are correct, consistent, and recoverable has become a top operational priority.

�ұ𲹰������’s Data 360 capabilities

91�Թ��� provides the most comprehensive DevOps support available today for Salesforce Data 360. It handles every Data 360 component through , including Data Streams, Identity Resolution Rules, Calculated Insights, Segments, Activation Targets, and more.

With , 91�Թ��� simplifies complex packaging requirements for bundled components such as Data Lake Objects (DLOs), Calculated Insights, and Search Indexes — ensuring that interdependent assets deploy cleanly and in the right order.

Every change is automatically tracked through version control, so teams can monitor how Data 360 configurations evolve over time — even for metadata types not fully supported by other tools.

�ұ𲹰������’s complete CI/CD pipeline solution makes it easy to automate deployments across environments, while rollback capabilities let teams revert changes instantly if something goes wrong. These features bring automation, safety, and visibility to a fast-moving platform that demands precision at scale.

The business case for 91�Թ���

For organizations deploying Salesforce 360, 91�Թ��� delivers tangible business value. Deployment time drops dramatically — what once took hours of manual packaging and troubleshooting can now be done in minutes through automated validation and intelligent dependency management.

Deployment previews let teams see exactly what’s changing before it goes live, reducing risk and preventing errors that could affect live customer data or revenue-generating segments. Version control integration supports collaborative development, allowing multiple team members to work on Data 360 configurations simultaneously without overwriting each other’s changes.

91�Թ��� also strengthens compliance and governance with full audit trails, documenting every modification, deployment, and rollback — essential for regulated industries. Because 91�Թ��� continuously updates its platform to align with ����������ڴǰ�����’s latest releases, it remains future-proof, ensuring ongoing compatibility as Salesforce expands capabilities.

With 91�Թ���, teams can manage the complexity of Data 360 confidently — deploying faster, minimizing risk, and maintaining the trust and agility that enterprise-scale Salesforce DevOps demands.

Take the next step

Salesforce Data 360 is transforming how enterprises manage, unify, and activate customer data — but with its innovation comes new deployment complexity. 91�Թ��� gives DevOps teams the confidence and control they need to manage Data 360 configurations smoothly alongside their existing Salesforce operations.

Don’t let deployment hurdles slow your momentum. Join the thousands of Salesforce teams already using 91�Թ��� to deploy changes faster, safer, and more reliably — and unlock the full potential of Salesforce Data 360 with every release.

Start your today to experience �ұ𲹰������’s full Data 360 deployment capabilities with no commitment.

Or book a demo to see a personalized walkthrough showing how 91�Թ��� handles your specific Data 360 challenges.

But which scanning methods and tools should you use? Salesforce provides several built-in security analysis tools, with each designed for a different purpose. Understanding what each tool covers — and where they have gaps — helps you choose the right combination for comprehensive security coverage. And as more teams adopt AI-generated code, scanning for vulnerabilities before they reach production is no longer optional.

In this guide, we’ll break down ����������ڴǰ�����’s native security tools and show you where each shines, when an enterprise-grade platform like 91�Թ��� gives you the edge, and how to create a scalable vulnerability management strategy that fits seamlessly into your DevOps lifecycle.

Vulnerability scanning methods in Salesforce

Native Salesforce security tools are built-in features that help monitor configuration, encryption, and code quality: Health Check grades your configuration settings, Shield handles encryption, and PMD flags programming mistakes. The most comprehensive scanning tool that Salesforce offers is Code Analyzer, which brings together different code-scanning engines, such as PMD, RetireJS, and ESLint, under a single umbrella to scan Apex, Visualforce, and Lightning components. Let’s look at each in a little more detail.

Salesforce Health Check

Health Check is, at its core, a pretty basic config checker. It takes your org’s current setup, compares it to ����������ڴǰ�����’s recommended baseline (or up to five you’ve uploaded yourself), and flags mismatches by risk level so you can tackle the most serious “High Risks” first, then work your way down to “Informational”.

What Health Check scans:

• Password policies
• Session timeout settings
• Network access controls
• Login IP rules and restrictions

It’s easy to see why teams use Health Check. The “Fix Risks” button promises quick solutions, and the top-line score keeps stakeholders happy at a glance. But it’s important to bear in mind that Health Check doesn’t touch your code.

What Health Check doesn’t scan:

• Apex classes
• Lightning and Web Components
• Flows or Process Builders
• Custom Visualforce pages

Consider Health Check a configuration-hygiene tool only; it doesn’t provide visibility into programmatic risks such as SOQL injection or cross-site scripting. For that, you’ll need something a little more heavy duty.

Salesforce Shield

Shield 91�Թ��� Encryption uses AES 256-bit encryption to keep your sensitive data safe. You can choose probabilistic encryption for the strongest protection — though it disables filtering and sorting — or deterministic encryption, which allows those features but offers slightly less security. If you want full control, Bring Your Own Key (BYOK) lets you manage the entire encryption key lifecycle yourself.

But Shield doesn’t stop at encryption. It also includes monitoring features:

• Event Monitoring tracks over 50 event types, from logins to API calls to report exports.
• Real-time streaming feeds data straight into your Security Information and Event Management (SIEM) tool of choice.
• Field Audit Trail extends your audit history from the usual 18–24 months to a full decade.
• Field tracking limits jump from 20 to 60 fields per object.
• Data Detect uses regex (pattern-matching) searches to find sensitive information like credit-card numbers or email addresses that are wrongly stored in fields or files.

It’s a solid setup, but only protects your data, not the applications accessing it. Shield also only focuses on data-at-rest — encrypting and monitoring stored data, but not spotting or stopping vulnerabilities in the app layer.

Salesforce Code Analyzer: strengths, limits, and where it fits

PMD is great at flagging common coding mistakes in Salesforce that can cause performance issues or deployment failures, whether that’s queries placed inside loops that burn through your SOQL limit or hardcoded IDs that blow up when you switch orgs.

Salesforce saw the value of PMD and built it into their Code Analyzer CLI tool — complete with ESLint for JavaScript and a few other linters thrown in. Code Analyzer is now the go-to quality gate for AppExchange submissions.

Getting Code Analyzer up and running is fairly straightforward:

• Use IDE extensions to catch issues as you type
• Run Code Analyzer via the command line in your build scripts
• Hook Code Analyzer into your CI pipeline to automate the checks

With Code Analyzer, you get cleaner code, fewer governor limit issues, and consistent standards — core essentials for any Salesforce team. But it’s important to note that as an Application Security Testing (SAST) tool, it cannot detect runtime-specific security issues.

While Salesforce Code Analyzer does bundle general-purpose linting tools like PMD and ESLint, its real security strength comes from the integration with Salesforce Graph Engine (SFGE). SFGE goes beyond simple code checks — it follows how data moves through your code to spot hidden risks. By tracing user input all the way to where it’s used (for example, in a SOQL query or DML statement), it can catch multi-step vulnerabilities like injection risks or missing security checks that other scanners might miss.

Because it runs locally on source files, Code Analyzer uses zero API calls — a major advantage over cloud-based scanners. That means you can scan frequently in your CI/CD pipelines without affecting API limits or production performance.

The goal should be to make Code Analyzer a standard pre-deployment security gate within your pipeline. Embedding it in your workflow ensures high-risk vulnerabilities are caught and fixed before code ever reaches production.

Code Analyzer should form just one layer of a defense-in-depth strategy — complemented by dynamic testing, runtime protection, dependency scanning, manual reviews, and penetration testing. No single tool can eliminate every risk; a mature security posture relies on multiple layers working together to safeguard your Salesforce environment.

AI-generated code: a gap native tools weren’t built for

����������ڴǰ�����’s native tools were designed to catch known patterns in human-written code. AI-generated code introduces a different challenge: it often looks syntactically correct while containing subtle logic errors, insecure sharing configurations, or architectural anti-patterns that don’t match the patterns these tools were trained to detect.

There’s also a currency problem. AI models are trained on historical data and lag behind the latest Salesforce security guidance and metadata behavior. That means AI-generated code may comply with yesterday’s standards while violating today’s. A static analysis tool that’s continuously updated to reflect the latest Salesforce platform changes and security best practices is essential for closing that gap.

Deterministic guardrails help you catch risky changes before they reach production — so your team can adopt generative tools responsibly, without adding to your security risk.

When scale breaks manual security

Most enterprise Salesforce setups aren’t neat and linear. You’ve got development, integration, UAT, staging, and production environments — and each has its own quirks: different configurations, different permissions, and different code.

Keeping security watertight across all of them with manual checks is nearly impossible. Things get missed, gaps open up, and the more environments you add, the harder it becomes to see where something’s gone wrong — let alone knowing how to fix it.

How often should I be performing vulnerability scans on my Salesforce environments?

How often you scan your environments depends on how fast you’re shipping changes. If you’re deploying daily, you’ll need scanning built right into your CI/CD flow — every commit, merge, and push. For most teams, here’s what works:

Continuous scanning (recommended):

• Every pull request gets scanned automatically
• Developers fix issues before code merges
• Security stays embedded in your workflow

Scheduled scanning (minimum baseline):

• Weekly scans for active development orgs
• Monthly scans for production
• Quarterly deep-dives for dormant orgs

But there’s a catch: manual scanning doesn’t scale. As environments multiply, small differences in configuration — like permissions or access controls — can quickly grow into major security gaps. Issues that go unnoticed in a sandbox can escalate in QA and reach production, where they expose sensitive data to real users.

Manual checks rarely keep pace with changing environments, and the cost of discovering vulnerabilities late is steep. A CRUD or FLS violation found in development is a quick fix; the same issue found in production can trigger incident response costs, compliance investigations, and deployment delays.

Building a continuous vulnerability management practice

Vulnerability management in Salesforce is an ongoing practice. The strongest security comes from embedding scanning into your existing DevOps workflow, not bolting it on as an afterthought.

The shift from reactive to proactive scanning

Most teams start scanning reactively. A penetration test finds issues. An audit flags problems. A security incident forces action. But reactive scanning means you’re always playing catch-up.

With proactive scanning:

• Vulnerabilities get caught during development, not after deployment
• Security becomes part of quality assurance, not a separate gate
• Developers learn secure coding patterns through immediate feedback
• Your security posture improves with every release

The transition requires three key elements: automated tooling that fits your pipeline, clear ownership of security tasks, and metrics that track improvement over time.

Integrating security into your DevOps pipeline

Security that slows down delivery won’t last. Your scanning needs to match your development velocity. For teams using version control and CI/CD, that means scanning at specific trigger points:

Pre-commit scanning:

• Flags issues as developers write code through IDE plugins
• Prevents bad patterns from spreading with immediate feedback
• Reinforces learning in real time

Pull request scanning:

• Catches issues before merging through automated reviews
• Builds shared accountability through team visibility
• Speeds up remediation with fix suggestions

Deployment scanning:

• Validates changes before production
• Catches configuration drift between environments
• Provides an audit trail for compliance

Each scanning point serves a purpose. Skip one, and vulnerabilities slip through. Layer them together, and you create a robust process.

How to find and fix your most critical vulnerabilities

Effective vulnerability management is about fixing the right things. Every org has limited resources, so prioritization becomes critical to maintaining both security and velocity.

How to focus on the threats that matter most

A SOQL injection in a payment flow is far more serious than a code-complexity warning in an internal report. Effective vulnerability management means focusing effort where it counts — using exploitability, impact, and context as your guide.

• Exploitability: How easily could someone take advantage of this issue?
• Impact: What would happen if it were exploited?
• Context: Where does this vulnerability live?

These factors help you triage vulnerabilities quickly and consistently:

🔴 Critical — fix immediately:

• SOQL injection vulnerabilities
• Missing CRUD/FLS checks on anything customer-facing
• Hardcoded credentials left in the code
• Cross-site scripting issues in Lightning Components

🟠 High — fix within the sprint:

• Permission bypasses in Flows
• Unescaped user input in Visualforce
• Missing error handling in integration points
• Use of deprecated APIs

🟡 Medium — schedule for next release:

• Code complexity issues
• Performance optimizations
• Clearly justified false positives
• Legacy code already on the refactor roadmap
• Issues inside third-party packages you can’t control

How to measure and prove security progress

You can’t improve what you don’t measure. Tracking the right metrics helps you prove that your security efforts are working — and justify continued investment in scanning tools.

Start with your core performance metrics:

• Mean Time to Detection (MTTD): How quickly are new vulnerabilities discovered after they’re introduced?
• Mean Time to Remediation (MTTR): Once found, how fast do they get fixed?
• Vulnerability density: Number of vulnerabilities per 1,000 lines of code — a simple measure of codebase health.
• Fix rate: Percentage of identified issues that actually get resolved.
• Recurrence rate: How often the same vulnerability patterns resurface, showing where more training or process change is needed

Then add leading indicators to track long-term improvement:

• Percentage of pull requests scanned for security issues
• Developer participation in secure coding training
• Adoption rate of secure code templates
• Use of automated fix suggestions

These metrics tell a clear story: whether your security program is actually reducing risk — or just producing more reports.

�ұ𲹰������’s Code Reviews: The solution to Salesforce vulnerability scanning

Native Salesforce tools are great building blocks — but they’re siloed. Health Check focuses on configuration, Shield secures data at rest, and Code Analyzer scans code quality. What’s missing is a single, connected view that covers everything.

91�Թ��� Code Reviews unifies those layers — scanning Apex classes, Lightning Web Components, Flows, Visualforce pages, Aura components, and permissions all mesh together. Instead of treating them like scattered bits of code, it scans the whole system as one connected setup. Every time a pull request is opened against a tracked branch, you get a fresh, automated review. Here’s what that typically covers:

• Apex classes scanned for injection vulnerabilities
• Flows checked for permission bypasses
• Lightning Web Components reviewed for XSS risks
• Visualforce pages inspected for security flaws
• Aura components validated for exposure issues
• Every metadata config is assessed for misconfigurations

Each type brings its own security headaches, and 91�Թ��� knows how to spot them all:

• Where a single manual fix might take up eight hours, 91�Թ��� gets it done in minutes.
• Salesforce-aware filtering cuts false positives significantly.
• Even your installed packages get scanned, so third-party dependencies are covered.

Best of all? Code Reviews does all this without touching your API limits. While typical org scans can chew through thousands of API calls per run, Code Reviews connects to your Git repository (GitHub, GitLab, Bitbucket, etc.) by creating webhooks for relevant events — like pull requests, merges — so it leaves your API limits untouched.

How to do security testing in Salesforce with �ұ𲹰������’s Code Reviews

Security testing shouldn’t add friction to your release process — it should run alongside it. �ұ𲹰������’s Code Reviews makes that possible by building automated security checks directly into the way your team already works. Every change, every pull request, every merge gets scanned automatically, so vulnerabilities are caught the moment they’re introduced, not after deployment.

The real advantage is how seamlessly Code Reviews integrates into your CI/CD pipelines. Security scans trigger automatically on every commit, with feedback delivered right inside the pull request — no manual steps, no context switching. Even Flow updates get the same protection, giving admins the same level of assurance as developers.

There are no silos between code and config — just connected, continuous scanning that keeps your entire Salesforce environment secure before anything reaches production.

Building a vulnerability strategy for AI-assisted development

As AI tools become a part of how your development team works, your vulnerability scanning strategy needs to account for the code it produces. That means treating AI-generated changes with the same rigour as human-written changes — not more trust, not less.

The teams that adopt AI responsibly are the ones with a deterministic, continuously updated quality layer already built into their CI/CD pipeline. Every pull request — whether written by a developer, an admin, or an AI agent — goes through the same checks. The guardrails don’t change based on who wrote the code.

Transform your security practice today

Drowning in PMD violations? Sign up for �ұ𲹰������’s and watch those 743 violations drop to 50 focused, fixable issues, with clear steps to fix them. You’ll get a real view of your security posture, not just another overwhelming list of warnings.

Managing complex enterprise orgs? Let’s talk. Book a demo built around your environment, and we’ll show you exactly what you stand to gain.

The good news, though, is that managing Salesforce technical debt doesn’t have to require a massive refactor or months of planning. It simply means treating debt like backlog work and folding it into the rhythm you already use.

In this guide, we’ll show you exactly how to do that — with a five-step framework for surfacing and addressing the right debt, plus a roadmap for starting with Process Builder to Flow migration.

What technical debt actually costs your Salesforce org

Technical debt is the real and mounting cost of rework that creeps into your org every time a quick fix takes precedence over a sustainable solution. In Salesforce, there are a few different ways this shows up, each undermining your ability to deliver:

• Code debt shows up as hard-coded IDs that break between environments, Apex classes that fail under bulk loads, and test coverage that technically clears but does little to validate actual business logic. These shortcuts make deployments brittle and slow down every future release.

• Configuration debt accumulates in duplicate approval processes, sprawling sets of nearly identical email templates, and the kind of feature bloat where half the “solutions” in the org sit unused — but still clutter user experience and degrade performance.

• Automation debt is the silent, but deadly. Overlapping Process Builders and Flows often target the same objects, creating recursive loops, unpredictable behavior, and debugging sessions where tracking down a single field update can take days.

• Documentation debt surfaces whenever context is missing. Without clear guidance on why something was built, new developers default to creating redundant components rather than modifying existing ones.

• People debt emerges when critical knowledge is concentrated in just a handful of individuals. If those team members are unavailable, progress can stall and the team might resort to hasty workarounds.

• Architectural debt traces back to foundational missteps — like introducing dozens of custom objects where standard ones would have worked. These decisions lock you into rigid patterns that limit agility for years.

The result of all this is an org that’s harder for users to navigate, harder for admins to manage, and harder for developers to deploy changes across.

Recognizing the tech debt patterns that slow your releases

Not all technical debt weighs your org down equally. Some issues are just background noise, while others actively block deployments, slow performance, or open up compliance risks. In mature Salesforce environments, certain patterns crop up again and again: sprawling configuration that confuses users, layers of overlapping automation that create unpredictable behavior, bloated access models that don’t stand up to audit, and the trail of abandoned components left behind by years of quick fixes.

The 80/20 rule applies here — a small share of debt drives the majority of deployment problems, performance issues, and maintenance overhead. The challenge is knowing which debts to tackle first, because targeting the high-impact patterns delivers the biggest payoff.

Building systematic debt reduction into your development process

The fastest path out of technical debt is weaving debt reduction into the same rhythm you already use for feature delivery. Here’s a five-step approach to make it sustainable:

1. Score debt items by impact and effort

Not all debt is equal. Some issues quietly sit in the background, while others actively slow down your releases or create compliance risks. To make sense of it all, give each debt item two scores:

• Business impact (1-5): How much this slows delivery, risks errors, or affects end users.
• Remediation effort (1-5): How difficult it will be to fix.

Your priority should be the debt that’s scored as high-impact, but low-effort. For example, an inactive Process Builder that still fires on every Opportunity save might score Impact 5, Effort 2. That makes it a high-priority task.

2. Write debt stories in business language

To make debt reduction visible and valuable to stakeholders, capture it as backlog stories written in business terms. For example, “As a developer, I need configurable record IDs so deployments don’t break between environments.” This phrasing makes the task specific (configurable IDs), testable (does a deployment succeed across environments?), and valuable (reliable releases for the business).

3. Build documentation into development

Technical debt often snowballs when context is missing. If future teams don’t know why a rule, Flow, or object exists, they’ll create something new instead of improving what’s already there. The antidote is lightweight, living documentation: clear naming conventions, useful component descriptions, and commit messages that explain why changes were made. This keeps your org understandable and prevents redundant components from creeping in.

4. Break big tasks into smaller increments

Trying to launch a massive cleanup project often runs into resistance — leaders see it as slowing down delivery without a clear benefit. Instead, break large remediation efforts into smaller chunks.

For instance, instead of “migrate all Process Builders to Flow,” create backlog items like “migrate Opportunity assignment automation to Flow” so that each segment of work delivers progress without overwhelming the team or the business.

5. Track progress with meaningful metrics

To prove the value of debt reduction, track it alongside your usual delivery metrics. One useful measure is the Technical Debt Ratio (TDR), which compares the effort spent on maintenance (bug fixes, patching, refactoring) to the effort spent on new features or innovation. The TDR formula is:

TDR = (Remediation Cost / Development Cost) × 100

A rising ratio shows that maintenance is consuming more capacity, while a falling ratio indicates you’re freeing teams to deliver new value. Pair that with concrete indicators like:

• Improved deployment success rates
• Increased test coverage quality (not just the 75% minimum)
• Reduced lead times from commit to release

From plan to practice: Start tackling tech debt with Process Builder to Flow migration

If you’re looking for a single action that proves the value of technical debt reduction, migrating from Process Builder to Flow could be it. This step aligns with ����������ڴǰ�����’s long-term roadmap, delivers immediate performance improvements, reduces maintenance complexity, and eliminates a common source of automation conflicts.

Choose the highest-impact automations for migration

Don’t try to migrate everything at once. Instead, identify the best candidates for early wins by looking at:

• CPU consumption: Automations that frequently hit limits
• Maintenance frequency: Flows you constantly have to update or fix
• Business criticality: Processes that directly affect revenue, compliance, or customer experience

This helps you prioritize where migration will deliver the most impact without overwhelming your team.

De-risk migration with systematic testing

One of the biggest fears teams have is the new Flow behaving differently from existing Process Builder logic. That’s why parallel testing is important. This means running the new Flow alongside the old Process Builder to validate that the logic matches exactly before cutting over.

Anticipate and address common pitfalls

Process Builder and Flow aren’t identical, so plan for a few key differences. Flows handle records in batches, while Process Builder often runs one record at a time. The order of operations can also shift during migration, and recursive logic may behave differently — a Flow might re-trigger where Process Builder wouldn’t, or vice versa. By knowing these pitfalls up front, you can design migrations that avoid unexpected regressions.

Prove value with metrics

Migration is a perfect chance to make the benefits of debt reduction visible. Document before-and-after metrics like CPU time reductions, faster save operations, and simplified maintenance workflows. These numbers tell a compelling story to stakeholders who want evidence, not just reassurance.

Position as a proof of concept

A successful Process Builder to Flow migration does more than clean up automation debt — it shows your team and your stakeholders what’s possible. It’s a proof of concept for broader debt reduction: one category fixed, with measurable improvements to system reliability and team confidence.

How 91�Թ��� simplifies technical debt management

The five-step approach we’ve outlined — scoring debt by impact, writing it into backlog stories, documenting, breaking it into increments, and tracking metrics — gives you a sustainable way to tackle debt.

But the reality is that without the right tools, teams often struggle to act on these good intentions. Debt lingers because cleanup feels risky, testing is slow, or deleting unused components is a guessing game. 91�Թ��� removes those barriers by turning high-risk, manual tasks into predictable workflows.

Spot and prioritize the right debt

�ұ𲹰������’s Code Reviews lets you run static code analysis across Apex, Flows, Lightning Web Components, Visualforce, and Aura, so you can surface violations, security vulnerabilities, and dependency risks early. Because Code Reviews is built into �ұ𲹰������’s complete DevOps solution, you can flag issues in the same UI you use for deployments, enforce standards automatically, and even apply autofix recommendations that turn hours of remediation into minutes.

Enforce standards with Code Reviews’ quality gates

�ұ𲹰������’s Code Reviews includes quality gates that make standards enforceable across your DevOps pipeline. Every pull request or CI job is automatically checked against those thresholds, so new debt never slips into production unnoticed. Combined with , this keeps teams focused on preventing fresh debt while steadily improving legacy areas. Instead of a one-time cleanup effort, technical debt management becomes part of the everyday rhythm of development.

This matters especially as AI contributes more code to your pipeline. Quality gates apply the same deterministic checks to every change — whether it was written by a developer, an admin, or an AI agent. AI-generated code can look syntactically correct while quietly introducing governor limit violations, insecure sharing patterns, or architectural anti-patterns that compound into debt over time. Automated guardrails that catch those issues at the pull request stage — before they merge — are the only scalable way to prevent AI from accelerating the very problem you’re trying to solve.

Turn backlog items into safe, achievable tasks

Technical debt stories often stall because teams don’t feel safe tackling them. 91�Թ��� removes that hesitation. Instead of writing destructiveChanges.xml files by hand, you can select unused fields, automations, or templates for retirement and let 91�Թ��� generate the manifest automatically. Each deletion is logged for auditing, and if anything breaks, rollback snapshots mean you can undo the change instantly. Debt items that once felt too risky become clear, actionable items that fit naturally into your backlog.

Build documentation into the process

Org Intelligence builds on �ұ𲹰������’s automatic record keeping — , commit messages, change monitoring, and audit trails — by adding fast, centralized insight into how your org is structured. It shows dependencies across fields, Flows, automations, and permissions, with historical context for auditability and troubleshooting. Because these insights live in a shared interface, they spread context across the team and become the living documentation that helps prevent debt and gives future developers and admins confidence to build on what’s already there.

Measure progress with real data

91�Թ��� gives teams visibility into like deployment frequency, lead time, and success rates, all in one place. When you can see hard numbers on how often you deploy, how long changes take, and how reliable those deployments are, you can prove that debt reduction ������’t just cleanup for its own sake. That proof builds trust with stakeholders, helps teams prioritize, and shows that the time spent addressing technical debt pays back in real improvements to release speed and stability.

Tackle technical debt before it slows you down

When you identify the high-impact patterns dragging down your org, build remediation into your development process, and rely on a complete DevOps platform to handle what manual methods can’t scale, debt reduction becomes systematic and sustainable.

The 80/20 approach ensures your limited time targets the debt that matters most: automation chaos, configuration sprawl, and missing documentation that forces developers into redundant work. 91�Թ��� helps you focus on those areas by taking the risky, manual parts out of the process. With automation, code reviews, problem analyzers, and rollback capabilities, the work shifts from stressful guesswork to a predictable, scalable process.

Ready to see how automated debt management works in practice? to get full visibility into your technical debt. Or book a demo to see how other Salesforce teams are using 91�Թ��� Code Reviews to catch issues earlier, enforce standards automatically, and keep their orgs running smoothly with fewer errors and rework.

Together, monitoring and observability strengthen every stage of the DevOps lifecycle. They help you detect issues early, analyze data quickly, and feed lessons back into future releases — leading to faster resolution, more reliable deployments, and continuous improvement across your Salesforce instance.

In this post, we’ll explore how you can make sure your DevOps lifecycle leverages observability and monitoring effectively, from selecting the right tools to turning valuable insights into action.

What is monitoring in Salesforce DevOps?

Monitoring in Salesforce DevOps means tracking deployments, integrations, and performance metrics against set parameters. If a deployment job fails, an API call volume spikes, or response times slow down, monitoring tools alert team members so they can act quickly to protect the stability and reliability of your environment.

Monitoring is reactive — you’re only alerted when known conditions are triggered — but it ensures problems don’t go unnoticed and helps teams deal with issues before they spread.

What’s the difference between monitoring and change monitoring?

Monitoring keeps you informed about issues in your Salesforce org, while change monitoring reveals what actually changed — helping you understand what caused them.

In Salesforce, problems often stem from metadata, automation, or user permission changes rather than just system performance. By surfacing recent changes, change monitoring gives you the context to link new errors back to the updates that may have introduced them. That way, instead of just knowing “a deployment failed,” you can see that it failed because a workflow rule was altered or because a dependency wasn’t included.

What is observability in Salesforce DevOps?

Observability is about understanding what’s happening inside your Salesforce org by looking at the data it produces. Rather than waiting for alerts to tell you something has gone wrong, observability helps you understand the current state of your org, why issues occur, and how different parts of your system interact.

Teams doing Observability well collect and interpret signals like logs, metrics, and traces. These signals are the external outputs of your system — giving you visibility into how integrations, components, and services behave in real time. With that information, teams can move beyond surface-level symptoms and uncover the chain of events that led to the problem.

For example, observability tools might show that a recently activated Flow is throwing errors whenever users try to create a new opportunity. Instead of finding out later through scattered error emails or user complaints, you see the failures in real time with full error context, so you can investigate and fix the problem before it impacts more users.

“Observability is a cornerstone of any successful Salesforce DevOps strategy. It’s not just about knowing what’s happening in your systems but understanding why it’s happening — so you can fix issues faster, prevent them proactively, and continuously improve how you deliver value.” — Rob Cowell

Observability vs monitoring: key differences

Monitoring and observability work hand in hand, but they’re not interchangeable. Monitoring is the early warning system that spots when something breaks, fails, or drifts beyond the limits you’ve defined. Observability is understanding these warnings, helping you investigate cause and effect, and carry out deeper analysis of the overall health and internal state of your org.

The key difference is in scope. Monitoring is designed around known failure scenarios: thresholds, alerts, and symptoms you can anticipate. Observability is an open-ended comprehensive view. It gives you the tools to ask new questions when unexpected issues come up. This is especially important in Salesforce environments where complex dependencies mean the root cause ������’t always obvious.

Why you need both: the benefits of a unified approach

On their own, monitoring and observability are powerful, but together they create a feedback loop that makes Salesforce DevOps more reliable and resilient.

For DevOps teams, this unified approach has clear benefits. You spend less time firefighting and more time solving problems with confidence. You can trace issues back to their source faster, reduce the risk of repeated failures, and use the insights gained to strengthen your release process over time.

Combining the two shifts teams from being reactive to being proactive. Instead of just waiting for the next error alert, you can spot patterns, anticipate issues, and continuously improve the way your Salesforce environment runs.

Top Salesforce observability and monitoring tools

����������ڴǰ�����’s native tooling won’t give you full visibility into your system health. Debug logs expire quickly, resource limits can terminate transactions without warning, and the multi-tenant architecture of the Salesforce ecosystem often obscures the root cause of issues. That’s why it’s important to be deliberate about monitoring and observability, choosing tools and practices that support your team with clear, actionable insights.

Metadata change monitoring

Change monitoring tools track configuration and code changes across environments. Tools like �ұ𲹰������’s automated change monitoring highlight changes in real time through daily reports and configurable notifications, making it easier to link new issues to recent updates.

�ұ𲹰������’s Flow and Apex monitoring give a centralized view of failures, integrate with Slack and Teams, and support custom notification rules so teams only get alerted about the errors that matter.

Event monitoring

Event monitoring in Salesforce gives you visibility into system-level activity such as logins, API calls, and Apex executions. Every org includes a limited free tier, but the data is delayed and covers only a handful of events. For teams that need broader coverage and instant visibility, Salesforce Shield Real-Time Event Monitoring unlocks a much larger catalog — from report exports to Flow executions — and delivers events as they happen.

Structured logging

Structured logging means embedding consistent log entries into Apex code and automations to capture what happens during a transaction. Unlike ����������ڴǰ�����’s raw debug output, these logs are recorded in a standard format so they can be stored, queried, and analyzed. Because Salesforce doesn’t offer this natively, teams either build their own logging framework or use third-party tools like Nebula Logger and .

These tools capture logs asynchronously with platform events or store them in custom objects, making them persistent beyond ����������ڴǰ�����’s normal limits, queryable with SOQL, and usable for downstream alerting, analysis, and reporting — either in Salesforce dashboards or external software development tools.

The (a VS Code extension from Certinia) offers a cleaner way to review downloaded debug logs and follow the flow of a transaction. It’s useful for individual debugging, but less suited for team-wide access because the logs are stored locally and shared manually.

Turning data into action: making the most of your insights

The value of embedding monitoring and observability tools throughout your DevOps pipeline ������’t just in data collection. You also need to know which metrics to track and how to respond. For Salesforce DevOps teams, some of the most useful metrics include:

• Deployment success rate: this tracks how often deployments succeed on the first attempt — highlighting issues with validation or dependencies.
• Mean time to resolution (MTTR): one of the core DORA metrics, the average time it takes to investigate and fix issues after detection.
• Flow and Apex error counts: how frequently automations or custom code fail, and whether error rates are rising or falling.
• API usage and limits: these metrics involve monitoring callouts to spot performance bottlenecks or risk of hitting governor limits.
• Test coverage and failure rates: identify if Apex tests run reliably and whether they are effective at enabling protection against regressions.
• User impact metrics: these show how issues affect end users directly, by tracking login errors, page load times, or failed transactions.

Once these metrics are visible in dashboards and fed into team channels, they become part of daily workflows. By reviewing them regularly, teams can prioritize fixes, spot recurring trends, and feedback into release processes — turning analytics into continuous improvement and making the whole DevOps lifecycle more efficient.

Challenges and pitfalls to watch out for

Left unmanaged, observability and monitoring can end up overwhelming teams with noise or become so fragmented that they add complexity instead of reducing it. Without thoughtful design and clear processes, they can end up obscuring the very problems they’re meant to reveal.

Alert fatigue

When every small fluctuation triggers a notification, important incidents get buried. Instead of chasing noise, align alerts with your release pipeline and existing tool stack so they flag what actually needs a response and surface where people will see them. This keeps the signal clear and helps the team act faster when something breaks.

Incomplete coverage

Debug logs or basic metrics leave you with critical blind spots. Instead, layer multiple approaches, like Flow and Apex error monitoring, change monitoring, and event monitoring, so you get a more rounded picture of what’s happening in your org.

Poor actionability

Collecting data is easy; turning it into action ������’t. If no one owns alerts or there’s no process to follow, issues sit unresolved. Building observability into your incident management means every alert has a clear owner, a documented path to resolution, and feedback that improves the next release.

Overcomplication

Stacking too many tools or dashboards creates silos and confusion instead of clarity so teams should consolidate where possible. One integrated DevOps solution is better than stitching together multiple tools that don’t talk to each other. Choose tools that integrate cleanly so you’re not navigating multiple files, dashboards, and systems that reduce overall efficiency.

Cultural gaps

If observability is seen as just monitoring for the operations team, its impact is limited. Make observability a key part of how the whole team works — not just admins but also developers, testers, and business stakeholders — ensuring the practice scales across distributed teams and improves overall capability.

Put observability and monitoring into action

Strong monitoring and observability practices can transform your team’s ability to deliver on Salesforce. According to the State of Salesforce DevOps 2025 report, teams with an observability solution are 50% more likely to catch bugs within a day and 48% more likely to fix them within a day. Find out more about how the 91�Թ��� Agent takes this further with AI built in to observability.

To see how 91�Թ��� can help your team today, explore our Flow and Apex error monitoring solution. And dive deeper into building an observability strategy by downloading our free .

Configuring Salesforce security features is one thing; proving ongoing compliance to regulators is another. Plus, as data protection regulations like GDPR, CCPA, and HIPAA multiply — and enforcement becomes more aggressive — businesses need more than checkboxes and trust statements. They need a verifiable audit trail that shows, with evidence, how their Salesforce org manages data.

We’ll break down why ����������ڴǰ�����’s platform compliance certificates aren’t enough to satisfy auditors, the kinds of documentation regulators expect to see, and how to move from reactive, last-minute compliance efforts to proactive, automated assurance. You’ll learn about Salesforce Shield, and how 91�Թ��� helps transform compliance from a manual, stressful process into a systematic, reliable part of your DevOps pipeline.

Why platform compliance doesn’t equal organizational compliance

Yes, Salesforce can be configured to meet GDPR standards, but your organization must prove that it consistently enforces these standards. This means not just having the platform in a “GDPR-capable” state, but actively generating deletion certificates within 30 days of a Data Subject Request, maintaining accurate consent timestamps for every customer interaction, and showing that EU resident data is housed in EU-based instances.

The absence of a solid audit trail becomes a significant issue when a regulator, customer, or internal stakeholder asks for evidence, like “Show me proof that a customer’s data was deleted from all systems, including backups.” Your Salesforce Trust Certificate only confirms that the platform can facilitate these actions; it doesn’t demonstrate your organization’s implementation of them.

For every regulation — whether it’s GDPR, CCPA, , or — there are specific artifacts you must generate to prove compliance. These include deletion confirmations with timestamps, consent audit trails, encryption certificates, and regional data storage verification.

Also, global organizations face an additional layer of complexity. You must meet the highest standard among the regulations you’re subject to. For example, even if your primary business operates under CCPA’s 45-day timeline for Data Subject Requests, you’re still bound by GDPR’s 30-day deadline if you handle data from EU residents. This “highest common denominator” requirement adds pressure to ensure compliance across multiple jurisdictions simultaneously.

What is Salesforce Shield?

Salesforce Shield is a suite of native security and compliance features designed to help organizations meet rigorous data protection and audit requirements. As a paid add-on, it extends ����������ڴǰ�����’s native security controls with three key features:

• Event Monitoring: Tracks detailed user activity — such as logins, API calls, and report exports — giving you visibility into who accessed what data and when. Logs are retained for 30 days by default, but this can be extended for up to a year, making them essential for compliance audits and incident investigations.

• Field Audit Trail: Extends the standard field history tracking limits, allowing you to retain historical data changes for up to 10 years. This ensures you can prove when and how sensitive data was modified — a critical requirement for frameworks like SOX and GDPR.

• 91�Թ��� Encryption: Provides encryption-at-rest for sensitive data, protecting it from unauthorized access even if the database is compromised. Admins can manage encryption keys and apply encryption selectively across fields, ensuring both security and system performance.

Together, these features form the bulk of ����������ڴǰ�����’s enterprise-grade security and compliance model. In the sections that follow, you’ll see how Shield supports each layer of your security framework — from organization-level monitoring to data encryption.

Building your four-layer security model

Achieving Salesforce data compliance requires a layered approach to security and monitoring, including the Shield features mentioned above. At each layer, you’ll need specific tools and documentation to demonstrate compliance with various regulatory frameworks like SOX, GDPR, and HIPAA.

Here’s how to build a four-layer security model that can withstand scrutiny during audits.

1. Organization-level security: Access logs and session monitoring

Your organization’s access logs and session monitoring are crucial for proving compliance with regulations like SOX, which requires comprehensive change management and audit trails.

only records configuration and metadata changes — such as updates to profiles, permissions, or automation — but it does not capture user access or session activity — for that you’ll need Shield’s Event Monitoring.

2. Object and field-level controls: PII protection maps

At the next layer, object and field-level controls are essential for protecting Personally Identifiable Information (PII). These controls dictate which roles can access sensitive customer data. But, it’s important to note that the native Salesforce reporting capabilities have row limits and complexity constraints, which make it difficult to produce a complete picture of who can access what.

To address this, lots of organizations end up manually documenting field-level permissions and mapping out access based on role assignments. This is important for compliance, but can be labor-intensive and prone to human error, particularly when you need to demonstrate the complete lineage of access rights across multiple profiles and permission sets.

3. Record-level sharing rules: Enforcing least-privilege access

Within a Salesforce org, record-level sharing rules help enforce the principle of least privilege — ensuring that users only have access to the data they need. This segregation of data supports compliance requirements such as GDPR and HIPAA by protecting sensitive records and reducing the risk of unauthorized access within the tenant.

Proving historical access patterns and data changes in Salesforce requires different tools. The Field Audit Trail preserves historical field value changes, providing long-term field-level history retention — but it does not record who viewed or accessed records.

4. Shield 91�Թ��� Encryption: Encryption-at-rest controls

����������ڴǰ�����’s Shield 91�Թ��� Encryption ensures that your data is encrypted at rest, which is vital for meeting privacy regulations such as GDPR and HIPAA. Encryption-at-rest keys form the foundation of ����������ڴǰ�����’s data protection model, helping organizations demonstrate compliance with standards that mandate the safeguarding of stored data.

It’s important to understand that encryption can impact certain Salesforce functions, including report filters, lookup relationships, and workflow rules that rely on encrypted fields.

While encryption adds complexity to day-to-day operations, its compliance and security benefits are undeniable. The key is to configure encryption in a way that maintains business continuity and visibility, while ensuring data remains secure and compliant.

Building your evidence pipeline

Automating the right to be forgotten across your entire data estate

The right to be forgotten — also known as the right to erasure under GDPR — allows individuals to request the deletion of their personal data. But fulfilling this requirement manually is an incredibly time-consuming task. Manual deletion using Data Loader takes hours for each request, as you must identify records across objects, verify relationships, document deletions, and purge backups. ����������ڴǰ�����’s Privacy Center can automate some of this, but it requires object-by-object configuration and doesn’t handle custom objects or PII mapping easily.

�ұ𲹰������’s backup workflow supports bulk deletion of personal data from historical backups with full audit logging, allowing you to process large requests in repeatable batches and prove what was removed and when — without re-introducing data through restores.

There are a couple more things to consider here:

• The Recycle Bin: ����������ڴǰ�����’s Recycle Bin only retains records for 15 days — or 30 days if you have enabled Extended Recycle Bin Retention — and when records are deleted, metadata relationships are destroyed. This makes it nearly impossible to reconstruct deleted data after this period. This creates a major issue when trying to comply with long-term data retention requirements. For example, if an audit or legal investigation surfaces after two weeks, your ability to provide a full trail of deleted data is severely limited.

• Encryption and consent management: Shield 91�Թ��� Encryption protects data at rest, but it can affect filters, searches, and matching logic used by consent processes. If your consent flows (, Contact Point records) rely on identifiers like email or phone, plan for deterministic encryption or alternate keys so lookups still work. The key is designing your identifier strategy so security and privacy processes both function.

�ұ𲹰������’s data retention addresses a different compliance challenge — extending audit log retention far beyond ����������ڴǰ�����’s native 180-day limit. It allows you to maintain comprehensive audit logs throughout the seven-year period typically required for SOX compliance and litigation holds. This makes your long-term audit trail both robust and defensible, without the risk of missing critical data during an audit.

Proving data residency

Data residency is a key aspect of data compliance, especially for organizations operating globally under privacy laws such as GDPR. ����������ڴǰ�����’s Hyperforce enables customers to host their data within specific geographic regions, helping meet data residency and sovereignty requirements.

For orgs not yet migrated to Hyperforce, regional control is more limited — adjusting where data is stored typically requires Salesforce Support intervention, which can delay compliance verification during audits. Ensuring your org is deployed on Hyperforce is the most effective way to demonstrate and maintain data residency compliance at scale.

91�Թ��� simplifies this process by offering regional storage options for backups, allowing you to store your data in your chosen region, with certificates explicitly stating data location. This completes the chain of evidence auditors need to verify your data residency practices, ensuring that you’re fully compliant with international data regulations.

Industry-specific compliance paths

While Salesforce offers a comprehensive platform with a wide range of tools to help meet regulatory requirements, it’s important to understand that industry-specific compliance often demands additional configurations, documentation, and customizations.

Industry regulations place different demands on Salesforce implementations. Here’s how to configure your org to meet each standard.

• HIPAA compliance: Salesforce doesn’t automatically comply with HIPAA. To meet healthcare regulations, you must sign a Business Associate Agreement (BAA) with Salesforce and run on Enterprise Edition or higher. Most implementations also use Shield 91�Թ��� Encryption to secure protected health information (PHI) and to meet HIPAA’s privacy and security requirements. While Health Cloud provides healthcare-specific functionality, it ������’t strictly required for HIPAA compliance. In practice, many orgs supplement Salesforce with third-party auditing and data management tools to meet HIPAA standards.

• FERPA compliance: FERPA (Family Educational Rights and Privacy Act) requires specific retention policies and for schools to give parents and eligible students access to records and to manage how long those records are retained. Salesforce doesn’t enforce FERPA compliance by default, so schools typically create custom retention logic for academic records, often leveraging third-party archival solutions to store data securely. Parent access can be configured via custom development, ensuring that FERPA guidelines for record access and retention are met.

• Financial services compliance: In financial services, detailed transaction lineage documentation is required. While can capture some changes, extensive custom development is necessary to track transactions and generate the detailed reports auditors require. ����������ڴǰ�����’s built-in tools often need to be supplemented with external systems to ensure that all data is captured and compliant with SOX and other financial regulations.

Managing compliance across multiple orgs

As organizations grow through acquisitions, managing Salesforce compliance across multiple orgs becomes increasingly complex. Each new org often brings different security settings, custom objects, and data classifications, leading to customization debt and creating compliance blind spots. These inconsistencies can make it difficult to ensure all orgs meet regulatory requirements, particularly when handling global compliance:

• Regional data residency and federated search: Regional data residency laws, like GDPR, often require org separation (e.g., EU data must reside in an EU org). But, fulfilling a DSR across multiple orgs is challenging without a federated search capability, which typically requires custom development or third-party tools.

• Duplicate management: Industry experts highlight duplicates as a major compliance risk. For example, if multiple records for a customer exist, each may have different retention policies, leading to multiple potential compliance failures.

• Hidden PII in custom fields: Customization debt can lead to hidden PII in custom fields (e.g., Project_Notes__c), which might bypass Privacy Center scans. This is a hidden compliance risk that could lead to regulatory issues if not addressed.

• Operational overhead: Managing compliance across multiple orgs brings added cost due to additional Shield licenses, user licenses, and training.

�ұ𲹰������’s layered modules solve these challenges by maintaining a core compliance configuration across all orgs, with flexibility for regional variations. You can deploy shared metadata, policies, and compliance settings to every environment in one controlled process — no manual reconfiguration or risk of drift.

This unified approach ensures consistent compliance while letting regional teams adapt to local regulations. And because 91�Թ��� automates multi-org deployments and compliance checks, you eliminate the duplication and overhead that typically come with managing separate Salesforce environments.

Building automated compliance processes with 91�Թ���

With 91�Թ���, you can automate compliance processes and integrate them seamlessly into your DevOps pipeline — here’s how:

Testing compliance changes without breaking production

One of the main challenges of compliance is testing new configurations without risking disruptions in production. 91�Թ��� solves this with sandbox seeding, allowing you to populate test environments with production-like data while maintaining compliance. By using data masking, you can replace sensitive fields, like phone numbers and email addresses, with realistic but obfuscated data, ensuring no PII is exposed during testing.

Also, �ұ𲹰������’s comparison tool helps you deploy encryption configuration changes with confidence. It allows you to compare your sandbox and production environments, highlighting exact changes and flagging potential issues before they make it to production, ensuring critical business processes remain unaffected.

Creating continuous compliance validation

The most reliable way to manage compliance is to make it continuous — validating changes throughout the whole DevOps lifecycle and catching any errors before they reach production. 91�Թ��� automates these checks in your pipeline, so compliance becomes part of every release, not a separate audit task.

Here’s why 91�Թ��� should be your go-to solution for this:

• Quality gates in your pipeline: With 91�Թ���, you can create automated that validate every deployment against your compliance rules, like checking for correct field classifications, required security settings, and data retention policies. These gates run automatically when developers create pull requests (PRs), blocking non-compliant changes from merging into protected branches or deploying to production. By enforcing compliance directly in your release process, 91�Թ��� reduces manual oversight and ensures every change meets your organization’s standards.

• Change monitoring: �ұ𲹰������’s change monitoring automatically tracks every metadata change across your Salesforce orgs — whether from deployments, manual edits, or third-party integrations. You’ll receive daily reports and configurable alerts whenever changes occur, so you can spot potential compliance risks early. And if something unexpected happens, 91�Թ��� lets you roll back unwanted changes or redeploy approved ones to restore consistency. These monitoring jobs also create a detailed audit trail that supports compliance reviews and regulatory reporting.

• Backup: �ұ𲹰������’s backup solution supports configurable retention periods aligned with your regulatory needs. Whether you need to maintain backups for seven years for SOX compliance or six years for HIPAA, 91�Թ��� ensures that your data is securely stored, with full audit logs of any deletions made from backup history. This guarantees that your organization can meet right-to-erasure requirements, an essential part of compliance.

• Deployment templates: With templates for security settings, field classifications, and retention policies, 91�Թ��� allows you to standardize compliance no matter how many orgs you manage.

The data governance culture shift

Achieving consistent compliance across your Salesforce environment means fostering a data governance culture that prioritizes data quality and compliance at every level of your organization.

Here’s how successful Salesforce implementations embrace a mindset shift that drives compliance from within:

• “If it’s not in Salesforce, it doesn’t exist”: This mindset is a core best practice that drives successful Salesforce compliance. This principle is pivotal for ensuring that your organization’s data is properly governed and compliant. If data ������’t stored in Salesforce, it cannot be effectively tracked, deleted, or protected — leaving it open to gaps in governance and compliance.

• Assigning data stewards across departments: To create lasting change, it’s important to assign data stewards across departments rather than relying solely on system admins to manage data quality. For example, sales teams should be responsible for the quality of opportunity data, while marketing teams own the integrity of campaign data. Each department is directly responsible for the accuracy and governance of its own data, ensuring that it meets compliance standards from the ground up.

• From IT project to business imperative: For compliance to truly succeed, it needs executive buy-in. When leadership understands that compliance is about protecting business value — not just avoiding regulatory fines — it transforms from a “nice-to-have” IT project into a business imperative.

• The ROI beyond risk mitigation: While compliance is often seen as a means of risk mitigation, the Return on Investment (ROI) extends far beyond simply avoiding penalties. Clean data enhances Agentforce accuracy, enabling your Salesforce org to deliver smarter insights and reliable agents. With faster DSR responses, you build greater customer trust, proving that your organization takes privacy seriously.

By automating compliance processes, you free up valuable staff time, enabling teams to focus on value-adding work rather than manual audits or data entry. This shift toward automation not only reduces the burden on employees but also improves overall operational efficiency, creating a virtuous cycle that benefits both compliance and business performance.

91�Թ���: Enterprise compliance, without compromise

91�Թ��� integrates seamlessly with the compliance and security frameworks your organization already relies on — rather than forcing you to adopt separate audit systems or duplicate processes. �ұ𲹰������’s Role-Based Access Control, granular permissions, and audit-ready logging are built into every part of the platform, from CI/CD pipelines to data backup and recovery.

Unlike other DevOps platforms that add their own gated compliance layer, �ұ𲹰������’s enterprise-level DevOps solution works with your existing governance workflows — including branch protection rules, approval gates, and change tracking in tools like GitHub, GitLab, or Bitbucket. Your DevOps and InfoSec teams maintain complete visibility and control, while 91�Թ��� reinforces compliance across every environment and release.

The result is continuous enterprise compliance — aligned with your organization’s security standards, verifiable through evidence, and ready for audit at any time.

Build compliance confidence with 91�Թ���

The shift from reactive scrambling to proactive compliance happens when you stop relying on piecemeal configurations and start engineering your evidence pipeline.

����������ڴǰ�����’s native capabilities provide a strong foundation, but there’s a critical gap between what Salesforce offers out of the box and the evidence regulators, partners, or internal auditors expect if questions are raised. 91�Թ��� bridges that gap with purpose-built solutions for long-term change histories, automated DSR fulfillment, compliant sandbox seeding, and unified multi-org governance. These tools mean your team no longer has to manually assemble compliance proof — you always have the documentation ready when it’s needed.

With 91�Թ���, you can ensure that every change is tracked, every piece of evidence is ready, and every action is in line with your regulatory obligations. Instead of waiting for an investigation or compliance request to spark a scramble, you can demonstrate a systematic approach to data protection and governance at any moment.

Not to mention, the next frontier — AI compliance for Agentforce — will require the same evidence-first mindset. Documenting training data sources, maintaining consent for AI processing, and proving data boundaries will be just as crucial as managing compliance for traditional data storage. Organizations that build compliance into their development pipeline today are positioning themselves to easily adapt to tomorrow’s regulations.

Ready for enterprise-grade Salesforce compliance?

Ready to transform your Salesforce compliance from reactive configuration to demonstrable evidence? Start your to experience how �ұ𲹰������’s automated compliance validation works in your org.

Or book a demo with our team to discuss your specific compliance challenges and see 91�Թ��� in action.

In this guide, we’ll show you how to build a practical governance framework using the four pillars of data governance. You’ll learn how to put validation rules and duplicate management in place for quick, visible wins; establish clear ownership with permission sets and roles people actually follow; and build audit trails and monitoring that stop problems before they derail your pipeline.

We’ll show you where ����������ڴǰ�����’s native tools work well, where they fall short, and how DevOps platforms like 91�Թ��� turn governance from a manual headache into an automated advantage. By the end, you’ll have a focused roadmap that transforms today’s data chaos into tomorrow’s competitive edge.

Building your foundation with the four pillars of data governance

Salesforce data governance rests on four core pillars:

• Data quality: Ensures information is accurate, consistent, and trustworthy, so teams can make decisions with confidence. In Salesforce, this might involve using validation rules to stop errors at entry, managing duplicates, and standardizing values with global picklists.

• Data stewardship: Puts clear ownership in place so there’s accountability for keeping data accurate and useful. For example, Sales Ops might be responsible for Opportunities while Marketing oversees Campaigns.

• Data management: Covers the processes and routines that keep data reliable day to day. Audit trails, automation, and scheduled checks all help maintain order and prevent issues from piling up.

• Data protection/compliance: Safeguards sensitive information and keeps your org aligned with regulations. Features like field-level security, Shield encryption, and role-based sharing rules protect customer trust while meeting compliance requirements.

Together, these four pillars form the framework that turns data disorder into disciplined control.

Executive buy-in: Your non-negotiable starting point

Governance falls flat without executive sponsorship. The real blocker ������’t budget — it’s having the authority to enforce standards across departments. Without leadership backing, rules get ignored, duplicate records creep back in, and compliance risks quietly pile up.

It’s important to position governance as disaster prevention, not just another process. Executives don’t need another slide deck about “data quality.” They want proof that governance is going to avoid real loss:

• Audit readiness strengthened: Field-level security and audit trails prove compliance and provide a clear record of accountability, reducing the risk of fines and failed audits.

• Trust protected: Validation rules and data checks ensure decisions are based on reliable information, keeping forecasts accurate and board confidence intact.

• Decisions safeguarded: Duplicate management and clear ownership stop pipeline inflation and commission disputes before they undermine credibility or morale.

• Compliance breach risk reduced: Access controls, encryption, and sharing rules can help prevent sensitive data from being exposed, maintaining customer trust and regulatory peace of mind.

Bringing concrete examples to the table can often make the difference. Show how one duplicate rule stopped dozens of duplicate opportunities, saving hours of reconciliation. Demonstrate how a single access control change eliminated the risk of a compliance fine. These are measurable avoided losses that speak the language of executives and unlock the authority you need to embed governance across your org.

Pillar 1: Data quality – building a foundation of trust

Pillar one focuses on the fundamentals: clean, reliable data. Strong data quality practices give your business a single source of truth — one that your teams can trust for accurate reporting, forecasting, and decision-making.

Start with duplication management

Duplicate records distort your customer view, inflate pipeline numbers, and reduce the accuracy of AI features like Agentforce — which can end up pulling back duplicate or incorrect information. Cleaning them up sharpens insights and creates instant value.

Configure around your business model: exact name matches for B2B, email for B2C, or “fuzzy matching” for more complex setups.

Some teams take a tiered approach, such as:

• Blocking clear duplicates automatically when confidence is high
• Flagging potential matches for manual review when similarity is moderate
• Running periodic checks or automated jobs to identify duplicates that may have slipped through real-time validation

This ������’t a one-size-fits-all setup — the right configuration depends on your data quality standards and tolerance for duplicate risk.

Building validation rules that work

Begin with fields that directly disrupt reports — Opportunity Close Date, Amount, Stage. Prioritize these first so users quickly see the benefit. Add rules gradually to avoid pushback:

• Phase 1: Require critical fields
• Phase 2: Enforce correct formats (dates, currency, picklists)
• Phase 3: Apply business logic (Close Date > Today, Amount > 0)

Provide bypasses for edge cases via permission sets, giving admins flexibility without undermining governance. And always explain the reason in the error message:

“Close Date must be in the future because historical opportunities break forecasting.”

Clarity like this helps your team know why the validation rule has been enforced and turns rules from red tape into real business protection.

Pillar 2: Data stewardship – assigning clear ownership

Even the best validation rules fail without clear accountability. Data stewardship defines who’s responsible for maintaining accuracy and consistency, turning governance from an abstract concept into a daily habit across your organization.

Building your ownership structure with clear responsibilities

A RACI matrix keeps governance roles unambiguous: Responsible (does the work), Accountable (owns the outcome), Consulted (provides input), and Informed (kept updated).

Here’s how it works in practice:

• Governance Council: Accountable for strategic goals and cross-department alignment
• Data Owners: Responsible for setting standards and business rules for their objects
• Data Stewards: Handle daily maintenance, track quality metrics, and resolve issues

It’s good practice to align these roles with Salesforce permissions from the start — Data Stewards need Modify All Data for their objects, Data Owners need access to dashboards on their domain’s health, and the Governance Council should be receiving executive-level reports.

Establish a simple weekly rhythm to keep governance active and accountable. A 15-minute Monday check-in gives Stewards space to share metrics and agree on priorities for the week. This consistent touchpoint turns ownership into accountability and keeps responsibilities clear when data issues arise.

Pillar 3: Data protection & compliance – securing your most valuable asset

As your Salesforce org grows, so does the volume of sensitive information it holds. Data protection ensures that security and compliance aren’t afterthoughts but integral parts of how you store, share, and manage data.

Security layers that scale with your growth

Build your security model in three layers:

• Object-Level Security: Decides which objects users can access at all
• Field-Level Security: Restricts sensitive fields like SSN or salary to the right profiles
• Record-Level Security: Controls record visibility through Organization-Wide Defaults (OWDs), roles, and sharing rules

Apply the principle of least privilege — set restrictive OWDs as the baseline, then expand access with permission sets as responsibilities grow. This keeps data safe without slowing down users.

Make quarterly reviews part of your security routine:

• Export LoginHistory to remove dormant users with access
• Check SetupAuditTrail for unapproved configuration changes
• Run User Access reports to confirm permissions match current roles

Use for real-time protection that stops breaches instantly. Block exports over 1,000 records to help prevent data theft, stop mass transfers that could corrupt your org, and flag unusual access patterns that could mean a compromised account. These automated controls run 24/7, guarding your data even when no one’s looking — but even the best prevention can’t stop every mistake. That’s why a reliable backup and recovery plan is also essential.

Pillar 4: Data management – operating and improving your Salesforce environment

Governance doesn’t stop once controls are in place. Data management is about sustaining those standards — monitoring changes, auditing activity, and refining processes so your data stays accurate, compliant, and actionable over time.

Auditing and lifecycle management

Enable Field History Tracking on up to 20 key compliance fields per object to create a persistent log of who changed what and when. Switch on Setup Audit Trail to capture key configuration changes, such as modifications to objects, fields, and security settings, so there’s always a clear record of who changed what and when.

Establish retention policies that balance compliance, performance, and cost. Define how long data must be stored to satisfy legal and industry obligations, then archive older records to reduce storage costs, and schedule routine purges for information that’s no longer needed. This approach keeps your org lean, compliant, and cost-efficient without compromising access to critical historical data.

How Salesforce native solutions handle governance

Salesforce provides native capabilities across each governance phase, but their strengths and limits differ as your org matures.

• Data stewardship: Roles establish data visibility, while permission sets control user access. As your org scales, managing hundreds of permissions and object-level settings across many users can quickly become complex and time-consuming.

• Data quality: Validation rules and duplicate management protect inputs, yet they’re reactive by nature. Too many strict rules, and users quickly find workarounds.

• Data management: Flows and scheduled Apex handle routine automation, but native tools lack advanced options like fuzzy matching or large-scale processing. Additionally, each org operates independently, so companies with multiple sandboxes, production orgs, or acquisitions struggle to align rules and policies without external help.

• Data protection and compliance: Field-Level Security, Shield encryption, and offer strong starting points. Still, when regulations overlap GDPR, , HIPAA or parent-child data needs handling, these native controls show their limits.

����������ڴǰ�����’s and provide valuable visibility into configuration and user activity. But, Setup Audit Trail data is retained for 180 days, and Event Monitoring logs only up to 30 days by default — enough for short-term troubleshooting, but not sufficient for organizations that require multi-year retention or long-term compliance evidence.

In practice, native Salesforce solutions give you the building blocks for governance. They’re effective for foundational enforcement — blocking duplicates, securing sensitive fields, assigning ownership — but when you need scale, cross-org consistency, or deeper compliance automation, you quickly encounter their boundaries. That’s the point where teams start looking for purpose-built solutions like 91�Թ��� to operationalize governance.

How 91�Թ��� powers enterprise-grade data governance in Salesforce

Native Salesforce tools provide a solid foundation, but scaling governance across multiple environments, teams, and compliance frameworks takes more than what’s built in. 91�Թ��� gives more than 3,500 teams complete visibility and control of their orgs through powerful CI/CD, monitoring, secure backups, and automated compliance.

Automating data stewardship at scale

Version control turns governance rules into an auditable system of record. Every validation rule, duplicate rule, and security setting is tracked in Git, with the full context of who changed what and why. So when an auditor asks, “Why was this field made optional?” you can show the complete picture — the ticket number, the business rationale, and the approval chain.

Our CI/CD pipelines solution ensures your governance rules deploy consistently across environments. No more finding out that the validation rule blocking bad emails worked in the sandbox but somehow never made it to production.

Quality gates catch issues before they reach users, while comparison views highlight any differences between environments ahead of deployment. This level of visibility prevents environments from drifting so far apart that deployments feel like guesswork.

Enhancing data management

Continuous monitoring works as your round-the-clock safeguard. If someone disables a key validation rule in production — maybe just for a “quick data load” — 91�Թ��� will flag it. That way, you stop problems before poor data seeps into your org, rather than uncovering it months later.

Sandbox seeding with data masking solves one of the biggest testing challenges: validating rules and workflows with production-like data while staying compliant with privacy regulations. With 91�Թ���, you can seed up to 100,000 masked records in a single deployment, retaining field relationships and dependencies while obscuring personal details. That means you can test against realistic datasets — without breaching governance or triggering a lengthy compliance review.

Automated synchronization ensures that duplicate rules and masking configurations stay consistent across every sandbox, eliminating the drift that weakens security frameworks over time. Update a rule once, and 91�Թ��� will push it everywhere automatically. Behind the scenes, �ұ𲹰������’s intelligent deployment engine maps ����������ڴǰ�����’s �貹����Գ�–c�󾱱��� data relationships, so your records land in the right order and avoid cascading errors.

With in-place masking and seamless sandbox seeding, your teams get the confidence of testing with production-quality data — without the risk of exposing sensitive information.

Proving ROI with complete visibility

Detailed audit trails capture every change with exact precision — who deployed it, when it happened, which Jira ticket justified it, and what testing was done. This goes far beyond ticking a compliance box; it’s the evidence that shows governance actively drives value.

Daily automated backups give your framework the safety net it needs. If 10,000 account records are deleted or a critical validation rule is corrupted, point-in-time recovery restores them in minutes — unlike native weekly exports, which risk losing nearly a week of data.

Compliance automation makes GDPR requests routine instead of reactive. Right-to-erasure jobs run automatically across all objects, complete with audit trails. You can demonstrate compliance with automated reports instead of last-minute spreadsheets.

Scalable performance ensures governance never slows you down. You can handle millions of records without impacting users: duplicate checks run quietly in the background, validation rules fire instantly, and audit trails capture everything without delay.

Making governance sustainable with DevOps

Rollback capability shifts the risk equation. If a validation rule update breaks an integration, you can instantly restore the prior configuration instead of rushing a fix under pressure. This safety net makes it easier to refine controls — you can improve continuously, knowing reversals take minutes.

Regional data processing solves sovereignty requirements cleanly. Decide whether data is processed in the US, Canada, EU, or Australia, so compliance adapts seamlessly to local regulations without slowing down delivery or demanding workarounds.

And while compliance and data sovereignty keep your governance framework secure, collaboration turns it into a shared effort. Instead of clunky spreadsheets, teams work through clear, Git-based workflows: admins propose changes via pull requests, developers review the impact, and business stakeholders approve using familiar tools.

Because 91�Թ��� is built for Salesforce, it understands exactly how rules, workflows, permissions, and duplicates interact.

The result? Governance shifts from a manual chore everyone avoids to an automated advantage that safeguards your business while speeding up delivery. With each deployment, your framework grows stronger — rather than being worn down by technical debt.

91�Թ���: Enterprise governance, without lock-in

91�Թ��� seamlessly integrates with the enterprise governance controls your organization already relies on — rather than forcing you to adopt new or external processes. The platform’s built-in , app permissions, and audit-ready security controls extend across everything from CI/CD pipelines to data management.

Unlike other DevOps platforms, which depend on their own gated governance layer, �ұ𲹰������’s enterprise-level DevOps solution works natively with your existing enterprise governance frameworks — including branch protection rules, code review policies, and approval workflows in GitHub, GitLab, or Bitbucket. That means your DevOps and InfoSec teams keep full visibility and control, while 91�Թ��� strengthens compliance across every deployment.

The result is true enterprise governance — aligned with and enhancing your organization’s standards, not restricted by someone else’s platform.

Automating Salesforce data governance with 91�Թ���

You’ve set up the right foundations for data governance with validation rules, duplicate management, and security controls — but keeping them consistent across environments without risking production can be a constant headache. This is often where teams implementing governance frameworks stumble.

91�Թ��� takes that weight off your shoulders and turns governance into a true advantage with version-controlled deployments, continuous monitoring, and full audit trails. Every validation rule you build, every permission set you adjust, and every duplicate rule you refine are all tracked, tested, and deployed with confidence.

Native tools might have helped you get started, but as your org scales from thousands to millions of records, 91�Թ��� keeps you moving forward without compromise.

Want to see 91�Թ��� in action? Start a and experience automated governance deployment and monitoring firsthand. Watch validation rules roll out cleanly across environments while you keep airtight audit trails for compliance. Prefer a tailored conversation? Book a demo of 91�Թ��� today.

In this post, we’ll take a closer look at how to create a roll-up summary field in Salesforce and how 91�Թ��� can help you avoid the common pitfalls when moving them between Salesforce environments.

What is a roll-up summary field?

A lives on a master object and calculates values from its detail records related through a master–detail relationship — think of it as a �貹����Գ�–c�󾱱��� setup, where the master is the parent and the detail is the child. When you set up a roll-up summary field, you select the field to aggregate on those detail records, and Salesforce will perform calculations using the supported roll-up types: COUNT, SUM, MIN, or MAX, and surface the result on the master record. They’re useful for scenarios like totaling invoice amounts, counting active contracts, or finding the earliest delivery date. For example, on an Account record, you’ll see “Total Opportunity Amount” as the sum of all related Opportunities.

Other common examples of roll-up summary fields include:

• A custom account field that counts the number of open cases linked to the account
• A custom project field that sums the total hours logged across related tasks
• A custom opportunity field that shows the maximum value across all related quotes
• A custom contact or household field that adds up all related donation amounts

Limitations of roll-up summary fields

Roll-up summary fields do come with some restrictions. The main one is that they only work on directly related records in a master–detail relationship one level deep. That means you can only roll up from the child side of a master–detail relationship to its direct parent and you can’t skip a level to roll up from a grandchild. And if your objects are connected by a lookup relationship, roll-ups also aren’t available.

Here are some other limitations to watch out for:

• Calculation types: The supported operations are limited to COUNT, SUM, MIN, and MAX. Other operations that might be useful, such as averages, text concatenation, or statistical measures like mode, aren’t supported.
• Field limits: Each object can have up to 25 roll-up summary fields by default, with the option to request an increase to a maximum of 40. Any more than this and you’d risk slowing down your org.
• Filtering restrictions: You can’t filter roll-ups on every field type. Unsupported fields include long text areas, multi-select picklists, description fields, system fields like Last Activity, cross-object formulas, and lookups. Date literal filters (like next year or last 90 days) aren’t supported either — these are just too complex for roll-up logic.
• Maintenance and performance impact: Roll-up summary fields usually recalculate automatically when child records change. An exception is campaign roll-ups, which don’t update if a lead or contact is deleted. In this case, you’ll need to manually select the option on the edit page of the roll-up summary field. Roll-ups can also add overhead to record saves and bulk operations, so using too many can affect org performance.
• Formula, currency, and percent fields: Formula fields that reference cross-object formulas and automatically derived fields such as Current Date or Current User can’t be rolled up. And if your org has enabled, some roll-ups, such as from opportunities to accounts, won’t work at all. But percent fields are supported, which means you can roll up values like probability percentages or completion rates without issue.

How to create a roll-up summary field in Salesforce

Roll-up summary fields are native Salesforce metadata. To implement a roll-up summary field, go to Setup and open Object Manager. Select the parent object (for example, Account). Under Fields & Relationships, click New. Choose Roll-Up Summary as the field type. Define the field label, select the summarized object (this is the detail object, or child, that you want to summarize), choose your field to aggregate option and summary type (COUNT, SUM, MIN, or MAX), and add any filter criteria. Save the field and add it to the page layout. You’ll now see the new field on the master side of the relationship, ready to display the aggregated values.

Alternatives to implementing a roll-up summary field

If you need roll-ups outside of master-detail relationships or with more advanced logic to get around some of the limitations listed above, there are a few ways you can mimic the behavior of roll-up summary fields with other tools. These approaches don’t create a true record roll-up summary field, instead they use automation or code to update a regular field with a calculated value.

AppExchange apps

For more flexibility, some teams turn to tools from the AppExchange. (DLRS) and are popular options, extending roll-up functionality to lookup relationships, adding new calculation types, and offering scheduling features. These tools can be useful for admins who want more functionality than Salesforce provides out of the box but without writing code. Because they rely on custom metadata, triggers, and jobs, if you use this option you’ll need to deploy any supporting components carefully and sometimes reconfigure scheduled jobs in the target org.

Flows

Salesforce Flow now makes it possible to , even across objects joined by lookup relationships. With record-triggered or schedule-triggered Flows, you can do calculations like Count, Sum, Min, Max, Average, First, and Last. For example, you could schedule a Flow to count all Asset records linked to an Account, and update a number field on the Account each morning. Flows give you flexibility without code, but you will need to design them carefully to avoid hitting governor limits or performance bottlenecks.

Apex triggers

For the most control, you can use Apex triggers. These allow developers to build custom roll-ups on almost any relationship, and handle more advanced scenarios like distinct counts or grandchild (multi-level) roll-ups. Apex can run on record creation, update, or deletion, but it comes with the overhead of writing, testing, and maintaining code, as well as carefully managing governor limits.

Reporting

In some situations, you don’t need a roll-up field at all. Reports and dashboards can provide aggregated views without adding fields or automation. The trade-off is that the value ������’t written back to the record, so it can’t be used in automation or list views. But if all you need is visibility, reporting might be the simplest option.

Best practices for roll-up summary fields

Roll-up summary fields might look simple, but they can have a big impact on your data model and org performance. Build them haphazardly, and you’ll soon run into limits, errors, or fields that no one actually uses. Build them well, and they’ll give your users instant insights without slowing anything down.

Here’s how to make sure you’re on the right track:

Plan before you build

Once a roll-up summary field is created, , and you can’t delete any fields used in its definition, so you need to plan them carefully.

Secure sensitive values

If a roll-up summary field calculates values that shouldn’t be visible to every user — like total deal value or contract amounts — apply field-level security so that only the right users can view or report on the field.

Test in a safe environment

Always test roll-up summary fields in a sandbox or development environment before deploying to production. This gives you a chance to check that the roll-up behaves as expected, without risking errors or performance issues in your live org.

Keep an eye on performance

Roll-up summary fields are usually recalculated automatically by Salesforce whenever child records change, which is part of what makes them so useful. But if you create too many, they can slow down your org, particularly on record saves. Limit the number you use, and only implement roll-ups that deliver real value.

Review regularly

Business processes change, and so do reporting needs. Review your roll-up summary fields on a regular basis to make sure they’re still useful, accurate, and secure — especially if the detail records related to the master object change as your data model evolves. Retiring unused roll-ups can free up space and improve system performance.

Common deployment error messages and how to overcome them

Every roll-up summary field comes with dependencies — the master–detail relationship, the child field being summarized, and any filter fields you’ve added. If those pieces aren’t present in the target org, or if permissions or limits get in the way, deployments can fail.

Here are six of the most common error messages you’ll see, along with tips for resolving them:

• Field {fieldName} does not exist or is not accessible on the related object: the summarized field on the child object is missing or hidden. Make sure it exists in the target org and is included in your deployment package, and confirm field-level security is set correctly. If you’re using 91�Թ���, dependency analysis automatically detects when related fields are missing and suggests adding them to your deployment package, so you won’t get blocked by this error.
• Roll-up summary fields can only be created on master-detail relationships: you’ll see this if you try to build or deploy a roll-up on a lookup relationship. To replicate roll-ups on lookups, you’ll need Flow, Apex, or an AppExchange tool.
• Insufficient privileges to deploy metadata: the deploying user doesn’t have enough permissions (e.g., Modify All Data or Author Apex). You’ll need to use an integration user with full deployment permissions.
• FIELD_CUSTOM_VALIDATION_EXCEPTION, Opportunity must have a Close Date: []: this happens when a validation rule blocks a record update during deployment (in this case, a validation rule requires a close date). Add an exception for your deployment user, or temporarily adjust the rule.
• Too many SOQL queries: 101 or Apex CPU Time Limit Exceeded: these come up when tests run as part of deployment and hit governor limits, often due to triggers or Flows firing on recalculation. Optimize your automation, bulkify Apex, or adjust test data.
• Exceeded maximum number of roll-up summary fields: each object can have 25 roll-up summary fields by default (up to 40 on request). If you’ve reached the limit, you’ll need to retire unused fields or consolidate. Remember the more you have, the more chance you have of seeing a lag on your org’s performance.

How to deploy a roll-up summary field

A roll-up summary field is just a Custom Field on the parent object, so you deploy it like any other metadata — but some methods are simpler than others.

Deploying with change sets

Change sets are one of ����������ڴǰ�����’s native deployment tools, but deploying roll-up summary fields this way can be tricky because of their dependencies.

A roll-up summary field depends on two key things:

• The summarized field it’s rolling up on the child object
• The master–detail relationship field that ties the child object back to the parent

If either of these dependencies is missing from your deployment package, the deployment will fail. This often leads to time-consuming trial and error as you gradually add the missing pieces until the change set validates.

To deploy a roll-up summary field with change sets:

1. In your source org, create an outbound change set. Go to Setup > Outbound Change Sets > New.
2. Give the change set a name and description and select Add under Change Set Components.
3. Choose Custom Field and add the roll-up summary field from the parent object’s metadata.
4. Make sure you include the summarized field and the master–detail field it depends on, along with any other fields used in filter criteria.
5. Click Upload to select the environment you want to deploy to.
6. To receive the inbound changes in your target org you’ll need to select Environments > Change Sets > Inbound Change Sets. You’ll find your change set will be listed under Change Sets Awaiting Deployment.
7. Click Deploy, select a testing option then press Deploy again to start the migration.
8. Check your deployment status on the Deployment status page in Deployment settings.
9. If you see errors like “In field: summarizedField – no CustomField named {fieldName} found” or “Component is not present in target org”, it means a dependency is missing. Add the missing field, relationship, or object to your change set and re-upload until validation passes.

Deploying with 91�Թ���

91�Թ��� streamlines the process of deploying your summary fields by automatically comparing the metadata in your orgs, detecting dependencies, and letting you know when an object with a roll-up summary field has a dependency on another object (the one you’re rolling up).

To deploy a roll-up summary field:

1. Select your source and target orgs

In Compare and deploy, connect your source and target orgs and click Compare now.

2. Filter and select your metadata

Use the metadata filter down the left-hand side to choose the metadata types you want to compare. In the comparison diff, find and select the roll-up summary field and the dependencies you want to deploy. 91�Թ��� will help by highlighting related dependencies so you don’t miss anything.

Once you’ve selected your changes, click Next to build your deployment package.

3. Run the problem analyzers

91�Թ��� automatically runs pre-deployment checks to catch common issues that might cause your deployment to fail. In this case, it’s identified that the new roll-up summary field has entries in existing profiles and permission sets that aren’t included in the deployment.

91�Թ��� highlights any issues and suggests an autofix — giving you the option to deploy those new entries into the relevant profiles and permission sets to keep everything up to date.

4. Deploy your changes

Click Next to finalize your deployment package. You can add deployment notes, assign user stories, and run pre-deployment validation checks.

When you’re ready, click Deploy. 91�Թ��� will apply the changes and give you a detailed deployment summary.

91�Թ��� handles dependencies that often trip up change sets, gives you detailed deployment logs, and makes roll-back easy if you need it. For teams working with lots of roll-ups (and other metadata), it can save time and frustration.

Deploy complex changes with confidence

One of the biggest challenges with deploying roll-up summary fields is understanding their hidden dependencies. Without that insight, deployments can feel like guesswork. The more visibility you have into how your metadata fits together, the more confident you can be that your deployment will succeed the first time.

91�Թ��� surfaces the relationships between your metadata, so you can spot dependencies before they cause failures. With that clarity, every release feels more controlled and predictable.

If you want to deploy roll-up summary fields — and all their dependencies — with ease, start a of 91�Թ��� today. There’s nothing to install in your orgs, and you’ll quickly see how much simpler and safer deployments can be. Or, if you’d prefer a guided tour, book a demo of 91�Թ��� today.

This post covers the fundamentals of Salesforce data governance, why so many orgs struggle to get it right, and how to build a practical approach that scales with your business and keeps your data ready for AI.

What is Salesforce data governance?

Data governance provides the structures and controls needed to manage data quality, consistency, and security at every stage of its lifecycle.

At its heart, governance sets the rules across five key areas:

• Access – Who can see or change what
• Accuracy – What qualifies as clean, usable data
• Privacy – How sensitive data is handled
• Security – Controlling access to your org and data
• Retention – How long data stays and when it goes

Salesforce data governance is about the policies, processes, and controls that keep your organization’s data accurate, trustworthy, and secure from start to finish. If data management is the team laying the bricks, governance is the blueprint guiding what’s built, how, and why.

What makes Salesforce data governance different is that it’s integrated into the platform. You’re not relying on external database rules. Instead, you’re using native tools like profiles, roles, validation rules, and workflows to enforce policies.

These span four layers of control:

• Organization level – Broad settings that apply across your instance
• Object level – Who can access entire objects, like Leads or Opportunities
• Field level – Controls over which fields are visible or editable
• Record level – Granular access to individual records via roles and sharing rules

One thing worth noting is that governance ������’t the same as (MDM). Master Data Management is a set of policies, processes, and technologies for consolidating data into a single, accurate source. Governance is the framework that keeps the data high-quality and compliant every step of the way. The aim is to make solid data habits part of everyday work.

What are the biggest challenges in Salesforce data governance?

Getting data governance right in Salesforce ������’t as simple as ticking boxes on a checklist. It means wrestling with technical limits, org-wide ambiguity, and human friction.

There are seven pain points that trip teams up most often:

Scale and complexity

The bigger your Salesforce org gets, the harder it becomes to maintain clear oversight. What starts off tidy soon spirals — objects multiply, relationships get tangled, and suddenly the old ways of managing data no longer work.

Ownership ambiguity

Here’s where a lot of orgs stall: no one’s quite sure who’s responsible for what. Without a clear line between data owners (who set the direction) and stewards (who manage the day-to-day), decisions get delayed — or worse, missed entirely.

Trust deficit

When users lose trust in Salesforce data — for example, due to duplicate or conflicting records — they create their own workarounds. Spreadsheets, local copies, and siloed reports only drag data quality down further, feeding the cycle.

Integration challenges

Your customer data doesn’t live in one place. It’s spread across platforms — Salesforce, ERPs, marketing tools — all holding different versions of the same record. Data governance ensures those systems stay connected and reconciled, so your teams work from the same truth.

Technical demands of compliance

GDPR, CCPA, and other regulations demand features like audit trails, deletion workflows, and data access logs. If you’re a large business handling sensitive customer data, native Salesforce tools aren’t enough to manage compliance at scale without serious workarounds.

Permission complexity

Every new field, object, or integration adds complexity inside your org. What starts as a simple set of roles and rules can quickly turn into an unmanageable tangle of profiles, permission sets, and exceptions.

Analysis paralysis

Most teams know they need better governance. The sticking point is understanding where to start. Data quality? Security? Org structure? That uncertainty slows everything down, and lets avoidable issues pile up.

Why do you need a data governance plan for your Salesforce instance?

Having a solid Salesforce data governance plan is a business-critical move that touches everything from your bottom line to your team’s daily workflow. Here’s why it needs to be on your radar.

The financial impact is measurable

Poor data quality drains a year from companies through wasted effort, missed chances, and clunky operations. And that figure only snowballs as your business grows.

Think of the 1-10-100 rule:

• It costs $1 to prevent a data issue up front.
• It costs $10 to fix that same issue later in the process.
• And if you ignore it until it causes downstream problems? The cost skyrockets to $100.

In other words, the longer you wait, the more it hurts. The teams that put governance in place early see stronger returns across the board.

Your AI and automation investments depend on clean data

With Agentforce and other AI tools becoming more popular, data quality matters more than ever. These tools are powerful, but they’re not magic.

The performance of Agentforce is directly tied to the quality of your CRM data. With accurate and organized information, it becomes a powerful tool that makes your teams more efficient. But if Agentforce is fed data that is outdated, duplicated, or simply wrong, it will confidently make mistakes. Because the AI doesn’t question the data it receives, these errors can disrupt your company’s operations and damage your reputation.

Compliance ������’t optional

While related, data governance focuses specifically on data policies and quality, whereas GRC (Governance, Risk, and Compliance) includes broader organizational risk management, including regulatory compliance, internal controls, and business continuity.

The risks of falling short of the required standards are significant:

• of your global revenue
• Territorial data protection laws like CCPA and are broadening their scope, extending beyond local residents to cover global businesses handling that data
• Highly regulated industries like finance and healthcare must comply with additional frameworks such as , , and
• Auditors expect detailed tracking and retention

Manual processes aren’t enough. Meeting today’s compliance standards means having end-to-end visibility and control over your data at all times.

Team productivity and user adoption

Without good governance, your team wastes hours second-guessing. Sales reps end up managing data instead of closing deals. Reports lose credibility. Meetings become data debates.

But when governance is in place, everything clicks:

• You know who owns which data and who’s responsible for quality
• Dashboards and reports actually help with decisions
• Adoption goes up because the system works
• And as trust grows, so does data quality

People input better data when they know it’ll be used and relied on, kickstarting a virtuous cycle that boosts productivity and builds a healthier Salesforce org over time.

How Salesforce native solutions handle governance

Salesforce comes with a solid toolkit for governance, but if you’re relying on it to scale with you, it’s worth knowing where those tools start to show their limits.

Core governance tools

����������ڴǰ�����’s built-in rules and automation — like validation rules and workflows — do a decent job of keeping data clean and consistent. They help set the ground rules. But they’re mostly reactive. That means they’ll flag a problem after it happens, not stop it at the door. And unless these rules and automations are designed with real care, they can trip up users and slow things down.

Security is handled through profiles and permission sets. It’s flexible and lets you fine-tune access, which works well up to a point. Start layering in custom objects, complicated relationships, and a growing user base, and suddenly your admin team is juggling overlapping permissions that are hard to untangle.

Data lifecycle management

Salesforce gives you a few native and add-on options for handling data over time:

• Salesforce does provide a built-in way to archive records, hiding them from everyday searches and reports. But those records are still sitting in your Salesforce storage, so your costs don’t actually shrink. By contrast, external archiving tools like 91�Թ��� genuinely move the data out — which means the subscription quickly pays for itself through reduced Salesforce storage bills.

• , ����������ڴǰ�����’s newer add-on, is pitched as a way to keep orgs lean by pushing older or less-active records out of production. The idea is to improve performance and cut clutter so only the data you really need stays live. It helps keep things tidier and more consistent, though you’re still working within ����������ڴǰ�����’s boundaries on how and when that archiving happens.

• steps in with GDPR features like auto-deletion, but as a paid add-on, it can be cost-prohibitive at scale, and the setup demands more configuration than most enterprise teams would expect from a compliance tool.

• Big Objects can handle large volumes of historical data, but they’re not practical for day-to-day enterprise reporting; there’s no standard UI, and extracting data often requires specialist skills that don’t scale easily across large teams.

As for backup, ����������ڴǰ�����’s native weekly exports may work for smaller orgs as a last resort, but for bigger teams or enterprises, the long gaps between snapshots and lack of granular restore options can pose a serious risk.

The enterprise gap

The native features cover the basics. But once you move into enterprise territory, they start to buckle. That’s why more complex orgs turn to 91�Թ��� — built to offer deeper automation, stronger controls, and the kind of scalability ����������ڴǰ�����’s native setup just ������’t built for.

How 91�Թ��� supports enterprise-grade Salesforce data governance

With 91�Թ���, data governance stops being a last-minute thought and starts feeling strategic. We’ll walk you through how we support the full governance process — minus the headaches.

Complete data protection and recovery infrastructure

Every admin knows the fear: one small misstep — like a misaligned Flow or a bulk update gone rogue — and thousands of records are gone or corrupted. �ұ𲹰������’s backup solution puts an end to that anxiety. Daily automated backups run quietly in the background, capturing both data and metadata.

You can also dial up the frequency for your most business-critical objects, so you’re never far from a usable restore point. But timing’s only half the story; accuracy matters just as much. Smart restore tools mean you can recover exactly what you need: one field, one object, no collateral damage.

Our change tracking catches unusual behavior — such as bulk deletions — before it snowballs. And because backups are stored independently on AWS, you don’t have to go through Salesforce to reach them — which means they’re still available even if your Salesforce org goes down. With point-in-time recovery, you’re not limited to your last scheduled backup either; you can roll back to the exact moment things went wrong.

Compliance automation that actually works

Manual compliance is both time-consuming and risky. 91�Թ��� handles the full compliance lifecycle automatically, from setting policies to enforcing them and proving it all happened.

You get customizable retention rules that fit how your business handles data, complete with automated scheduling and airtight audit documentation. Take GDPR’s right to erasure: what used to mean digging through records across systems is now just a query away. 91�Թ��� wipes the record from every backup while keeping the audit trail clean.

For dev teams, data masking replaces sensitive info with realistic dummy data so that testing stays fast, safe, and fully compliant. Every action is logged, timestamped, and attributed, giving auditors everything they need without you scrambling.

Scalable governance for multi-environment architectures

If you’re running multiple orgs across business units or regions, you already know how messy governance can get. �ұ𲹰������’s layered modules make it manageable. You can roll out standard governance policies across every org — covering things like security settings or retention rules — while still giving teams room to apply their own local tweaks, whether that’s for currency formats or specific regulatory needs for that region.

Automated sync makes sure changes don’t conflict: local updates won’t break global policies, and global changes don’t bulldoze regional setups. It’s scalable governance without the chaos.

DevOps integration for governance at scale

91�Թ��� brings to your governance setup, so configurations like validation rules and retention policies are version-controlled, reviewed, and deployed just like code. This stops the classic “it worked in sandbox” issue before it starts. CI/CD quality gates catch governance issues before they ship, and if something does slip through, automated rollbacks make it painless to recover.

Data quality and migration excellence

Data moves constantly, whether you’re deploying to a new sandbox or merging orgs, and governance has to move with it. �ұ𲹰������’s deployment engine understands the tangled web of Salesforce relationships, so it doesn’t stall on dependencies or corrupt your data mid-transfer.

Duplicate detection runs across environments and backups, keeping your data clean end to end. And when you seed sandboxes, the same governance rules apply right from the start, so your test data behaves just like it did in production. Built-in data lineage shows how information flows across your setup, making impact analysis precise instead of guesswork.

Purpose-built for Salesforce complexity

Some tools treat Salesforce like a generic database. That’s where they go wrong. �ұ𲹰������’s built with Salesforce in mind, from how metadata behaves to how your org evolves over time. We work within your security model, don’t bolt on extra layers, and stay up to date with every Salesforce release. Even if you’re dealing with millions of records, 91�Թ��� stays fast and responsive so that governance doesn’t get in the way of getting things done.

Transform your Salesforce data governance today

Good data governance is about consistent systems that quietly stop small problems from turning into big ones later. The difference between orgs that thrive and those stuck in firefighting mode is that they define smart policies and put automation in place to actually enforce them — across every environment, process, and team.

As your setup grows, you’ll start bumping into the ceiling of what ����������ڴǰ�����’s built-in tools can handle. At that point, platforms built specifically for backup, compliance, and deployment automation stop being “nice to have” and start becoming critical.

91�Թ��� turns governance from something that feels heavy and reactive into a smart, automated layer of protection that quietly does the hard work in the background, setting you up to scale confidently.

Curious what that actually looks like? to see what automated governance really feels like. Or, if you’d rather talk specifics, book a demo of 91�Թ��� today with our team — we’ll help you unpack exactly where 91�Թ��� can take the weight off your shoulders.

In ����������ڴǰ�����’s declarative environment, debt spans clicks as well as code — from suboptimal admin configurations that slow page loads to outdated automation patterns running in parallel with newer Flows. When deployment failures spike, governor limits hit their ceiling, or a simple field addition takes three days, you know debt has moved from an abstract concern to an operational crisis.

In this post, we’ll cover ����������ڴǰ�����’s native basics for identification and assessment and then show how �ұ𲹰������’s DevOps platform adds advanced detection, analysis, and remediation to turn technical debt into clear, actionable work.

Understanding the Technical Debt Ratio (TDR)

The (TDR) measures how much it would cost to fix existing issues compared to what you’ve spent building the system in the first place.

In Salesforce terms, that means comparing your estimated remediation cost (for bugs, inefficient code, or configuration fixes) against the total development cost of the same feature or project over a defined period — typically a release cycle or fiscal year. TDR = (Remediation Cost / Development Cost) × 100. So if your Salesforce org costs $500,000 to develop and resolving identified issues would cost $50,000, your TDR is 10%.

In practice, you’ll want to keep your TDR below 10%, with 5% being a strong indicator of healthy development practices. Anything above 20% is a warning sign that debt is dragging down delivery.

These thresholds aren’t arbitrary: a 23% TDR on your budget can mean $34,000 per quarter lost to avoidable rework — and that cost translates directly into developer hours where you could’ve been building new features instead of fixing old ones.

A typical example of remediation times could include:

• Simple field deletion: 5 minutes
• Flow refactoring: 4 hours
• Trigger rewrites: 2 days
• Major architectural changes: 40+ hours

This two-way translation is what makes TDR actionable. Dollar figures get executive attention and justify investment. But hour-based estimates make technical debt work backlog-ready. When you size technical debt work in hours — whether it’s a quick field deletion or a multi-day architectural change — those issues can slot into your backlog alongside features.

With a shared currency of developer time, your product owner can weigh “fix the governor limit warning” against “build new lead scoring,” turning the conversation from opinion to clear trade-offs.

Building your Technical Debt Registry

Once you’ve calculated your Technical Debt Ratio, the next step is to make that debt visible and actionable. That’s where a tech debt registry can help. Filling in these details can help you understand the impact to the business and where you should focus your efforts first:

• Issue description: Clear, specific problem statement
• Categories: For example, Apex / Flows and automation / Configuration / Integration / Security
• Business impact score: 1–5 scale
• Remediation hours: Estimated fix time
• Risk level: Critical/High/Medium/Low

This framework converts the findings from static code analysis, org health scans, and configuration checks into work items your team can pick up and resolve as part of their regular delivery cycle.

Score the business impact of an item of technical debt by asking three questions:

1. Does the issue affect user productivity?
2. Could this debt item cause data loss or security issues?
3. Will it block future development?

Rate 1–5 based on severity and user count. A broken automation disrupting lead assignments for 500 sales reps is a bigger deal than a page layout issue that only three admins ever see.

Turn the registry into quarterly budgets with: Total Remediation Hours × Average Developer Rate = Cleanup Investment. Then weigh this against the cost of doing nothing.

What are the native Salesforce options for measuring technical debt?

Salesforce does provide some built-in ways to surface tech debt in your orgs. , once the go-to tool for highlighting unused metadata and performance concerns, has now been retired. The main native option today is Salesforce Code Analyzer, which runs static analysis across Apex, Flows, and Lightning code to uncover quality, security, and performance issues. It’s powerful for spotting problems in both declarative and programmatic logic, but on its own it doesn’t provide a full picture of technical debt across the org.

tracks recent administrative modifications in your org. You can view the 20 most recent changes directly in the UI, and download up to 180 days of history via CSV. This delivers forensic visibility into who changed what and when, which is useful for accountability and debugging sudden issues. But, Setup Audit Trail stops short of giving you broader insight into data changes, component dependencies, actual usage patterns, or the business impact of those changes.

is ����������ڴǰ�����’s solution for scanning both programmatic and declarative code. Unlike Optimizer’s metadata-level checks, Analyzer inspects real code quality, security risks, and performance issues across Apex, Visualforce, Flow, and Lightning components.

, which is part of Code Analyzer, is especially relevant as organizations migrate from Process Builder to Flows. Flow Scanner reviews Flows for:

• Inefficient loops that hurt performance
• Poor error-handling practices
• Resource-heavy operations likely to hit limits
• Conflicting automation patterns

On its own, Code Analyzer tells you what’s wrong, not how to fix it. It flags issues but doesn’t provide the context or dependency analysis needed to act safely. Without a complete picture of how components connect, refactoring a “problematic” trigger might break managed packages or integrations — turning cleanup into a source of risk.

There’s a second limitation worth flagging for teams adopting AI tools: Code Analyzer, like the AI models generating your code, is operating from a fixed snapshot of Salesforce best practices and security guidance. Salesforce evolves constantly — new metadata types, updated well-architected principles, changes to security standards. When both your code generator and your scanner are working from yesterday’s data, issues introduced by AI can slip through undetected.

This leaves a gap between detection and action. While native capabilities serve their purpose for basic scanning, DevOps teams need to move from identifying problems to fixing them safely and efficiently. For teams managing technical debt at scale, 91�Թ��� bridges this gap by providing dependency analysis, remediation guidance, and automated fixes that turn detection into action.

Technical debt measurement, built into the DevOps lifecycle

Unlike ����������ڴǰ�����’s native tools, which stop at detection, 91�Թ��� is built to measure, prioritize, and manage technical debt across the entire DevOps lifecycle. Because it’s a complete DevOps platform, 91�Թ��� combines static code analysis, dependency mapping, remediation guidance, and automated fixes — turning abstract problems into structured, backlog-ready work.

With 91�Թ���, you’re not just collecting a list of issues; you’re measuring debt in the same currency as feature delivery: remediation hours, business impact, and team velocity. This makes it easier to quantify the cost of debt, justify investment, and track steady improvement over time.

Measuring debt with Code Reviews

�ұ𲹰������’s Code Reviews give you a structured way to measure technical debt across Apex, Flows, Lightning Web Components, Visualforce, and Aura. Each issue is classified by severity (critical, error, warning) and assigned an estimated remediation effort, so you can calculate the cost of debt in hours and prioritize accordingly.

The Remediation Chart makes this visible: issues are grouped by rules, plotted by severity and fix time, and surfaced in Git branch reviews or org assessments. That visualization helps teams quickly identify “quick win” fixes versus long-term remediation projects — a practical input into a Technical Debt Registry or Technical Debt Ratio calculation.

By pairing effort estimates with severity levels, Code Reviews turn abstract quality concerns into measurable debt items. You can slot them into your backlog alongside features, report on remediation hours, and track progress release by release.

Making technical debt visible with Org Intelligence

Measuring technical debt starts with visibility. You can’t calculate fixing costs or build a Technical Debt Registry if you don’t know what’s actually in your org, how it’s connected, or how hard it will be to change. ����������ڴǰ�����’s native tools surface some issues, but often stop short of providing the context you need to size and prioritize them. But �ұ𲹰������’s Org Intelligence can help.

Org Intelligence maps your org’s architecture, showing the entire metadata, dependencies, and permissions structure, so you can see exactly how fields, Flows, automations, and components connect. Instead of relying on partial checks, you get full impact analysis — complete with history of who made changes and when. That context makes it possible for any developer to be dropped into any org and have complete clarity on what exists and why. It also highlights unused fields, ghost code, and redundant automation, giving you a backlog of debt items to quantify.

Beyond surfacing debt, Org Intelligence helps share org knowledge. Insights are available to every team member, not locked into one or two experts. This spreads context, reduces “people debt,” and makes estimating and planning debt remediation a collaborative process rather than a bottleneck.

Alongside Org Intelligence sits the 91�Թ��� Agent, which can interpret org complexity in plain English. You can type prompts like “Why is this page running slow?” or “How do I automate this safely?” and get guided answers, with AI-generated cleanup suggestions. This blends human control with AI speed, turning technical debt from an opaque risk into clear, measurable work.

Move from detection to action with 91�Թ���

�ұ𲹰������’s enterprise DevOps platform bridges the gap between knowing you have technical debt and doing something about it. Where native Salesforce tools highlight problems, 91�Թ��� gives you the context, safeguards, and automation to fix them safely and sustainably. From Org Intelligence mapping out dependencies, to Code Reviews with autofix and quality gates, to safe deletions and instant rollbacks, 91�Թ��� turns cleanup into part of your delivery rhythm rather than a risky side project.

Start your , or book a personalized demo to see how to partner with 91�Թ��� to prevent new debt, remediate legacy issues with confidence, and build continuous quality into every release.

Here’s where many teams slip up. They hear “cloud” and think “automatically backed up”. Yes, Salesforce maintains backups for its own systems, but those won’t help when your sales team accidentally deletes opportunities, or when a bad data import overwrites months of information.

When crises like these happen, you need data and metadata backups to fall back on. Without backups, you’re dependent on ����������ڴǰ�����’s Data Recovery Service (which Salesforce itself does not want you to rely on) and rebuilding metadata — or perhaps deploying it from source control.

It’s important to remember, though, that any old backup won’t do. You need backups you can restore from quickly and reliably, to restore service for Salesforce end users with minimal disruption. In this article, we’ll cover your options for Salesforce backup and setting up your team for success when data loss happens.

Setting up an effective backup strategy

An effective Salesforce backup strategy protects your whole org, enhances security and compliance, and helps you recover quickly from any incident.

Backup coverage

Your backups should reflect the complete working state of your org: the metadata that represents the structure and behavior of your org, your records, files and attachments.

While you should back up all your metadata to capture the shape of your org, backing up all your data ������’t actually the best approach. Some high-churn data objects aren’t business-critical, and in backup monitoring will look like large volumes of deleted and added records — noise that potentially conceals actual data loss incidents.

Backup frequency

The cadence for your backup runs will determine your recovery point objective (RPO) — a disaster recovery metric which sets the maximum amount of acceptable data loss, by time period. Most businesses don’t want to lose more than a day’s worth of data, so daily backups are essential. Many businesses also want high-frequency backups for their most critical data objects, reducing the RPO for those records to 1 hour.

Disaster recovery testing

When designing a backup strategy, your recovery time objective (RTO) — the amount of acceptable downtime before data is restored — has to be front of mind. Having backups is one thing; being able to restore quickly is another. Businesses need Salesforce back on track within hours, not weeks.

Testing your backups with different restore scenarios is essential, both as you set up your backups and then periodically. Run recovery drills at least once a quarter. For safety, restore into a sandbox rather than production. Check that all data relationships — such as master–detail and lookups — are maintained correctly. Time how long recovery takes, note any challenges, and update your runbooks so future restores run more smoothly.

Secure, compliant storage

Ad hoc backups of Salesforce data can be a temptation for teams that haven’t secured budget for backup tooling. But this approach is a false economy: storage costs will soon mount up. Worse still, these backups are often stored without the level of encryption data has in Salesforce — meaning backups are actually putting data at risk. It’s also incredibly difficult to comply with “right to be forgotten” requests when backups are in countless CSVs.

Understanding ����������ڴǰ�����’s native backup solutions

Salesforce offers three native ways to create backups:

• Salesforce Backup managed package (paid add-on).
• Data Export Service (free, built-in tool).
• Salesforce Backup & Recover (formerly Own, paid solution)

Each works in a different way, and each has trade-offs that affect how quickly — and reliably — you can restore your data.

Salesforce Backup managed package

The Salesforce Backup managed package is a paid add-on you install into your org. You can customize your backup schedule, with backups stored within ����������ڴǰ�����’s own infrastructure. It’s designed to capture both data and includes a point-and-click restore interface directly inside Salesforce.

With the Salesforce Backup managed package, you benefit from:

• Delta backups — only the data that’s changed since the last backup is captured, reducing processing time.
• Files and attachments can be included in backup jobs.
• A backup dashboard, which visually shows you recent changes and backup status.
• On-demand backups, which allow you to trigger additional backups whenever needed.
• Trust boundary storage — all backup data remains inside ����������ڴǰ�����’s security perimeter.

However, it’s important to know this solution doesn’t back up Big Objects, skips objects without CreatedDate or LastModifiedDate fields, and is subject to Bulk API governor limits. Certain encrypted fields also need special permissions to be included. And because the backups live entirely inside Salesforce, they can’t be accessed during a Salesforce outage.

Data Export Service

The Data Export Service is a free tool included with Salesforce, available through the Setup menu. It creates a complete export of your records as CSV files and can optionally include files, images, and attachments (you’ll need to check the “Include images, documents, and attachments” box before running the export).

While simple to use, it’s limited to weekly or monthly schedules, meaning your Recovery Point Objective (RPO) could range from 7 to 29 days. Exports contain no metadata, and they must be downloaded within a 48-hour window before Salesforce deletes them. There’s also no sandbox support for practicing restores — something worth considering if you want to test your recovery process in a safe environment.

Salesforce Backup and Recover (formerly Own)

Salesforce acquired Own Data in 2024 and rebranded its backup solution as Salesforce Backup and Recover. A much more robust solution than the Salesforce Backup managed package, this represents ����������ڴǰ�����’s best answer for backup tooling.

The weak point for Backup and Recover is Salesforce metadata coverage, as its restore tooling only handles a small number of metadata types. It seems difficult to get predictable costs, since pricing is no longer public and users are reporting increases.

�ұ𲹰������’s enterprise approach to backup and recovery

At 91�Թ���, we take a different approach to Salesforce backup — one designed to make recovery faster, more reliable, and more aligned with the way teams already work.

In line with backup best practice, �ұ𲹰������’s backup solution ������’t installed inside Salesforce. Your backups are stored securely in the same AWS data centers trusted by Salesforce, but storage and access is kept separate from Salesforce itself.

Each 91�Թ��� backup snapshot captures data and metadata together — not just records, but the configuration that defines how your org works. This includes:

• Custom objects and fields
• Page layouts
• Apex classes and triggers
• Flows and automation
• Permission sets and profiles

Because these elements are captured in sync, your backups reflect a true, holistic state of your org at a given point in time, making restores more consistent and predictable.

�ұ𲹰������’s backup and restore solution also offers standard daily backups for all objects, plus high-frequency hourly backups for whichever objects you consider especially critical, such as opportunities, cases, and leads. You can also run on-demand backups before any high-risk operation. This allows teams to achieve a recovery point objective (RPO) as low as one hour.

How to back up Salesforce

Backing up your Salesforce orgs in 91�Թ��� is a simple, guided process.

1. Select your Salesforce organization

From the Backup & Archiving section of 91�Թ���, select Data backup jobs. Click Create job in the top right corner and choose between daily or hourly backups.

Select an org that you’ve authorized from the dropdown, give your backup job a name, and configure when the job should run.

2. Select the objects you want to back up

By default, 91�Թ��� suggests a set of recommended objects you could back up, leaving aside objects that most teams won’t find valuable and will create noise in your backup monitoring. But you can include or remove any objects, based on your requirements.

91�Թ��� will then guide you through permissions setup, both within Salesforce to make sure the backups function as you expect, and within 91�Թ��� to balance protection and collaboration.

3. Set up backup notifications

Finally, choose when and how you would like to be notified of backup job runs — whether it’s for every run, or only if the job fails.

Back up on demand

You can back up your org on demand any time, either from the main backup page showing all your backup jobs or from the backup history for each job.

Set up smart alerts

Configure alerts that will trigger when unusual changes happen in your org’s data, dramatically reducing your time to discover an issue.

Security, compliance, and data residency

Your backups need to be secure and compliant. 91�Թ��� uses enterprise-grade encryption, and gives you the tools you need for compliance requirements.

• Encryption standards: 91�Թ��� encrypts your data in transit using the latest SSL standards and at rest using one of the strongest block ciphers available to encrypt your data, 256-bit Advanced Encryption Standard (AES-256). It also supports Bring Your Own Key (BYOK) encryption for customers who require full control over their encryption keys.
• Data residency for compliance: Where your backup data is stored can be critical for meeting data sovereignty or GDPR obligations. 91�Թ��� allows you to choose your backup storage region: US, EU, Canada, or Australia.
• Compliance: 91�Թ��� holds ISO 27001 certification. It also offers a Business Associate Agreement (BAA) for HIPAA compliance.
• Access control and audit trails: Strong governance depends on knowing exactly who can access backups and what actions they take. 91�Թ��� offers role-based permissions and audit trails showing who restored what and when. 91�Թ��� extends this with the ability to perform targeted deletions across backup history, supporting compliance with “right to erasure” requests.
• Retention policies: 91�Թ��� allows you to configure your retention policy to align with compliance requirements.

What happens when you need to restore lost data?

It’s one thing to have backups. It’s another thing to actually use them to get your Salesforce org back to the state it was in before a problem occurred. The restore process and the challenges along the way depend heavily on the backup method you’re using.

If records are accidentally deleted, you can open the Salesforce Backup app, select the relevant backup snapshot, choose the records you want, and click Restore. In simple cases, this works quickly.

Meanwhile, if you’re using Data Export Service, the restore process is more hands-on:

• Map fields carefully before reimporting with Data Loader.
• Restore parent objects before child objects so relationships remain intact.
• Disable all automation to avoid triggers or Flows from running mid-restore.
• Manually match External IDs if you want records to align with other systems.

This process is painfully slow, and every manual step increases the risk of errors.

Restore with intuitive workflows

�ұ𲹰������’s workflows for restoring data and metadata are intuitive and user-friendly. With complete visibility over the process, you won’t risk blind overwrites, guesswork, and unexpected side effects.

91�Թ��� has four restore workflows to cover every scenario:

• Restore records with all dependent child objects — ideal when recovering a deleted parent record, ensuring all related records are restored in a single action.
• Restore specific fields only — perfect for scenarios like a mass email update gone wrong, allowing you to roll back just the affected field while keeping other valid changes intact.
• Restore records without dependencies — the fastest option when you just need to replace a few records and no related data is involved.
• Restore to multiple objects with complex filtering — for targeted recoveries across multiple objects, with fine-tuned filters to include exactly what you need.

For any restore, you can preview the exact restore plan, confirm the scope, and proceed knowing there will be no surprises or unintended changes. 91�Թ��� also includes search across your entire backup history, allowing you to quickly find specific records and restore them without trawling through complete snapshots.

Discover data loss immediately

Restoring after an incident takes time, but noticing an incident can take even longer if there’s no monitoring in place.

91�Թ��� offers smart alerts that trigger when unusual changes occur — for example, more than 100 contacts being deleted in a short period. Backup job monitoring flags failures or anomalies, and proactive notifications reduce the time between an incident occurring and your team responding.

DevOps integration advantages

One challenge for disaster recovery is real-life incidents are (hopefully) infrequent and unplanned. That means the teams working on restoration can be unfamiliar with the tooling and process they’re using.

Regular disaster recovery testing is part of the answer, so that teams can at least remember working through the process once. But a much better way is possible.

Teams using �ұ𲹰������’s full platform can go into their restore process feeling totally confident and familiar with the process, because it’s similar to their everyday deployment and sandbox seeding workflows. Salesforce teams are moving data and metadata between environments all the time. Why use a different tool when it comes to the most critical moment of restoring from backups?

There are other advantages that come from treating backups as part of DevOps. It’s easy to back up on demand right before a release, or at least check there’s a recent backup. You get integrated monitoring of data and metadata changes in one place. And you only deal with one vendor, which means lower costs, fewer legal, compliance and security checks, and less complexity for the team.

Why 91�Թ��� is the strategic choice for long-term Salesforce success

It just takes one serious incident to discover that investing in a proper backup solution pays off. And it’s a question of when not if: 47% of businesses saw Salesforce data or metadata loss last year. Salesforce is a critical business platform, and your backup strategy should match that importance.

With 91�Թ���, you get the broadest protection of your Salesforce orgs, secure and compliant storage, and crucially the best possible performance for disaster recovery. Book a demo with our backup experts to see exactly how 91�Թ��� can handle your specific requirements and restore scenarios.

There’s a tension between getting realistic test data and maintaining data security. Deploying customer data from production to other Salesforce orgs gives teams realistic test conditions, but risks exposing sensitive information and breaching compliance regulations — especially when data sets include PII (Personally Identifiable Information).

In this article, we’ll explore how data masking can resolve the security and compliance concerns associated with using production data in your testing environment. We’ll look at how to mask data natively with Salesforce Data Mask. Then we’ll see how �ұ𲹰������’s in-place masking gives you a safe and streamlined process for Salesforce data masking.

Realistic test data — without undermining data security

Full copy sandboxes mirror your production org’s data and metadata, but refreshing a sandbox is often slow. And whenever sensitive data is copied outside production, it raises the risk of internal or external data breaches. Other sandboxes and developer environments need populating with test data.

Basic, fictional data sets in sandboxes can be fine for unit tests, but they rarely reflect the real-world complexity of your Salesforce org. Fictional data won’t capture relationships between records, data structures, or how different types of data behave in real workflows.

To capture the complexity of your production data model, it can be tempting to seed sandboxes with data from your live environment. Having realistic data in your testing environment makes testing more reliable and helps developers find bugs before changes hit production. But using your production data for testing ������’t always possible due to regulatory compliance and security concerns.

Salesforce teams need to comply with a growing number of data protection frameworks, such as GDPR, CCPA, DPA, HIPAA, SOX, and PCI DSS. These regulations set strict governance rules for handling personally identifiable information (PII). It’s best practice not to give your developers access to customer data, and compliance often requires that PII be obfuscated before it’s used in testing. Masking data is also critical to prevent accidents like test emails being sent to real customers.

What is data masking?

Data masking makes it possible to test with data that looks and behaves like production records, without the compliance and security risks of exposing real customer information that comes with testing with production data. Data masking strategies replace sensitive records with realistic imitation data while helping to maintain data consistency so dependencies between records stay intact. This means you get the accuracy of production data without compromising security.

Masking can be static or dynamic. Static data masking, the type most commonly used in Salesforce, permanently replaces sensitive values with fictitious but realistic alternatives, making it ideal for software development and testing where teams need usable but safe sandbox data.

Dynamic data masking doesn’t alter the underlying records — it changes the data in real time as users access it, so the original values remain intact in the database. This makes dynamic masking less useful for Salesforce sandboxes, where developers need permanent, obfuscated test data.

What’s the difference between encryption and masking in Salesforce?

Data masking is sometimes confused with data encryption. Data encryption turns plaintext data into ciphertext using an encryption algorithm, making the data unreadable. A decryption key is needed to return the data to plaintext format.

This is ideal for securing live production records but useless in a sandbox. Masked data looks and behaves like the real thing, which keeps sandboxes functional for testing and development while removing the compliance risks of exposing actual data.

What’s the difference between data masking and tokenization?

Tokenization replaces sensitive values with randomly generated “tokens,” while the originals are stored in a secure vault and can be swapped back only by authorized systems. This reversibility is essential in highly regulated contexts such as payment processing, but ������’t ever necessary for sandboxes.

Compliance frameworks that require data masking

Compliance frameworks set strict governance rules for how different systems handle PII. If you’re subject to any of these frameworks, it’s important to identify sensitive data and apply controls for safeguarding sensitive information before it’s used in testing.

GDPR — Requires organizations to minimize the use of personal data and apply to protect it. Masking lets teams replace identifying details (names, emails, phone numbers) in Salesforce sandboxes so developers aren’t working with real customer data.

CCPA — Grants California residents control over how their personal data is used. Masking ensures that any data copied into non-production environments doesn’t count as unnecessary processing or exposure of personal information.

CPRA — Extends CCPA with stricter rules about protecting sensitive information such as financial records, precise geolocation, or healthcare records.

HIPAA — When PHI (Protected Health Information) is copied into a sandbox for testing or development, it must be either so individuals can’t be re-identified.

PCI DSS — The (PCI DSS) requires the protection of cardholder data in all environments. Masking credit card numbers, bank account numbers, CVVs, and other payment details ensures developers can test integrations without handling real card data.

SOX — While best known for financial reporting rules, SOX also requires strict internal access controls for financial data. Masking means sensitive financial records won’t reach sandboxes, preventing unauthorized access.

ISO 27001 — A global standard for information security management. While not prescriptive about masking, it requires technical and organizational controls to protect data.

Common data masking techniques

There’s more than one way to mask sensitive data in Salesforce, depending on how you want to strike the balance between usability and anonymity. The most common data masking techniques for keeping customer information secure are:

Scrambling

Scrambling jumbles characters in a field (like shuffling the letters in a name or the digits in a phone number) to break the link to the real value while keeping the same format. This is lightweight but effective for test data.

Anonymization

Anonymization removes or irreversibly alters identifiers so records can no longer be traced back to real people but can still support data analysis. This is often a compliance requirement, especially where regulations like GDPR and HIPAA apply.

Data substitution

Substitution swaps sensitive values with fake but realistic alternatives. This keeps testing environments functional and workflows intact without exposing real data.

Is Salesforce data masking permanent or can it be reversed?

Applying data masking is an irreversible process — once sensitive values are replaced, the original data can’t be restored. That’s what makes masking so effective for compliance and security: the sensitive data doesn’t exist in the sandbox, removing the risk of exposure during a data breach.

How to mask data with Salesforce

is ����������ڴǰ�����’s main native option. It’s a managed package and a paid add-on that can be used to obfuscate or delete sensitive records.

Since acquiring Own, Salesforce has also made two of their products available alongside Data Mask. streamlines the process of populating Salesforce sandboxes with up-to-date, realistic data and its features now live under ����������ڴǰ�����’s umbrella. is a separate managed package that lets teams build anonymization templates to disguise PII and other sensitive values, either by running a standalone anonymization job or as part of a seeding workflow.

Installation and setup of Salesforce Data Mask

Before you install Data Mask, make sure MyDomain and Lightning Experience are enabled in your orgs. Once you’ve installed the managed package, assign yourself the user profile System Administrator and the permissions Modify All Data and API Enabled. Finally, assign yourself the permission sets Data Mask User and Data Mask.

Data Mask is installed in production and will then be automatically enabled in any sandbox created or refreshed after installation. If you want to retroactively enable Data Mask in any existing sandboxes, take the URL from the Data Mask managed package link and manually change the subdomain from login.salesforce to test.salesforce.

This setup process is a bit convoluted, but upgrades and maintenance will happen automatically because Data Mask is a managed package.

How to use Salesforce Data Mask to protect sandbox data

You can configure a Data Mask job in production, then use it in any sandboxes you create or refresh afterwards. Or you can configure a job directly in an existing sandbox.

You’ll need to choose how to mask the data in your standard and custom objects. You can replace records with readable but randomly generated values, or you can replace them with records from one of these libraries: First Name, Last Name, Company Name, Email, Street, City, Country, Country (Abbr.), State, Postal Code, Phone Number, Social Security Number.

There’s also the option to specify any sensitive data that should be completely deleted. Case comments, emails and Chatter feeds, for example, are highlighted for you to consider masking or deleting.

Seeding masked records with their relevant relationships is the key to realistic test data, but Data Mask doesn’t always make that possible:

• It can sometimes skip over records with master-detail or lookup relationships, usually indicated by the error messages UNABLE_TO_LOCK_ROW or unable to obtain exclusive access. You’ll need to reconfigure and run the masking job again to try and get these records deployed.
• It doesn’t support , so records may come through incomplete or lacking fields.
• It can skip over records if there are . To overcome this, you need to configure an additional user that can bypass the duplicates and run masking from this profile.

Given the implications for security and compliance, it’s always a good idea to spot check records are being masked as expected.

Recent updates to Salesforce Data Mask

����������ڴǰ�����’s Summer ’25 release introduces improvements to make Data Mask easier to use and faster to run:

• Faster job execution: so jobs complete more quickly. Automations like workflows and triggers are now bypassed once a job finishes, preventing unintended actions and improving overall performance.
• Clearer visibility into jobs: From here, you can click into any masking job to see which objects were configured, track progress in real time, and review any errors, making it easier to troubleshoot and monitor.
• Automated Data Mask processes: now lets you configure Data Mask to run automatically on a daily, weekly, or monthly basis. This applies to sandboxes created from production orgs that have the latest Data Mask managed package installed.

How to run in-place masking with 91�Թ���

91�Թ��� makes sandbox protection quick and reliable with in-place masking. You can obfuscate data that’s already sitting in a partial or full copy sandbox, keeping PII safe while still leaving the environment usable for testing.

In-place masking is part of our sandbox seeding solution, which also lets you deploy masked data from production or another org into a sandbox and .

1. Enable data deployments

Data deployments aren’t enabled by default in your 91�Թ��� account. Before configuring your first in-place masking, a team owner will need to go to Data management, via My Account —&����; Backup and archiving (under Data deployments) and select Enable data deployments to developer and sandbox orgs for my team. This is a one-time setup and won’t need to be repeated.

2. Select target org

Once data deployments are enabled, you’re ready to get started. Navigate to Data Deployments —&����; Configure and deploy. If you have data deployment templates saved, you can select them here or opt to configure your data deployment from scratch.

Click on the Configure in-place masking button. This will launch a dialog box where you can select the target org. Team-owned orgs cannot be used for in-place masking, so this will need to be a sandbox you’ve connected to 91�Թ��� with your own user credentials.

3. Select the objects you want to mask

After pressing Configure in-place masking, 91�Թ��� will list all objects that are available for masking. You can select all the objects you want to mask and click Confirm.

4. Select the fields you want to mask

Use the search box to filter the list of fields by the object and field name or use the filters on the left to filter by field type. Select all the fields you want to mask.

For standard fields, 91�Թ��� provides localized masking options to make sure the data is as accurate and representative of your production data as possible.

For example, you can choose to mask phone numbers in US format or UK format — 91�Թ��� will then automatically use the correct country code and number of digits.

You can also customize masking for some fields by selecting a mask method. Check the sample output in the right hand column and click Next.

5. Disable rules, triggers and Flows

91�Թ��� will automatically flag any active rules, triggers or Flows in your target org. You can disable these while the in-place masking is running. They can be reactivated in just a few clicks afterwards. Simply clicking Deactivate will deactivate the selected automations via a metadata deployment. When it has completed, click Next.

You can also disable . If it’s left on, Salesforce will create a history record for every masked field — storing both the old and new values. To prevent this, select the relevant objects with history tracking in the rules and automations list (seen here on the object My_record__c).

Once your masking job has finished, you can roll back everything you disabled in a couple of clicks, using the same smooth rollback process 91�Թ��� gives you for data deployments.

6. Start your in-place masking

91�Թ��� will show you the object records to be deployed and any actions taken to retrieve the records — like fetching, masking, and updating — as well as the field count. When you’re ready to continue, press Deploy data. When the in-place masking is running, each stage will mark as completed and show you how many records have been processed in each step.

Once the deployment has run, your testing environment will be ready to go with masked test data.

You’ll be able to see your in-place masking deployments in your data deployment history. And if you disabled any rules, this can be reversed by clicking on Rollback deactivation deployments at the bottom of the page.

Choosing your data masking solution

When it comes to finding the right data masking tools for Salesforce, teams can choose between a few different data masking solutions: Salesforce-native tools, a Salesforce-specific DevOps solution like 91�Թ���, or a general purpose, multi-system ETL (Extract, Transform, Load) platform. Here’s a look at how they compare:

Salesforce Data Mask is the main native option. It’s a managed package installed in production, and it only supports in-place masking. While it can preserve referential integrity automatically, it has limitations: picklists, formula fields, checkboxes, and roll-ups can’t be masked. Jobs can be scheduled inside the app, but with no API or external integration, Data Mask can’t be embedded in a broader DevOps workflow. Logging is also limited to the Jobs tab, with no export for external auditing. Pricing is an add-on SKU, .

Anonymize (Own from Salesforce) is a separate managed package for production-derived sandboxes. It offers a broader range of format-preserving anonymization functions than Data Mask, so you can disguise PII while keeping masked data realistic. Relationships are kept intact, though the main focus is on field-level obfuscation. It includes reporting for compliance teams, but like Data Mask, integration with DevOps pipelines is limited. .

�ұ𲹰������’s in-place masking is part of its complete DevOps platform, so masking fits naturally into the same workflow you already use for deployments, CI/CD, and release management. Connecting orgs is quick with OAuth. 91�Թ��� masks any queryable field and auto-detects and maintains relationships between records. You’ll also use the same UI for masking during data deployments and masking jobs are logged in your deployment history for exportable audit trails.

Third-party ETL tools like Informatica are general-purpose rather than Salesforce-specific, and masking features typically won’t appear in a Salesforce-style UI. Some ETL platforms can support both sandbox seeding and in-place masking, but setup is often done object-by-object and relationships need to be configured manually.

Quality testing without the risk

If you’re running a large Salesforce org with millions of records, working in a heavily regulated industry, or handling sensitive customer data, the stakes for testing are high. You need a sandbox seeding and data masking solution you can rely on to protect sensitive data.

Your sandbox data masking process should never force you to choose between protecting customer data and ensuring quality releases. The closer your test data is to production, the more reliable your testing will be — and the less likely you are to face unexpected issues on release day.

Get the confidence of realistic test data without the risk of exposing sensitive information. Try out �ұ𲹰������’s data masking for yourself, start a free with nothing to install in your orgs.

But that can leave teams confused about implementing DevOps. Where do you begin? What steps need to come before others? What’s the end goal?

In this guide to finding Salesforce DevOps success, we’ll outline a roadmap for adopting DevOps. It’s not a “one size fits all” model, but a typical pattern. It shows how the average Salesforce team tends to introduce new tools and processes to support the different stages of the DevOps lifecycle.

Salesforce DevOps adoption in 2025

It’s worth highlighting that the vast majority of Salesforce teams are somewhere along the road to adopting DevOps. �ұ𲹰������’s State of Salesforce DevOps 2025 report shows that 87% of Salesforce teams have or are looking to implement DevOps tools and practices.

DevOps tools underpin DevOps practices

There’s a logical sequence for adopting DevOps tools — version control before CI/CD automation tools, for example. And the data shows that teams are picking up those tools in that order: 65% have implemented version control; 55% practice CI/CD.

Backup is quite widely adopted (70%) though not every team has backups well integrated with their broader Salesforce tech stack. Newer areas for the Salesforce world currently have lower adoption rates for tooling: observability (31%) and change intelligence (26%).

But DevOps principles are fundamental

A plan to implement DevOps shouldn’t be a checklist of tools, but a set of principles that will help your team to achieve their goals. What are the essential DevOps principles? You’ll find a variety of thoughtful answers, such as the . But with different emphases, these frameworks all address a similar set of principles:

Collaboration

The origin story of DevOps was all about bringing together development (“Dev”) and operations teams (“Ops”) to break down team silos. In the Salesforce context, the teams might be different — low-code admins and pro-code developers, for example — but the principle is the same: bring teams together to share responsibility for their overall performance. A culture of collaboration is foundational for DevOps.

Iteration

Where the standard development lifecycle is generally depicted as a circle, the DevOps lifecycle is shown as an infinity loop. This represents the agile, iterative approach to the entire development process, in contrast to legacy approaches to release management such as the waterfall methodology.

There’s a strong connection here to the “7 Cs” of DevOps: continuous development, continuous integration, continuous testing, continuous deployment/delivery, continuous monitoring, continuous feedback, and continuous operations. Teams should also aspire to a culture of continuous learning and continuous improvement, taking the right lessons from each development cycle.

Automation

Once any given step in a workflow is repeatable and reliable, it should be automated if at all possible. Automation reduces the manual effort spent on releases, freeing up developers to spend more time on the development phase. Even more importantly, automation makes it possible to achieve the iterative and continuous processes associated with DevOps.

Security

DevOps sometimes has a reputation for being about speed alone, without due care for quality and security. In fact, the DevOps philosophy is that collaborative, iterative, automated ways of working help teams to achieve higher quality and enhanced security practices.

Shared accountability for security and a low-blame culture encourages quick reporting of vulnerabilities, honest diagnosis of mistakes, and widespread uptake of security best practices. Making change incrementally reduces the risk of each deployment, and shrinks the surface area for testing. Automation takes away the risk of human error from repetitive processes.

Some like to use the term ���𱹳��𳦰����” to emphasize this commitment to integrating security within DevOps and the necessity of bringing security teams into the fold. This can have the unfortunate effect of implying that DevOps itself has little regard for security, when the reverse is true.

Drivers and barriers for development teams implementing DevOps

The drivers for Salesforce DevOps and the barriers faced by teams reflect the complexity of DevOps adoption. Budget constraints relate to tooling. Lack of buy-in, training or prioritization all highlight that a culture shift is needed. Security and compliance challenges should be addressed with tools, process and culture. For a successful DevOps implementation, you’ll need to consider all three.

Mapping DevOps adoption with the DevOps lifecycle

If DevOps tools are just part of the picture, and DevOps principles are an open-ended commitment to a new way of working, is there anything more definite to aim for? The DevOps lifecycle gives you a complete view of the essential stages that make up your complete development process. This is the best roadmap for guiding your implementation of DevOps.

But where do you begin with the lifecycle? Attempting everything in one go would be overwhelming, so you’ll need to consider which stage to focus on first. Your team should really diagnose performance in each area and evaluate how new tools, better processes and changed culture could help. But you’ll probably find yourself somewhere on the journey we’ll outline in the rest of this article.

Start at the release stage: get quick wins with proper deployment tooling

Releases are a non-negotiable step for every development team. For Salesforce teams pre-DevOps adoption, releases are also error-prone, time-consuming, and risky, which is why most teams already know they want to start here. Releases are where they feel pain right now.

Salesforce teams typically start by looking for a deployment solution to make releases less painful. At this stage, they might not be thinking about DevOps more broadly — they’re just focused on solving that immediate pain. Deployments with change sets, DevOps Center or the Salesforce CLI are where teams see friction, which prompts them to look for a replacement deployment tool.

There are real and significant improvements that teams will achieve with �ұ𲹰������’s deployment solution alone, including:

• Total visibility on the differences between environments
• Ability to move metadata easily between orgs and version control
• Dependency analysis to any depth
• Visualizers for metadata types such as Flows and Layouts
• Problem analyzers designed to ensure deployment success
• Testing for any Apex classes being deployed
• Team collaboration on deployment packages
• Cloning and combining packages
• Scheduled deployments
• Full or partial rollback
• A full audit trail of deployments

With all those features, teams see much more deployment success. And because deployments are much faster, teams can increase their release frequency.

Shift left: improve quality and efficiency with the right testing strategy

But focusing on deployment tooling and process alone doesn’t solve every problem you run into at release, because some of them aren’t really release problems the pain is just felt at the release stage.

To address the root cause of these problems, development teams need to “shift left”. That is, they need to catch problems at the earliest possible opportunity, when they’re easiest and cheapest to fix.

Shifting left to the build and validate stages

Imagine your team is collaborating on a new feature. You really don’t want to wait until you’re nearing release day to find out:

• Will everyone’s changes integrate properly?
• Will the feature perform as intended in live environments with real data?
• Is our code and configuration secure, efficient, and consistent?
• Are we hitting the 75% code coverage threshold with our unit tests?

These questions need to be answered earlier, shifting left to the validate or build stages of the lifecycle. With continuous integration, all work should be continuously tested as it’s combined, with any merge conflicts handled along the way. Code analysis and automated code reviews should flag security vulnerabilities and non-compliant Apex classes and Flows, so developers can get them fixed along the way.

Shifting left to the plan stage

Now let’s imagine some different scenarios, that can happen even when there are no concerns about functionality, quality, and security because the necessary fixes and improvements have been made during the build and validate stages:

• A feature gets to UAT, only for end users to say it doesn’t meet their requirements.
• Your team is busily working on a feature, but then the business says it’s no longer needed and the work is abandoned.
• You release a feature successfully, but there’s no uptake in production.

These are failures at the plan stage of the lifecycle, and the “shift left” mindset needs to be pushed back to the beginning of each cycle. Is everyone definitely aligned on what needs to be built and why? Does everyone understand the current state of the org? Is it clear what success would look like? Have all relevant stakeholders been included in the decision-making process? A little more focus on getting the plan right saves a lot of wasted time and effort.

The cultural element of good planning is vital: collaboration and communication are critical. But tools can help as well. Org Intelligence massively reduces the time it takes to understand the current state of your orgs in the planning stage.

Look right: close the visibility gap and complete your process

While we’re coming to them last in this article, we could have made a compelling argument for paying attention to the operate and observe stages first. Securing and understanding your org is the solid foundation you need to innovate safely. And as we’ve said, there’s no “right” way to adopt the lifecycle, so your team may decide to do just that.

But in reality, when it comes to DevOps adoption for Salesforce, the “Ops” side of things has generally lagged behind partly because Salesforce handles some operations for you. Its shared responsibility model means it takes care of your infrastructure and offers a safety net for worst-case scenarios, while you’re responsible for your data and metadata on the platform.

It’s your responsibility to build a solid backup and restore process, so you can recover quickly from any incident and keep your Salesforce orgs operational. It’s also your responsibility to implement observability tools, so you can understand how your work is performing in production. Backups and observability are a given for DevOps teams on other development platforms. Without them, you’re developing in the dark and running a risk with every release.

Investing in these stages becomes a no-brainer once you’ve already invested in releases and have embraced a “shift left” approach. You’ve gained the ability to release quickly, but do you have the confidence to release more frequently? You’ve driven down change failure rates by shifting testing and analysis to the left, so why aren’t you doing anything to identify the breaking changes and errors in production?

Choosing the right tools for Salesforce DevOps

The DevOps lifecycle represents the complete process your team is aiming to bring in line with DevOps principles, making it the best guide for DevOps adoption. The lifecycle doesn’t imply a specific set of tools and workflows, and that’s important. Each team will need a slightly different toolset, and will need workflows that match the makeup of their team and business context.

But without giving a prescriptive checklist of tools, it’s still useful to be aware of different categories of tooling for Salesforce DevOps:

91�Թ���: the DevOps platform that brings everything together

Given the number of tooling categories, as we saw above, an obvious challenge with point solutions is that a broad DevOps implementation will result in multiple tools and vendors to manage.

�ұ𲹰������’s platform covers the full lifecycle with our own solutions in every category, except ticketing and version control, where the vast majority of teams want to use their tools (e.g. Jira and GitHub) for consistency with the rest of their business. We have tight integrations with all major ticketing and VCS providers.

Rather than twenty tools covering different tasks in your development lifecycle, you can get all the tools you need for the whole DevOps lifecycle using, for example, 91�Թ���, Jira, and GitHub. This takes for granted the “build” tools you use: Salesforce developer environments and an IDE like VSCode (which is free). Salesforce DX (also free) can be used within and alongside 91�Թ��� as well.

It’s intuitive that teams perform best when they can manage their end-to-end process from one shared platform. And the data confirms that this is the case. The State of Salesforce DevOps 2025 report demonstrates a strong correlation between fewer tools and better performance even factoring for variables like the size of organization or DevOps maturity.

DevOps teams consider the full lifecycle — Salesforce teams should too

Not many years ago, most Salesforce teams hadn’t heard of DevOps. Now the situation is reversed. But relatively few teams have adopted mature processes and tooling right across the Salesforce DevOps lifecycle. As the performance gains for quality, speed and security of delivery become increasingly clear, DevOps adoption will continue at pace in the Salesforce ecosystem.

On other development platforms, the tools and processes covered in this article are generally assumed to be essential. Salesforce teams deserve the same toolsets to ensure success on a critical platform for their business.

Get in touch with us today to arrange a tailored demo of 91�Թ���, so you can see how the platform will help you implement or improve your Salesforce DevOps process.

At this point, one thing is clear: you need to free up space fast. But that raises the big question — what’s the best way to archive this data without disrupting your users or losing critical information?

At first glance, Salesforce Big Objects can be an attractive choice. They’re native, designed for scale, and available without additional licensing. But when it comes to complex archiving and data restoration, you’ll find that Big Objects require more extensive development work, have strict indexing requirements, and don’t support automation or standard Salesforce reporting.

If you’re dealing with storage issues, this guide is for you. We’ll break down what options you have, including ����������ڴǰ�����’s Big Objects, what it really takes to use them effectively, and why they may not always be the most practical choice for long-term data archiving.

Understanding Salesforce Big Objects: Technical foundation

are a special type of custom objects designed to hold massive amounts of data, often billions of records, within your org. But they don’t work the same way as your standard Salesforce objects. Instead of using the usual database that powers most of your org, Big Objects are stored in a system built specifically for massive scale.

Big Objects are non-transactional, so partial write failures are possible and expected. Salesforce recommends implementing your own retry logic to handle these failures, but keep in mind that this requires additional development and testing to ensure your data loads are reliable.

Big Objects vs. External Objects

It’s easy to confuse Big Objects with External Objects, but they serve very different purposes — and it all comes down to where your data lives.

Big Objects keep your data inside Salesforce, but in a storage system designed for scale rather than day-to-day access. They’re a good fit when you need to archive large volumes of historical data and keep it within your org.

External Objects, on the other hand, don’t actually store data in Salesforce at all. Instead, they display data from outside Salesforce using OData connections. They’re great for integrating external systems, but they’re not designed for archiving data you want to keep securely within your org.

Creating and setting up Big Objects

Setting up your first Big Object ������’t as simple as clicking a button. Unlike standard objects, which you can create through the Salesforce UI, Big Objects require either a Metadata API deployment or manual setup through Setup > Big Objects.

This process involves defining fields, setting up indexes, and deploying. Unlike relational databases, you’ll also be using methods like Database.insertImmediate() for synchronous operations (which come with governor limits) or Database.insertAsync() for large-scale loads.

The 5-field index limitation

When you create a Big Object, you’re allowed one compound index with up to 5 fields. Indexes are crucial when you’re archiving, because they determine how you’ll be able to search and retrieve your data later. You can’t modify the index after the object is created. This can cause you problems down the line during data recovery scenarios where you may need to search for data based on different criteria. If you make the wrong decision here, you’ll need to start over — there’s no quick fix.

Accessing Big Object data

Until Summer ’23, Salesforce offered Async SOQL (Salesforce Object Query Language), a feature that let you run large-scale queries on Big Objects in the background. It’s retirement leaves you with two ways to access Big Object data:

• Batch Apex allows you to process large datasets in manageable chunks. This requires careful management of governor limits and error handling.

• Bulk API is ideal for extracting data to external systems for reporting or analysis, but comes with its own set of complexities, such as managing authentication, handling large CSV files, dealing with API rate limits, and transforming data into a format your target system can consume.

With Async SOQL gone, you can’t just run a query and wait for the results to land in your inbox anymore. Instead, you’ll need to build and maintain batch jobs or external data pipelines — adding even more complexity to an already challenging implementation.

Using Big Objects for archiving: What to expect

Moving millions of records out of production sounds simple enough. But with Big Objects, the reality is more complicated. Without careful planning and a clear understanding of the limitations, you can end up with data that’s hard to query, slow to restore, and expensive to maintain. Here are some things to consider if you want to use Big Objects for your archiving:

Understand Big Objects’ use cases

Big Objects are designed for very specific scenarios, typically data that’s written once and rarely accessed — think audit trails (Field Audit Trail) or sensor data.

If you need to quickly restore data for active business operations — such as supporting customer service, sales, or any other department that requires frequent access — Big Objects are not the right solution.

Calculate the total cost of storage. Big Objects are available by default in Salesforce Enterprise, Performance, Unlimited, and Developer Editions. But if your org needs to archive more than the one million records that are included by default, you’ll likely need to purchase additional capacity.

You’ll also need to take into account the cost of development. Schema design, index planning, batch job development with retry logic, and custom UIs for accessing data all take time. Restores, in particular, can be complex and resource-intensive. While the storage itself may appear inexpensive, the operational overhead can add up quickly.

Consider record IDs and relationships

In standard Salesforce objects, every record has a unique 18-digit ID that keeps relationships between records intact — for example, Accounts know which Opportunities belong to them, and Opportunities know which Line Items they own.

Big Objects work differently. Instead of those familiar record IDs, they use internal identifiers that you can’t query in the same way. This makes it harder to restore data to its exact original state if you ever need to re-insert it back into standard objects.

This means that when you archive an Account along with its related Opportunities into Big Objects, the relationship between them is lost. Without the standard Salesforce ID, you can’t easily query or restore those records and their relationships back together.

You can’t simply “restore” an Opportunity with its related Account — you need to rebuild the entire relationship hierarchy from scratch. This manual process not only introduces risk but also creates a massive burden on the recovery workflow.

Prepare for security and compliance

Big Objects offer basic security controls — object and field-level permissions only. There’s no sharing rules or team hierarchies to customize access in a granular way. Essentially, everyone with access to Big Objects can see everything — or nothing. This can be a serious issue if you have a complex security model in place within Salesforce.

Features like Shield 91�Թ��� Encryption don’t extend to Big Objects. For organizations bound by compliance regulations like GDPR, HIPAA, or financial regulations, this can trigger major compliance violations.

Big Objects can also cause frustration because there’s no built-in UI for deleting a customer’s data. Instead, you’ll need to write custom Apex code to identify and remove records based on your limited index. And, when it comes to Data Subject Access Requests (DSARs) — requests from customers to access or delete their data — Big Objects can slow down response times. Since there is no easy UI or automation to process these requests, what should be a simple task could end up taking days, not hours, to resolve.

Design for query and storage needs

When designing your archive system, one of the most important decisions is how to structure your indexes. Indexing is critical for query performance, and it’s essential to think about how users will search your data, not just how it’s structured.

For example, if you’re archiving EmailMessage records, you should index by AccountId first if users will search by account. If you run time-based reports, index by CreatedDate. Remember, once you’ve set your index, you can’t modify it — so make sure you get it right the first time. If you don’t, you’ll have to start over completely.

Salesforce also sets a 100 Big Objects per org limit, which can quickly become a bottleneck if you’re managing multiple record types.

Why teams choose 91�Թ��� for external archiving

As Salesforce organizations scale, managing storage efficiently becomes more critical. �ұ𲹰������’s external archiving solution offers a way to solve this problem with features and capabilities that extend beyond the limitations of ����������ڴǰ�����’s native options, like Big Objects.

Here’s why more teams are choosing 91�Թ��� for archiving:

• True storage reduction through off-platform archiving: �ұ𲹰������’s Data Archiving doesn’t just move data — it reduces storage by migrating records from Salesforce to 91�Թ���, then deleting them from your Salesforce org to free up existing storage capacity. This approach genuinely reduces storage usage, unlike Big Objects, which keep data within Salesforce, continuing to count toward storage limits.

• Unlimited storage container: Instead of paying for increased Salesforce storage over time, 91�Թ��� offers unlimited storage for archived records. This means you can avoid per-GB pricing and predict your costs based on the number of Salesforce users in your organization. No more worrying about scaling storage or fluctuating costs — 91�Թ��� simplifies your long-term planning.

• Automated archiving rules: With 91�Թ���, archiving ������’t manual — you can automate the process. Set up rules to automatically archive records based on record type or timeframe. 91�Թ��� will automatically move irrelevant data out of your org without requiring constant intervention. This ensures that your team doesn’t need to remember to archive data — it happens automatically, saving time and streamlining processes.

• Preview and control: Before archiving data, 91�Թ��� lets you preview what’s about to be archived, providing full visibility. You can review and adjust your archiving jobs as needed before execution, which prevents surprises and ensures you maintain control over what’s moved and when.

• Searchable archive: Searching archived records is a breeze with �ұ𲹰������’s searchable archive. Retrieve records quickly by searching for anything within them, such as by record name or ID. You can even view archived records alongside their child records to maintain context. This makes audits, compliance checks, and general record retrieval efficient and hassle-free.

• Files and attachments included: Unlike Big Objects, which do not support attachments or files, 91�Թ��� includes them in your archiving process. Archive data on standard objects, custom objects, and files/attachments. This comprehensive approach ensures that all your storage needs are covered in one solution.

• Fast implementation: 91�Թ��� makes archiving simple to set up. There’s no software to download or install in your Salesforce orgs. Just connect your org to 91�Թ���, and you’re ready to start archiving. There are no managed packages or custom development required, which saves time and resources.

• Enterprise security: 91�Թ��� takes security seriously. We’re ISO 27001 certified and provide enterprise-grade encryption both in transit and at rest. You can choose where your data is hosted in data centers across the US, EU, Australia, or Canada. Additionally, 91�Թ��� is fully compliant with global standards like UK GDPR, EU GDPR, CCPA/CPRA, and HIPAA, ensuring that your data is always safe and compliant.

• Always available: Since your archived data is stored off Salesforce servers, you’ll still have access to it even if there’s an outage within Salesforce. This feature ensures business continuity and gives you peace of mind knowing that your data is always available when you need it.

• Archive viewer for easy access: �ұ𲹰������’s provides an easy way for non-91�Թ��� users — like Sales and Support teams — to view archived data directly from Salesforce. This Lightning Web Component lets teams quickly access related archived records (such as tasks, cases, opportunities) without needing to restore them back into Salesforce. It’s a read-only view that ensures data stays secure while still being accessible.

The unified platform advantage: When backup meets archiving

�ұ𲹰������’s complete DevOps platform offers a unique advantage by combining backup and archiving into a single solution. Rather than managing two separate systems, you only need to learn one restoration process, work with one vendor, and go through one security review. This simplicity significantly reduces risk, making your data management strategy both more effective and less complicated.

Consistent recovery regardless of data location

One of the key benefits of 91�Թ��� is the consistency of your recovery process. Whether the data you need is in your latest backup or last year’s archive, the restoration process remains identical. You’ll use the same user interface, the same workflow, and get the same reliable results every time. This consistency transforms recovery from an emergency scramble to a routine, predictable operation.

With 91�Թ���, you can restore records quickly and reliably, whether you need to retrieve a single record or bulk data. Access controls ensure that only authorized users can archive or restore data, maintaining security throughout the entire lifecycle.

Unified monitoring and alerts

Managing both backup and archiving becomes even easier with �ұ𲹰������’s monitoring and smart alerts. From a single platform you can track both your backup and archiving operations, giving you a comprehensive view of your org’s data.

Smart alerts keep you informed in real-time when there’s unusual data volumes being deleted or corrupted. We understand that “unusal” for one team is normal for another, so we let you set the limit to what’s usual for you.

Compliance without complexity

With automated retention policies, you can set up rules once and apply them universally across your data. Whether you need to retain financial records for seven years or ensure GDPR-compliant deletion after three years, 91�Թ��� automates these processes, saving you time and reducing the risk of human error.

91�Թ��� also captures a full audit trail for every operation, ensuring that all actions are documented and accessible at any time. This makes it easier to meet compliance requirements while avoiding the complexity and manual work often associated with these tasks.

Your path to reliable data archiving

The choice is clear: Big Objects are suited for analytical data storage, but when your business relies on quick data recovery, when managed packages complicate your data model, or when users need daily access to archived records, only a purpose-built solution like 91�Թ��� delivers the performance and reliability you need.

Take the next step toward confident data archiving. or book a personalized demo with our Salesforce experts to experience how purpose-built archiving should work.

This growing gap between approving a change and safely deploying it is technical debt in action. In Salesforce, this technical debt shows up as deployment time inflation — routine changes become slow, risky, and expensive. If you leave this technical debt unmanaged, it becomes a barrier to scaling and a hidden cost embedded in every change. AI tools accelerate this further — code generated at scale, without knowledge of your org’s architecture or governance standards, adds debt faster than most teams can measure it.

In this article, we’ll break down ����������ڴǰ�����’s technical debt into six key categories, explore how small cracks can lead to deployment disasters and compliance risks, and show how 91�Թ��� can help you move from constantly cleaning up debt to preventing it in the first place.

What is technical debt in Salesforce?

is what happens when quick fixes you make today create big problems tomorrow.

Imagine you’re tidying up but you don’t have time to do it properly so you shove everything in a drawer. Problem solved, for now. But the more times you do that, the messier it gets — and one day, you can’t even fit anything else in.

Salesforce works the same way. Every time we add a field, Flow, validation rule, or automation without thinking about how it fits into the bigger picture, we’re shoving something “in the cupboard.” It works in the moment, but over time it becomes harder to change things without breaking something else.

It’s important to understand the difference between Salesforce technical debt and just having a messy org:

• A messy org is clutter that builds up in an org over time — unused fields, duplicated automations, inconsistent naming conventions. It creates friction and slows people down, but with disciplined cleanup and stronger governance, it can usually be brought under control.

• Technical debt embeds brittle patterns in your architecture, limiting flexibility and eventually creating a scalability wall that no amount of surface-level tidying can fix.

Technical debt also impacts you financially. As complexity grows, a growing portion of your technology budget gets redirected from innovation toward managing the consequences of past decisions. Development teams lose time navigating systems, chasing down dependencies, and firefighting unexpected behavior.

The six categories of Salesforce technical debt

Understanding these six categories will help you spot technical debt early before it slows down your team.

Configuration debt: When declarative choices compound

One of ����������ڴǰ�����’s greatest strengths is its flexibility. Teams can build powerful functionality without writing a single line of code. But over time, that flexibility can lead to layers of automation, fields, and permissions that become difficult to manage and even harder to change safely.

Here’s why:

• Automation sprawling across multiple tools: A single record save might trigger six separate automation paths built by different teams over several years. A Workflow Rule from 2019, a Process Builder from 2020, multiple Flows from 2022, and an Apex trigger added last quarter — all trying to run at once, often in unpredictable order. This results in unexpected behavior, performance issues, and high-risk deployments.
• Excessive custom fields: For example, over time, the Account object might end up with 347 custom fields, with more than half not being actively used. Changing or removing these custom fields (even unused ones) means sifting through hundreds of potential dependencies.
• Overlapping permission sets: You might find twelve different permission sets with overlapping access, no clear documentation, and no reliable way to know who actually needs what. If that’s the case, making a single security change can take weeks, simply because no one’s sure what’s safe to adjust.

Individually, these issues seem manageable, but combined, they create a landscape where even simple changes require excessive caution or they’ll quietly generate a significant layer of technical debt.

Code debt: Governor limits as strategic warning signs

Code debt often becomes visible through platform constraints, especially when systems grow and usage scales. Apex code written for today’s needs might not hold up under tomorrow’s data volumes, and the consequences often show up at the worst possible time.

Common causes of code debt include:

• Non-bulkified Apex that hits Salesforce governor limits: A trigger that works fine when processing 100 records may fail completely at 1,000 — not because the logic is flawed, but because it wasn’t designed to scale. Suddenly, critical business operations stall, and development teams are pulled into emergency refactoring that derails planned work.
• Hard-coded dependencies that make deployments fragile: Sandbox or user IDs embedded directly in code seem harmless at first until they cause deployment failures in production. What should be a simple release turns into multi-day troubleshooting, delaying delivery and damaging stakeholder trust.
• Relying on vanity tests: Vanity test coverage — hitting the required 75% by executing code paths without actually verifying outcomes — creates a false sense of security. Bugs slip through, technical risks go unnoticed, and teams assume the system is more stable than it really is.

Architectural debt: Design flaws that prevent scaling

Architectural debt is the accumulation of flawed or short-sighted design decisions that block scalability, clarity, and strategic growth. This can cause issues like:

• Data model bloat: You might find 15 custom objects supporting a business process that could realistically be handled with five. Each object brings its own relationships, fields, and dependencies, making reporting difficult and changes risky. A single reporting initiative can require months of data model restructuring just to deliver usable insights.
• Overcomplicated security models: Between role hierarchies, profiles, permission sets, and sharing rules, access control can become deeply tangled. Even small permission changes require lengthy investigations to assess risk. As a result, admins grow hesitant to make updates, and necessary improvements to security posture are delayed or avoided entirely.

Integration debt: External dependencies as business risk

Modern Salesforce orgs rarely operate in isolation. They’re connected to Enterprise Resource Planning Systems (ERPs), marketing platforms, finance systems, and data warehouses. But with every integration comes a new layer of risk. Integration debt is what happens when those external connections are fragile, outdated, or built without long-term maintainability in mind.

Major risk areas here involve:

• API version retirement: Integrations built years ago may rely on retired API versions. Everything runs smoothly until Salesforce retires that version. Suddenly, your integration returns 410 GONE errors, and entire business processes stop overnight. Order syncs fail. Renewals don’t process. Revenue gets impacted because an invisible dependency has expired.
• Integration brittleness: Many orgs rely on point-to-point connections with no monitoring or error handling. When these integrations silently fail, no one notices until critical data is missing or out of sync. Business continuity depends on these connections, but without stability or observability, they become a constant liability.
• Missing error handling: Many integrations lack retry logic, monitoring, or alerting. If a sync fails over the weekend, no one knows data is missing until Monday. Silent data corruption becomes a hidden liability, affecting forecasting, compliance, and customer experience without any clear signal of what went wrong.
• Data silos between systems: When Salesforce diverges from the system of record — the authoritative source of truth for that data, often an ERP or HR platform — reporting becomes unreliable. Regulatory violations can occur if customer data is inconsistent across platforms, especially in industries governed by strict audit or privacy standards.

Environmental debt: 91�Թ��� evolution as inherited liability

Salesforce releases three updates a year, introduces new tools, and eventually retires legacy features. That continuous innovation is a strength, but it also imposes a maintenance burden on every org.

Even if the original automation was well built, once Salesforce deprecates a tool like Process Builder, continuing to rely on it becomes an inherited liability. Over time, the cost of staying put grows through performance warnings, compatibility issues, and limited support.

Lightning migration is another example. Visualforce pages that once met every business need now require conversion to Lightning Web Components. While Salesforce hasn’t retired Visualforce, building new functionality on it creates mounting debt — what should be a straightforward maintenance task becomes a full development project, adding unexpected costs and effort for even minor changes.

Documentation and people debt: The risk multiplier

Documentation and people debt are tied to what your team knows, remembers, or forgets. When knowledge lives in people’s heads instead of systems, it causes several problems:

• Knowledge concentration in single points of failure: Critical logic might live in the mind of one developer or admin — the only person who truly understands how a specific automation works or why a particular field behaves the way it does. When they’re unavailable, every deployment decision slows down. When they leave, that knowledge can disappear entirely.
• Undocumented business rules: For example, a 200-line Flow that validates revenue recognition logic might look sound, but without explanation, teams can’t say whether it reflects current policy, how it connects to reporting, or what happens if it’s changed. This uncertainty causes hesitation, delay, and in many cases, organizational paralysis around even minor updates.
• Day-to-day friction from inconsistent standards: When fields storing similar data are named Customer_Value__c, Client_Priority, and CustomerRating, developers and admins waste time tracing functionality, mapping dependencies, and second-guessing what should be straightforward decisions.

When technical debt becomes a business crisis

Most of the time, technical debt is just a drag on productivity. But there are moments when it snowballs into a full-blown business crisis — here are a few scenarios where that happens:

Major release deployment disasters

A cross-functional team spends months building a new feature set. Everything passes sandbox testing, but when the deployment goes to production, it fails with cryptic errors — or worse, it succeeds but breaks core processes in the background.

The culprit is often hidden dependencies between new components and undocumented legacy automation. Because test environments don’t fully replicate production, these issues only surface when it’s too late. The result is delayed go-lives, shaken stakeholder confidence, and emergency rollbacks during critical business periods.

Compliance audit failures

Auditors request a full history of changes to a revenue recognition process. But no one can explain why certain fields were updated, who approved specific validation rules, or what a piece of undocumented Apex code actually does. Without documentation and traceability, critical business logic becomes a compliance liability. In industries governed by SOX, GDPR, or similar regulations, this can result in significant financial penalties or legal exposure.

Critical integration breakdowns

A weekend order sync to the ERP fails silently. On Monday morning, finance discovers missing transactions, and marketing realizes that failed data syncs have triggered thousands of incorrect customer emails. Often, the root cause is a retired API version, an outdated third-party connector, or hard-coded credentials that expired without warning. By the time anyone notices, revenue-impacting processes have already been disrupted.

These are just a few of the scenarios where technical debt can can ripple beyond the dev team — disrupting critical processes, eroding trust, and impacting the entire business.

How technical debt impacts strategy and innovation

Technical debt doesn’t just cause firefighting in the moment — it reshapes how teams plan, budget, and innovate. Its long-term impact can quietly slow down progress, drain resources, and make it harder for the business to stay competitive.

The maintenance overhead challenge

Development teams spend a significant portion of their time dealing with the consequences of debt instead of building new features. Simple requests, like adding a field or updating a process, come back with estimates in the range of three to six months because making it safe requires extensive remediation and testing first.

The financial impact

Debt consumes the budget. that some organizations are diverting over 20% of their technology spend away from innovation and toward resolving debt-related issues.

The business agility breakdown

Market opportunities don’t wait. But when every change requires months of technical preparation, competitive responses slow to a crawl. New products, process optimizations, and integrations get delayed or shelved entirely. In extreme cases, the platform becomes incapable of supporting business growth without risky and expensive reengineering.

91�Թ��� transforms debt reduction from project to process

Reducing technical debt means building processes that prevent debt from accumulating in the first place. �ұ𲹰������’s DevOps platform enables teams to make that shift, turning debt management into an integrated part of day-to-day Salesforce delivery.

With 91�Թ��� Code Reviews every proposed change — from Apex to Flows to Lightning Web Components — is scanned for potential risks before deployment. The platform detects governor limit issues, security vulnerabilities, and architectural anti-patterns, while also enforcing consistent naming conventions and flagging missing documentation on Flows, fields, and objects. This proactive approach catches “clicks and code” debt before it reaches production. The same checks apply equally to AI-generated changes — every pull request goes through the same deterministic review, regardless of whether it was written by a developer, an admin, or an AI agent. 91�Թ��� also automatically analyzes component dependencies, revealing all connected items instantly. This eliminates the manual investigation that can turn small deployments into hours of detective work. By detecting missing dependencies ahead of time and visualizing their impact, 91�Թ��� helps teams deploy with confidence, even in complex orgs.

Git-based version control, made accessible to the whole team, creates a single source of truth for every change. With a permanent audit trail and alerts for unauthorized production changes, teams can avoid the documentation debt caused by untracked modifications and stay compliant with ease.

Teams can deploy confidently knowing they can revert instantly if needed, thanks to �ұ𲹰������’s rollback functionality. This reduces Mean Time to Recovery and gives stakeholders the assurance to address long-standing technical issues.

By integrating these capabilities into everyday workflows, 91�Թ��� helps teams reduce existing debt and stop new debt from forming, protecting both delivery speed and long-term scalability.

Eliminate your technical debt with 91�Թ���

Salesforce technical debt is a strategic business issue that impacts agility, compliance, and long-term growth. Addressing that debt requires more than occasional cleanup. It takes a proactive, continuous process that prevents complexity from becoming a barrier to delivery.

With automated dependency analysis, intelligent deployments, comprehensive quality gates like 91�Թ��� Code Reviews, and complete version control, teams partnering with 91�Թ��� can make confident changes faster, while keeping risk low.

and see how integrated DevOps capabilities can prevent debt from building up and reduce investigation time from hours to minutes.

You can also book a demo to see how 91�Թ��� can help organizations like yours scale Salesforce operations safely and sustainably.

But ever since Salesforce released Apex as its programming language in 2006, it’s been clear that “traditional” developers still have a vital role to play. And with hindsight it’s also easy to see the naiveté of imagining that low-code development didn’t need the DevOps practices that have been embraced by the wider engineering world.

In the mid-2010s, third-party Salesforce DevOps solutions began to appear, accelerating awareness and adoption of DevOps practices in the ecosystem. Salesforce itself responded in 2018 with Salesforce DX (“Salesforce Developer Experience”, sometimes just “SFDX” or “DX”).

What is Salesforce DX?

is a set of features designed to make source-driven development easier on Salesforce for traditional developers. It ������’t a set of DevOps tools, but Salesforce DX has helped Salesforce teams adopt DevOps, which was ����������ڴǰ�����’s intention.

Why does Salesforce DX still matter?

Salesforce now has a native low-code offering for DevOps, as it released DevOps Center in 2022. But DX still matters. Salesforce DX ������’t a direct alternative to DevOps tools, but mostly complementary. Some of its features (e.g. scratch orgs) can be used alongside or even within DevOps solutions; other features (e.g. DX format) have been leveraged by other DevOps solutions to be more effective for users.

Is Salesforce DX free?

Yes — all of the Salesforce DX tools covered in the rest of this article are completely free to use. In the past, Salesforce advocated for application lifecycle management (ALM) using org-to-org deployments. But Salesforce now promotes DevOps best practices, including version control and CI/CD, and so it doesn’t currently charge for DX or DevOps Center.

Salesforce DX: tools and features

DX format: a better metadata structure

Before DX, one of the most significant challenges for developers was the relatively unstructured “happy soup” of Salesforce metadata. Because Salesforce was designed for no-code development, the metadata that defines org structure and behavior wasn’t designed to be read by developers or managed in version control (Git). Developers would find themselves routinely working with enormous XML files for many metadata types.

The new DX format (or “source format”), now available as an alternative to the original Metadata API format, is a significant improvement. It breaks down larger components into more manageable subcomponents, and allows for an orderly folder structure — much easier for developers to read and work with. Breaking down large files into multiple, smaller files also significantly reduces the likelihood of merge conflicts in version control, as it’s less likely that developers will be making changes to the same files.

If you still haven’t made the transition to DX format, 91�Թ��� can help. When you’re committing metadata to version control with 91�Թ���, it detects the format you’re using and matches that. If you’re populating a new repository, 91�Թ��� will write the metadata in DX format by default.

Integrated development environments (IDEs) for developing Salesforce

Salesforce has continually improved its no-code development tooling. Creating Flows, Agents, Digital Experiences and more is a great experience. Ultimately though, traditional developers want to work in an integrated development environment (IDE) and have the same great experience.

Before DX, developers had been able to use the IDE based on Eclipse. As part of DX, Salesforce initially released extensions for Visual Studio Code (VSCode), which was fast becoming the most popular IDE among developers. A year later, Salesforce retired the IDE, encouraging developers to use modern, open source tools.

Since 2023, developers have also been able to use in their web browser, matching the VSCode functionality on their desktop. And is now bringing the power of LLMs to coding for Salesforce. Developers can use natural language prompts to generate code, as well as getting suggested auto-completions and improvement for code.

Source tracking your changes in Salesforce orgs

For many low-code Salesforce teams, having a version control system (VCS) is still a relatively new concept and Git workflows can seem daunting. But version control is a fundamental part of how developers work. The vast majority of development teams take for granted that Git is tracking all the changes they make to code, before committing those changes to their feature branch and opening a pull request.

in Salesforce brings that same value to everyone in Salesforce, including no-code developers. Once switched on, it keeps track of new, changed and deleted items in the Salesforce org, removing the need to track all of these manually. It can be enabled across your environments from your Dev Hub.

SFDX and the Salesforce command line interface (Salesforce CLI)

Before DX, developers wanting to use a command-line interface (CLI) for Salesforce deployments were able to use the migration tool, which was based on Ant. Its performance was limited and unreliable, as .

As part of DX, Salesforce released the Salesforce CLI, which brought a significantly improved experience for pushing and pulling metadata between Salesforce orgs and version control. It also includes many other commands to manage other DX features, such as converting metadata to SFDX format.

Originally, the Salesforce CLI used sfdx commands. But with , released in 2023, sfdx commands were deprecated. Salesforce now encourages developers to use the sf commands instead and has to help manage the transition. The sf commands are simpler and more intuitive than the older equivalents. For example, sfdx force:apex:test:run is replaced with sf apex test run. And sfdx force:source:deploy --checkonly --testlevel NoTestRun becomes sf project deploy validate.

Scratch orgs and their use cases

Scratch orgs, so called because they can easily be created “from scratch”, are short-lived (“ephemeral”) orgs. Rather than needing to maintain a long-lived sandbox org for every development task, Salesforce developers can spin up scratch orgs quickly for building and testing in a clean org. You can choose how long each scratch org should exist — up to a maximum of 30 days.

To use scratch orgs, you need to designate a permanent org as a Developer Hub (Dev Hub); usually this will be the production org. You can use definition files to determine the shape of a scratch org and which features it has enabled. Or you can use the feature to base the scratch org on the source org.

Teams with fast-paced development cycles tend to find creating scratch orgs takes more time than they can afford. One workaround is to “pool” scratch orgs: maintaining a supply of several scratch orgs that are available to use, so that developers can grab one as needed and streamline the process. ����������ڴǰ�����’s proposed solution is , which allows you to create new scratch orgs based on snapshots of others — avoiding the need to start again with each scratch org.

91�Թ��� can help you create and manage scratch orgs easily. When choosing environments in 91�Թ��� to deploy between, you have the option to create a scratch org as the target, based on your definition files or Org Shape.

91�Թ��� can also create scratch orgs automatically for you as part of a CI/CD process. You can configure a continuous integration (CI) job to create a scratch org and deploy metadata to it — or validate against it. This saves you the manual effort and waiting time for scratch org creation.

Second-generation packaging (2GP) for modular development

The Salesforce metadata that represents features and customizations easily becomes one extremely complex model, with countless dependencies between metadata items. An unstructured org is harder to understand and develop without running into issues.

Packaging up metadata is a way to achieve a more modular design for logical units of functionality in Salesforce, with separation of concerns between different features. Package-based development is an especially popular approach with ISVs and consultants, who can “build once, deploy anywhere” when it comes to fairly self-contained apps.

Before DX, developers were able to package metadata using a packaging org; this is now known as first-generation packaging (1GP). The most significant limitation of 1GP is that each package and version requires a unique org, resulting in teams maintaining numerous orgs. DX introduced second-generation packaging (2GP), in which version control is the source of truth — not a packaging org. This transition was a key part of the switch to source-driven development. 1GP is still available and there’s no public retirement date, but Salesforce actively pushes development teams toward 2GP.

Within 2GP, there’s a distinction between and . 2GP managed packages are recommended for AppExchange partners, as the apps continue to be managed by the provider. Unlocked packages are recommended for in-house development teams and systems integrators, as the applications are managed by the customer.

Neither 1GP nor 2GP packaging covers all of the metadata types covered by the Metadata API. For example, 2GP currently doesn’t cover any Einstein metadata types, though it does now cover most GenAI metadata types used for Agentforce. Salesforce provides a .

91�Թ��� fully supports deploying unlocked and managed packages. You can filter by namespace to find the relevant packages you want to deploy. 91�Թ��� will compare your metadata between the source and target environments, and show you all differences. You can deploy new packages which will be installed in the target org, or deploy updates to the latest version.

Salesforce DX and DevOps on the Salesforce platform

It’s easy to get confused by Salesforce DX; as we’ve seen, it’s a diverse set of tools and features. But at its core, Salesforce DX was designed to facilitate the workflows used by developers. Many DX features are designed to make Salesforce play nicely with version control. Ultimately, that’s about making it easier to apply DevOps practices to Salesforce, achieving more frequent releases and improving resilience with the VCS as the source of truth instead of the production org.

Teams trying to build their own CI/CD pipeline for Salesforce will generally rely on scripting with Salesforce DX commands, alongside either generic pipeline tooling such as , , or — or automation tools such as , , , and .

Most teams that try the DIY DevOps route end up finding that it’s a full-time job to maintain these toolchains, because they’re always more brittle than expected, and Salesforce upgrades need to be planned for multiple times a year. If your team is working through this dilemma, you may find our “build vs buy” guide useful for why we think investing in 91�Թ��� is the right call. Since 91�Թ��� has integrated DX functionality, it’s not a case of deciding between DX and a DevOps platform.

Salesforce DX tools for everyone (not just developers)

Salesforce DX has been part of the transformation in the Salesforce world from org-to-org deployments to true DevOps practices with version control and CI/CD. And it’s great that DX has ultimately benefited everyone building on the Salesforce platform, not just developers.

Some DX features, like the newer metadata format, are now just baked into development on Salesforce. And DevOps platforms like 91�Թ��� put DX tools into the hands of no-code developers as well, with an intuitive clicks-based UI. Admins can use source tracking, spin up scratch orgs, commit to version control easily and trigger builds, all without needing to touch the Salesforce CLI.

�ұ𲹰������’s DevOps platform brings DX to your whole team. It also provides all the solutions you need to build a modern DevOps process for Salesforce, including smart deployment workflows, automated testing, CI/CD pipelines, backups, observability and more. Try the full platform today on a or get in touch to arrange a personalized demo for your team.

For the behind-the-scenes story of how Salesforce DX was created, it’s also well worth watching this DevOps Diaries podcast episode with Wade Wegner.

Your Salesforce backup is only as good as your ability to restore from it. If you’re rolling out Salesforce Backup this guide will cover the step-by-step setup. We’ll explore what you can do with Salesforce Backup and compare when it makes sense as a backup solution versus when an enterprise-grade platform is the right move.

So, before you assume that just having daily backups is the answer, let’s walk through what Salesforce Backup can do, how best to set it up — and where it quietly leaves you exposed.

What is the Salesforce Backup managed package?

, is ����������ڴǰ�����’s safety net for your data. Sold as a paid add-on, it captures automatic daily snapshots of your org’s records, files, and attachments.

Your backup policy defines exactly what gets protected, including object data, related records, files, and attachments. You can opt for the daily scheduled backup that runs automatically, set up a custom schedule that fits your workflow, or trigger on-demand backups.

If you need to restore, Salesforce Backup can handle a few data recovery flows directly. For more complex restoration processes, you’ll need to export the data from your backup and restore it using other tools. But it’s important to make sure you have the right object-level permissions for the records you’re working with.

Salesforce Backup vs. Data Export: What’s the difference?

If you’re weighing up whether the cost of Salesforce Backup is worth it when Data Export Service is free, here are the key differences to keep in mind:

How does pricing work for Salesforce Backup?

Salesforce charges based on file storage, at . Storage-based pricing is more difficult to predict and budget for, and you’ll need to speak to your Salesforce Account Executive for exact costs to your business.

The importance of backing up metadata as well as data

Salesforce Backup backs up records, files, and attachments, but skips the metadata structure that actually makes sense of all your data. It’s like saving every page from a filing cabinet but forgetting the folders, labels, and tabs. When it’s time to restore, you’ve got all the papers but no system to store them in.

That’s exactly what happens when any metadata has changed since your backup.

Keep in mind that metadata changes constantly. You might back up records when your org was a certain shape, and by the time you go to restore those records the metadata structures for that data have changed.

Backing up Salesforce with Salesforce comes with risks

Having backups stored and managed by Salesforce sounds handy, but it comes with risks. If Salesforce goes down, so does your access to both your live data and your backups. During , orgs relying on native backup were left locked out, right when they needed access most.

So while ����������ڴǰ�����’s native backup can handle the basics of safeguarding records, when complexity increases, it can quickly fall short. If your org needs proper disaster recovery with reliable and quick restoration, Salesforce Backup ������’t best equipped to deal with complex recoveries.

How to install the Salesforce Backup managed package

While most teams will benefit from a more robust backup solution, Salesforce Backup is still better than having no backups at all — and for some orgs, it might be a helpful safety net. If you’re going ahead with the native tool, here’s how to get set up.

Your installation email should arrive 24–48 hours after your Salesforce AE processes the subscription order. This critical email contains your unique package installation link so don’t lose it.

A System Administrator will need to log in and use the installation URL provided in your order confirmation to access the download page for the Salesforce Backup managed package. Select Install for Admins Only, and approve third-party website access for Amazon Web Services (AWS) infrastructure if prompted.

Package installation typically takes 5–10 minutes, but you’ll also need to earmark time for license and permission assignment, AWS setup, IP configuration, and policy creation.

Assign user licenses

Any user setting up or managing Salesforce Backup needs the right license assignments — they’ll need the Backup and Restore User Permission Set License plus a System Administrator profile (or similar).

Assign permission sets

Users will also need the right permission sets. On the relevant user profile again, scroll down to the Permission Set Assignments section, and click Edit Assignments. Find the “BackupRestore” permission set, click Add, then Save.

Assign object-level access

Finally, the user will need the right access to the relevant objects to make sure they can access the data needed. From the Setup page, head to the Permission Sets page. Find “BackupRestore” and click Object settings. Select Edit next to the object you need to assign permissions and assign the level of permissions that the user needs, then press Save. You’ll need to repeat the final step for every object the user needs access to in the Backup app.

AWS setup and IP configuration

To select your AWS region, go to Settings in the managed package, click Region and pick the AWS region that meets your business’s data residency requirements. You may also have IP restrictions, in which case you should for your AWS region to the Login IP Ranges for your user profile.

Establish the OAuth connection by clicking Connect to link your org with backup infrastructure. Test immediately using Test Connection. Common failures include incomplete IP allowlisting, proxy interference, and SSO timeouts.

How to create your first backup policy in Salesforce Backup

In the Salesforce Backup app, first click Create Policy.

Back up objects

When you select an object to back up, related objects will also appear that you can also select — click Save Related Objects. When you’re done, click Enable. Repeat for the other objects you need to back up, then click Activate Policy.

Consider carefully which objects to back up, and resist the temptation to back up everything as it increases the risk of hitting API limits. Not every object represents mission-critical data.

Note that the following can’t be backed up:

• Objects without the fields: CreatedDate, LastModifiedDate, SystemModstamp, LoginDate
• Objects not supported by the Bulk API
• Records stored in Big Objects
• Light Application objects

Back up files and attachments

To back up files and attachments, the integration user must also have the QueryAllFiles permission.

From the “Backup” tab in the app, select Configure Policy Defaults and enable backups for files and attachments. As with objects, carefully consider what needs to be backed up. Adding files and attachments to your backups can significantly increase your storage footprint. Salesforce only backing up files and attachments created within a recent data range. Once you’ve chosen a backup window for files and attachments, click Save to include them in your backups.

See our guide on Salesforce backup best practices for detailed backup strategies.

How to decide between Salesforce backup solutions

When native backups still make sense

Using native backup is better than not having a backup at all, but you’ll need to weigh up whether it can provide everything your business needs. Here are some scenarios where the native offering might be the right fit:

• Simple orgs with minimal customization: If your Salesforce setup is mostly plug-and-play, with standard objects and a few custom fields.
• Stable metadata that rarely changes: Organizations that locked down their configuration years ago and rarely modify fields, validation rules, or workflows.
• Severe budget constraints: When every dollar counts, and manual recovery time is cheaper than software licensing.

When native backups leave you vulnerable

Organizational complexity demands a more sophisticated approach. Here’s when native backups can leave your business exposed:

• Frequent metadata changes requiring synchronized data and metadata backup. If you’re developing your Salesforce org, which almost all businesses are, remember Salesforce Backup only covers your data. 91�Թ��� backs up data and metadata in sync — because what good is one without the other?
• Compliance requirements beyond basic backup. Need to hold onto records for seven years to meet SOX requirements, or abide by GDPR to store data within EU borders? Native backup ������’t customizable enough to keep auditors happy. 91�Թ��� gives you customizable retention options and residency flexibility across the US, EU, CA, and AUS.
• Recovery speed is a high priority. No business wants to suffer data loss and downtime. But the larger the business, the more costly disruption gets. �ұ𲹰������’s backup solution has intuitive restore workflows to minimize your time to recover.

�ұ𲹰������’s enterprise backup solution

�ұ𲹰������’s comprehensive, off-platform and enterprise-ready backup solution is built specifically to handle the complexities of Salesforce data and metadata, so you’re protected when disaster strikes.

Complete org protection

91�Թ��� doesn’t just back up your data. You can back up any metadata types supported by the Metadata API (over 700) — much more than most other tools. Plus, 91�Թ��� has specific support for config data like CPQ and Vlocity, as well as Marketing Cloud. In practice, most backup solutions for Salesforce only protect a subset of your org’s data, and none or very little of the metadata that houses your data and powers your business with automation and more.

Flexible recovery options

Not all data loss incidents are alike, so 91�Թ��� gives you options for restoration:

1. Restore records with dependent objects. For example, if an Account was deleted, this restores the Account plus its Opportunities and OpportunityLineItems, preserving all relationships. This is the most common and safest option for restoring object-level deletions.
2. Restore records with specific fields. This targets and restores only particular fields on records while leaving other fields unchanged. This is ideal for fine-grained corrections, for example if a mass update only corrupts some fields.
3. Restore multiple parent objects with their dependencies. Use this method if you have a solid understanding of your org’s data model and need to recover from large-scale data loss across multiple objects.
4. Quick restore of a single record (without dependencies). A lightweight option to remedy minor mistakes where you just need to restore a record (or few) with no related objects.

Smart alerts and metadata monitoring

91�Թ��� gives you full visibility into how your data changes over time. You can configure smart alerts to fire when thresholds are crossed that represent unusual data changes in your org. You’ll also get reports on metadata changes between each backup run.

Backups alongside other data management tools

Alongside your backups, many teams need options for data archiving, sandbox seeding, auditing and compliance. With 91�Թ��� you can bring all these tools under one roof with similar workflows.

Backup as part of your DevOps lifecycle

Even more broadly, 91�Թ��� treats backups as a core part of DevOps, essential to keeping your orgs operational. You can buy our backup solution as a standalone option, but we recommend managing the whole DevOps lifecycle on one platform, as consolidating tools improves team performance across the board. For example, restoring from backups is much easier when the recovery process feels like the metadata deployment and sandbox seeding workflows your team uses every day.

Off-platform resilience when disaster strikes

With 91�Թ���, your data and metadata are securely encrypted and stored in the same AWS data centers trusted by Salesforce, but on different servers. If Salesforce goes down, you won’t lose your backups with it.

Support that understands Salesforce inside out

91�Թ��� support is run by real humans with in-depth knowledge of Salesforce. And with a 2-minute average response time, the support you need is on hand when disaster strikes. With 84 billion records safely backed up and a 98% customer satisfaction rating, the numbers back it up. Hear from Sage why 91�Թ��� is their trusted backup solution for Salesforce.

Enterprise compliance without complexity

You can set data retention rules that match your business needs. You’re also in control of data residency, with regional options to help you meet regulatory obligations. Every backup and restore is tracked, giving you a full audit trail when you need it.

For compliance with GDPR’s “right to be forgotten”, you can remove specific records from all backups, and maintain an audit trail.

Ready for a complete backup solution with reliable restoration?

Salesforce Backup offers teams a safety net, but it potentially introduces a new risk: a false sense of security.

If your setup is fairly static and your recovery needs are minimal, this lightweight option for native backup might give you enough protection. Daily automated snapshots and in-app restore are far better than relying on weekly manual exports.

But issues like metadata gaps and broken relationship integrity are fundamental design limits that make Salesforce Backup a risky choice for most orgs. When your environment includes regularly changing metadata, intricate dependencies, or heavily used managed packages, a data-only backup leaves too much uncovered.

With 91�Թ���, your backups will protect both data and metadata, so you’re protected across the board. or book a demo.

While ����������ڴǰ�����’s native Data Export Service gives you the data you need in an easily downloadable ZIP file, it’s far from a true backup solution. In fact, most teams don’t realize until they need to recover that it is just an export, not a backup, and they don’t have everything they need to restore successfully.

In this post, we’ll get into exactly what ����������ڴǰ�����’s Data Export Service provides, why the restoration process is more complex than it seems, and how purpose-built backup solutions can turn your recovery process from a multi-day, manual nightmare into a streamlined, automated operation.

What Salesforce Data Export Service actually does

����������ڴǰ�����’s Data Export Service creates CSV files containing the records from your Salesforce org, which are bundled into a ZIP archive for easy download. You can schedule these exports to occur on a weekly or monthly basis, depending on your Salesforce edition:

• Enterprise, Performance, or Unlimited editions allow you to export your data weekly (every 7 days).
• Professional and lower editions limit you to monthly exports (every 29 days).

These export frequencies can mean that you have a Recovery Point Objective (RPO) of up to a month. So consider the frequency of data changes happening in your org and how critical your Salesforce data is to help decide whether a month of lost data is an acceptable level of risk for your business.

It’s important to understand that these exports are not designed to act as backups, and the Data Export Service doesn’t include functionality to restore your data from exported files.

It’s also worth noting that only the data of your org is exported, not metadata — so key configuration elements like validation rules, automation, and custom objects won’t be included in the export file. This can be challenging for restoration because the metadata provides the context for your data. Without it, your data becomes raw information.

You’ll also need to consider the size of your org. Large exports are automatically split into multiple ZIP files (each up to 512 MB). So even if you’re exporting a single object like Account, if it’s particularly large you may end up with multiple files, each representing part of the data. This can mean you’re left with lots of disconnected records — what’s often referred to as “flat data” — that requires substantial manual work to stitch back together, even if parent IDs (e.g., AccountId on Contact) are exported.

Data Export Service vs. Data Loader

Another native tool in ����������ڴǰ�����’s arsenal that can export data is Data Loader.

Here’s a quick side-by-side comparison:

Data Loader requires a deeper understanding of ����������ڴǰ�����’s structure and you’ll need to be familiar with SOQL queries to filter the data you want to extract.

No matter which method you choose, there’s still one major hurdle: the output reality.

When you run the Data Export Service, you’re not getting a tidy, easy-to-restore set of records. Instead, you’ll be left with separate CSV files that contain isolated pieces of your data and scattered parent-child relationships. Your Contacts, Opportunities, and Cases are all linked to Accounts but those relationships are not preserved in your exported files. You’ll have to manually figure out how to tie everything back together when you need to restore your data.

Having CSV files doesn’t guarantee recoverability. You need a modern backup solution that covers both your data and your metadata, and has in-built restoration capabilities to ensure you’re truly protected.

How to use Salesforce Data Export Service: A step-by-step guide

While we strongly recommend transitioning to a more robust backup solution, for teams without a budget for a backup solution or with orgs that change infrequently, Data Export can be better than having no backups at all.

Here’s a quick breakdown of how to set up and run a Data Export, whether for a one-time export or a scheduled process.

Export now: For immediate, one-time exports

1. Navigate to Setup and search for Data Export in the Quick Find box.

   

2. Click Export Now.

   

3. Configure the export:

   • Select the relevant encoding for your export file.
   • Select whether you want to include images, documents, attachments, Salesforce Files, and Salesforce CRM Content. You can also opt to replace carriage returns with spaces.

   

4. Scroll down and choose data scope. For this walkthrough, we’ll tick the Include all data box for a full org backup.

   

5. Click Start Export and wait for the email that notifies you that your organization’s data export has completed. Large jobs may take several hours.

6. Return to Setup > Data Export (or use the link in the email) and press Download on each ZIP file. Save them locally or to secure cloud storage.

Make sure to download your export within 48 hours after receiving the email notification, or you’ll lose access to the export.

Schedule export: For ongoing, automated backups

If you’d rather not manually export your data every week or month, you can set up an automated export schedule:

1. Navigate to Setup > Quick Find > Data Export and click Schedule Export.

   

   • Configure file options in the same way as before — choosing what file encoding you want and whether images, documents, etc. should be included in the export.

2. Define frequency. Keep in mind the maximum frequency of exports is determined by the type of org you have.

   

3. Select data scope. Just like before, for this walkthrough, we’ll check the Include all data box for a complete backup.

4. Click Save.

Now, Salesforce will automatically run your export at the designated frequency.

Why CSV exports aren’t a recovery strategy

When the worst-case scenario hits — whether it’s accidental data deletion, a bad import, or corrupted records — will a bunch of locally saved CSVs enable effective recovery?

Limitations of restoring with raw data

The Data Export Service is archive-grade, not restore-ready. It produces raw data, but without the essential components that make Salesforce function. No metadata, no relationships, and no automation are included. Essentially, it’s just a collection of standalone records that are disconnected from each other. Restoring your org from these files is a massive, time-consuming effort — think 8+ hours just to restore 500 records, and weeks for a full org. And if your metadata needs rebuilding, you can expect it to take significantly longer.

A restore-ready backup is a complete, point-in-time snapshot of your Salesforce org — both data and metadata. It’s designed for rapid, reliable recovery, with relationships intact. When you restore from a modern backup solution, you’re getting more than your raw data back — you’re getting a fully functional Salesforce org.

For example, the same 500 records that would take you 8+ hours to restore manually with CSV exports can be restored in 20 minutes with a modern solution. The process is specifically built to preserve all of the critical components of your Salesforce org, including parent-child relationships between objects.

With a restore-ready backup, you can get your Salesforce org back up and running quickly and with minimal disruption. The complexity of mapping records together, ensuring relationships are intact, and manually reloading data is eliminated.

What you need for quick, successful recovery is a restore-ready backup solution, such as the �ұ𲹰������’s Salesforce-specific backup and restore.

The Recovery Point Objective (RPO) problem

When considering the effectiveness of your data export strategy, it’s essential to think beyond the mechanics of the export itself. RPO is a critical metric for any backup system, and it tells you how much data you can expect to lose during a disaster.

With weekly exports via the Data Export Service, your RPO is up to 7 days, meaning the worst-case scenario could see you losing an entire week’s worth of data. For a company with a significant revenue stream, that can be devastating.

And the problem doesn’t end there. If your export takes several days to complete, you’re not just looking at a 7-day window of exposure — your backup might represent 10-14 days of data loss. In a fast-moving business environment, that’s an enormous risk that could lead to major financial loss, operational disruption, and brand damage.

The manual restoration reality

Unlike a true backup solution that allows for point-in-time recovery with minimal effort, restoring from CSVs requires painstaking work that often feels like trying to put together a puzzle with missing pieces.

Let’s take a look at the restoration workflow you’ll be facing when you rely on CSV exports:

1. Assess the damage: You’ll need to first export the current state of your Salesforce org (which will likely include all the corrupted data) and VLOOKUP it against your backup CSV files to determine what’s missing.
2. Metadata verification: Check that all the necessary fields, custom objects, and relationships still exist. If any metadata has changed since the backup, the restoration will fail, so it will need to be rebuilt beforehand.
3. Disable automation: You’ll have to manually disable all automation (validation rules, triggers, flows) to avoid conflicts during the restore process.
4. Rebuild relationships: You’ll need to manually update the AccountId references in Contact CSVs, mapping IDs across different objects to maintain referential integrity, which typically takes several hours.
5. Test and reload: Once you’ve managed to piece everything back together, you’ll need to test it in a sandbox to ensure that your restore doesn’t break anything. Only then can you attempt to reload your production org’s data, one object at a time, in the correct order.

If that wasn’t complex enough, here are a few hidden challenges that further complicate the restoration process:

• Record types: If your record types don’t match exactly between the backup and the org, the import will fail silently without any helpful error messages.
• Picklist values: If any picklist values have changed since your last export, the new data might be rejected due to mismatched values.
• Inactive user references: If user references in the backup are tied to inactive users, Salesforce won’t be able to restore owner assignments properly.
• Lookup relationships: Restoring objects with lookup relationships is a nightmare because Salesforce requires exact ID matching across multiple files. Missing or incorrect IDs will cause data integrity issues.

Then there is the cascading failure, which is the ultimate risk of manual restoration. For example, if you restore Accounts before restoring the associated Contacts and Opportunities, you’ll break all the relationships between the objects, causing a cascading failure where all related records are lost or incorrectly restored.

If the data ������’t restored in a specific order, it will likely become corrupted in your Salesforce org. This adds enormous complexity and risk to the restoration process, making the challenge of recovery even more complex.

At 91�Թ���, we recommend the following three main steps for Salesforce data recovery:

1. Identify and assess the damage: Determine the cause and scope of data loss. You can use �ұ𲹰������’s automated backup jobs and smart alerts to quickly detect issues, then verify backup integrity.

2. Restore metadata: If metadata (like custom objects or Apex code) is impacted, restore it first. If you’re using 91�Թ���, you can compare backup snapshots with the live environment and selectively restore metadata.

3. Restore data: Again, if you’re using 91�Թ���, you have four restoration options:

   • Restore records with dependent objects (recommended for most cases — restores related child records).
   • Restore records with specific fields (useful when only certain fields are affected).
   • Restore records without dependencies (restores individual records without related objects).
   • Restore records to multiple objects (for complex, multi-object recoveries with filtering options).

   You can access this by clicking the Restore button from .

We also recommend testing the restoration process in a sandbox environment before deploying to production and regularly testing your recovery process to stay prepared.

How modern backup solutions transform recovery

CSV exports protect you from auditors, not disasters. In practice, what you need is a modern true backup solution, like 91�Թ���.

Instead of relying on weekly, export-based backups that don’t include metadata, relationships, or configuration, modern solutions offer comprehensive, continuous data protection, like:

• Off-platform storage: Solutions like 91�Թ��� use the same infrastructure trusted by Salesforce. But 91�Թ��� uses different data centers — so your backups are secure and available even during Salesforce outages.

At 91�Թ���, we’ve designed a comprehensive, purpose-built solution for Salesforce backup and recovery. Unlike CSV exports, which leave you vulnerable to long recovery times, �ұ𲹰������’s Backup & Restore functionality addresses every aspect of Salesforce data protection. You can:

• Capture daily whole-org backups plus hourly high-frequency backups for critical objects.
• See the evolving shape of your data over time with change visualization.
• Use smart alerts that proactively warn when unusual amounts of data change or disappear.
• Leverage DevOps integration that treats backup as part of your complete DevOps lifecycle, not a siloed function.
• Get intelligent restoration capabilities, including automatic relationship preservation, metadata and data restore processes, and flexible restoration flows for different scenarios — from fixing a single field on a record to recovering entire object hierarchies.

That’s why the industry is moving toward purpose-built backup solutions. In fact, of the 87% of Salesforce teams that back up their data, most now rely on third-party backup solutions to protect their orgs. 91�Թ��� alone protects 84 billion records, and with 2-minute support response times, we deliver the maturity and scale needed by modern backup platforms to address ����������ڴǰ�����’s unique structure.

From false security to true resilience

While the Salesforce Data Export Service may seem like a good compliance tool, it falls short as a reliable recovery solution. Accidental data loss, integration failures, and configuration issues can happen at any time, and relying on weekly CSV exports is risky. The potential impact on your organization’s operations, finances, and reputation is too great to ignore.

Purpose-built backup solutions, like 91�Թ���, offer a robust and reliable approach to backup. By capturing both data and metadata, and enabling streamlined, flexible recovery, these solutions ensure your Salesforce org is restore-ready. With point-in-time recovery, automatic relationship preservation, and granular restore options, 91�Թ��� simplifies recovery from hours to minutes, providing true resilience for your org.

Get robust backup and recovery for your org with a or book a demo to see how we can help you protect your Salesforce org and streamline your DevOps workflow.

While Salesforce manages the underlying infrastructure — including servers, availability, and core platform security — you’re responsible for your org’s data and metadata, including all configuration and permissions. If something goes wrong or you get audited, the Salesforce development team will need to be part of the response, not just IT or security.

In this post, we’ll explore why strategies for backup and archiving are essential to operational success in the Salesforce DevOps lifecycle, and how to build them into your processes to stay resilient, compliant, and ready to recover.

What happens in the operate stage?

The DevOps lifecycle is a version of the development lifecycle that covers planning, building, validating, releasing, operating and observing on Salesforce — a continuous process that helps teams deliver faster and more safely at scale.

In the operate stage, your Salesforce org is live and in use. End users are working with the features you’ve delivered, while the development team’s role is to ensure the right processes are in place to maintain stability.

For Salesforce teams, that means managing user access, running backup jobs, and responding fast when something breaks — whether it’s a failed deployment, a permissions issue, or unexpected data loss.

The operate stage is also where compliance matters most. This is where you need processes and audit trails in place to demonstrate compliance in response to any audits or access requests. It’s also important to maintain high data quality and smooth org performance. Archiving plays a key role here — removing obsolete data from the live environment keeps records accurate and systems running efficiently for Agentforce agents who rely on accurate, up-to-date records.

As the DevOps lifecycle is continuous — visualized as an infinity loop — the operate stage ������’t just an end goal. It’s closely related to the observe stage where you understand how well it’s running, using observability tools to detect risks early, surface trends, and plan improvements. Together, the operate and observe stages give your team the real-time control to stay stable and the long-term visibility to evolve.

Why Salesforce backup and archiving are key to staying operational

Operational success in Salesforce depends on your ability to protect data, maintain performance, and recover quickly when things go wrong. At the heart of this are two foundational functions for the operate stage: backup and archiving.

Backing up both data and metadata is vital to being able to restore data after disruptions. With reliable backups, a tested restore process, and a clear strategy in place, the best teams can reduce mean time to recover (MTTR) and build confidence in their ability to respond to issues without major disruption.

Archiving obsolete data improves org performance and helps manage storage costs, while maintaining long-term access for compliance standards and reporting.

Operational excellence means being ready to respond, recover, and improve every time something goes wrong. When backup and archiving are embedded into your daily operations, they reduce risk and create the stability and visibility your org needs.

Who’s responsible for operational success on Salesforce?

Staying operational on Salesforce is a team effort. No single role shoulders total responsibility for how things go in production. For example, admins might configure backup jobs and make sure the right data is protected, while developers might support recovery to ensure data and metadata are restored quickly from backups. Release managers reduce risk by triggering on-demand backups ahead of deployments, and compliance officers ensure retention policies meet regulatory standards.

Because metadata determines the shape and behavior of your Salesforce org, you need your Salesforce team to stay actively involved in the operate stage. They understand how configuration, automation, and permissions interact — and that knowledge is essential when restoring metadata or resolving issues in production.

Learning from real-world Salesforce operational failures

So what happens if you’re operating on Salesforce without backup and archiving in place? You’re leaving a tooling gap in the DevOps lifecycle — one that jeopardizes your development and data security.

It’s impossible to avoid failures completely. Operational excellence means being ready to respond, recover, and learn when things do go wrong. And in the Salesforce ecosystem, things can go wrong. In November 2024, a database maintenance change impacted orgs hosted on some North American and Asia Pacific data centers, leaving some users temporarily unable to log into Salesforce or access its services. A similar incident, in 2016, caused by a database failure on the NA14 instance, was resolved by restoring from a backup and meant that users lost four hours of data.

In May 2019, an accidental permissions change led to “Permageddon” — an incident which briefly exposed sensitive org data and locked users out of critical functions. Salesforce deleted all affected permissions, protecting sensitive data but resulting in some admins needing to rebuild their org’s profiles and permissions manually. In September 2023, another internal permission change blocked customers across multiple clouds from accessing their services for several hours in peak business hours.

These incidents show that while you can’t prevent every disruption, strong backups and tested restore processes are essential for minimizing the impact of data disasters or human error — and for recovering quickly and confidently.

To run resilient orgs, high-performing Salesforce teams invest in backups they can trust, and tools that make restoration fast, reliable, and audit-ready. When it comes to protecting your most critical business data, it pays to be prepared.

What mature Salesforce operations look like in practice

Here are the key areas every Salesforce team should care about if they want to build operational excellence into their DevOps process.

Make sure backups and archives are compliant

Operational maturity means staying audit-ready at all times, and that only works when compliance is built in from the start, not added on as an afterthought. If your data protection practices need to meet GDPR requirements, that means defining clear processes for selective data purging versus retention, automating anonymization where appropriate, and ensuring your archiving policies align with legal obligations.

For industry-specific compliance frameworks such as HIPAA, you’ll need to secure sensitive data through encryption, maintain detailed audit logs for access and deletion events, and follow a clearly defined standard operating procedure (SOP) that retains records for six years. And if your organization is subject to SOX, you’ll need immutable backups and archives, along with quarterly restore drills that demonstrate you can recover critical data on demand when auditors need proof.

Don’t forget metadata backup

Restoring objects and records won’t help if your automation, layouts, or permissions are missing. And even more fundamentally, you can’t restore records to an object if the object itself has been lost or corrupted. Metadata determines how your Salesforce org works, so make sure it’s protected alongside your data.

Ensure consistent backups and archiving with automation

Manual backup processes are hard to keep up with, don’t scale, and leave too much room for error. Automating your backups and archive runs ensures consistent coverage, reduces overhead, and limits the impact of manual errors — without depending on someone to remember.

Test your disaster recovery plan regularly

If you’ve never tested a restore, you don’t really have a meaningful backup process. Set up regular restore tests — typically to a sandbox, not production — to validate your backup strategy, improve MTTR, and give your team confidence to recover fast under pressure.

Improve data quality by archiving legacy data

Archiving is an opportunity to improve the quality and relevance of your live data. Removing outdated or redundant records from the active environment helps ensure that reports, dashboards, and AI-driven tools like Agentforce are working with the most accurate, up-to-date information. Cleaner data means faster queries, more reliable insights, and better outcomes for agents and end users.

Maintain documentation on data management

Document your backup and retention SOPs to build a clear, accessible guide for your backup, archive, and recovery practices. This should cover what gets backed up, how long data is retained, who has access, and how to run a restore — and which service level indicators (SLIs) you track to measure success, like backup success rate or MTTR. Incorporate your disaster recovery and incident response plans here, so the team has a single source of truth when urgent action is needed. A well-documented data archiving strategy ensures your team can manage storage and compliance with confidence.

Measure your operational performance with monitoring tools

Effective planning for the operate stage means identifying the right metrics to track and setting clear alert thresholds. This ensures that failures are detected early and acted on immediately:

• Backup success rate: Are your jobs completing as expected?
• Mean time to restore (MTTR): How long does recovery actually take?
• Recovery Time Objective (RTO): What’s the maximum acceptable downtime?
• Recovery Point Objective (RPO): How much data loss is tolerable and how recent is your last usable backup?
• Anomaly detection lead time: Are you catching data loss or corruption before users do?
• Backup job health monitoring: Are failures being flagged immediately?

These metrics shift your team from reactive to proactive, giving you early warning signs and the insight to improve over time.

5 questions to help embed archiving and backup in your Salesforce DevOps lifecycle

Operational excellence ������’t a one-time setup. By regularly asking the right questions, you can surface blind spots, sharpen your response plans, and keep improving how your team operates.

Here are five questions to help you review your operate stage:

1. When was our last successful restore, and what did we learn? Treat every restore as a chance to validate process and uncover gaps.
2. Are backups triggered automatically in our CI/CD pipelines? Especially for teams deploying larger changes periodically, having regular metadata backups in place means you’ve got a reliable restore point if something goes wrong in production.
3. What is our acceptable RTO and RPO and have we tested them? Recovery time and data loss tolerances are only useful if you’ve validated them under real conditions.
4. Which anomalies did our backup alerts catch this quarter? Alerts should lead to action. Reviewing what was flagged — and how the team responded — helps you figure out your thresholds and prevent future incidents.
5. What process improvements have we made since the last incident? Incidents are opportunities to gather insights and improve. What changed as a result? What’s easier, safer, or faster now than it was before?

Stay operational with 91�Թ���

Because it’s built to support the complete DevOps lifecycle, 91�Թ��� gives Salesforce teams more flexibility, control, and reliability in the operate stage than native tools or point solutions. Here are some of the ways 91�Թ��� supports teams to stay in control in production.

Being off-platform adds resilience

While Salesforce offers native solutions like and , many teams choose 91�Թ��� for greater flexibility, faster data recovery, and a combined approach to backup and archiving. Storing backups off-platform adds an extra layer of security — isolating your backed up data from any issues inside Salesforce itself.

91�Թ��� also offers off-platform archiving, removing the access and automation limitations that come with native tools like Big Objects or . You control how long data is kept, where it’s stored, and who can retrieve it — with no trade-offs on compliance or usability.

Intuitive workflows join up the DevOps lifecycle

Having one system for both release and recovery makes all the difference. 91�Թ��� is a complete Salesforce DevOps platform, combining backups and archiving with release management staples like deployments, version control, CI/CD, code reviews, and monitoring.

During the operate stage, that integration matters — daily backups, org snapshots, and point-in-time restores all live in the same UI your team already uses, so there’s no tool switching or extra overhead. With everything in one place, you get a clear view of org health, audit trails, and change history.

Maximum metadata coverage leaves no gaps in protection

Unlike many solutions, 91�Թ��� backs up all your metadata and data, giving you full coverage across your Salesforce environment. Metadata backups capture your org’s logic and structure — things like Apex code, flows, and permission sets — while data backups cover records like accounts, opportunities, and custom object data. You need both to fully restore functionality and prevent disruption.

This is especially critical in complex orgs where dependencies, relationships, and automation can break without the right metadata in place. As Heath Parks, Salesforce Manager at Cincinnati Works, put it: “A lot of tools can back up your data, but what’s it going to look like when you restore it? That was when the lightbulb went on.”

Operate with confidence

�ұ𲹰������’s predictable, user-based pricing for teams of all sizes means no surprise costs for restores or overage. With one platform covering data and metadata management across the complete DevOps lifecycle, you can also avoid the complexity and extra cost of managing multiple tools for your Salesforce DevOps process. And because it’s built to scale, 91�Թ��� adapts as your business grows, instead of locking your orgs into rigid storage tiers or retention models.

Want to see how �ұ𲹰������’s Backup & Archiving solution works out in the real world? Hear from Jolene Mair, 91�Թ��� DevOps Leader and Salesforce Application Engineer at HackerOne, on the DevOps Diaries podcast. Or if you’re ready to see how 91�Թ��� can transform your backup and archiving strategy, book a demo and take control of the operate stage with confidence.

In this post, we’ll explore what makes Salesforce so central to modern organizations. We’ll also look at the numbers behind its market leadership and why its mix of clouds, apps, and community offers something far beyond a traditional CRM.

Whether you’re building on Salesforce or shaping strategy at the C‑suite level, you’ll find insights here to help you get more from the platform.

What is Salesforce?

is the world’s leading customer relationship management (CRM) platform. The platform enables organizations to connect their teams and deliver unified experiences at scale. It brings together critical business processes in one integrated platform, giving organizations a single source of truth to drive decisions and growth.

According to the IDC (International Data Corporation), in 2024, market share and generated the highest revenue in the CRM market.

For developers, it’s a deeply customizable environment that combines declarative tools with programmatic flexibility, helping you to build, deploy, and iterate at speed. For leaders, it’s the backbone of a strategy that connects every stage of the customer lifecycle, giving you the visibility and agility to drive growth without adding complexity.

Inside the economy and community of Salesforce

When people talk about Salesforce, they’re often referring not just to the CRM, but to the Salesforce Customer Success 91�Թ��� (CSP) — a suite of clouds and services designed to connect every part of your business.

This foundation has fueled the growth of a vibrant, global community. ����������ڴǰ�����’s ecosystem includes developers, architects, admins, consultants, and business users. Known as “Trailblazers”, these Salesforce users master the platform, share best practices, mentor others, and help drive innovation. Programs like Salesforce MVP and events like Dreamforce celebrate and connect the community, sparking collaboration at every level.

And the economic impact reflects that scale. According to IDC, the Salesforce economy is expected to generate $2.02 trillion in new business revenues and create 11.6 million jobs worldwide between 2022 and 2028 (). From in‑house Salesforce developers to independent app builders and consultants, this ecosystem shapes not only how businesses operate — but the careers and communities that grow around them.

The community is also supported by an extensive Partner Network, from consultancies to global system integrators, as well as the AppExchange marketplace, which offers thousands of prebuilt apps and components to extend ����������ڴǰ�����’s functionality.

Why businesses use Salesforce

Organizations don’t just choose Salesforce because it’s popular — they choose it because it brings together the tools, data, and innovation they need to keep growing. Let’s break down why it’s become the go‑to platform for so many teams.

A single source of truth

Instead of customer information being scattered across spreadsheets, siloed apps, or individual inboxes, Salesforce centralizes it into one single source of truth. Customer data, customer interactions, and business processes live in one place, so everyone — from a sales rep to a C‑suite exec — is working with the same, up‑to‑date information. In practice this means fewer errors and less duplication.

91�Թ��� innovation

With three seasonal releases a year, Salesforce continually enhances its suite of clouds. Innovations like Agentforce embed AI into frontline service, surfacing next-best actions and significantly reducing resolution times. This rapid pace delivers increasingly powerful tools — from low-code builders like Flow to robust APIs and metadata-driven development. As a result, the platform evolves with customer expectations, supports emerging channels, and empowers teams to experiment and scale with confidence.

Scalability

Whether you’re a fast‑growing startup or a global enterprise, Salesforce scales with you. You can start small, then extend across different clouds like Sales Cloud, Service Cloud, Marketing Cloud, or even Commerce Cloud as your needs grow — without having to rip and replace systems. Adding clouds as and when you need them means you can evolve your Salesforce implementation at your own pace, while maintaining a unified view of customers, operations, and performance across the board.

What are the Salesforce Clouds?

The broad range of Salesforce clouds are designed to solve different challenges across the customer lifecycle. While the platform includes many specialized solutions, a few stand out as the most widely adopted and impactful. Below are some of the most popular Salesforce Clouds that teams use every day to sell smarter, support customers better, and create more connected experiences.

Sales Cloud

Salesforce Sales Cloud helps teams manage leads, contacts, and opportunities while giving full visibility into pipelines and forecasts. It automates repetitive tasks and supports collaboration, streamlining entire sales processes from lead capture to deal closure.

Service Cloud

Salesforce Service Cloud is built for customer service, enabling personalized support through case management and omnichannel tools. Features like Agentforce help automate routine tasks and guide agents with next best actions, improving response times, and customer experiences. It stretches to customer service reps too, allowing them to benefit from AI‑driven suggestions and case histories, helping them respond with speed and context.

Marketing Cloud

Salesforce Marketing Cloud powers personalized marketing campaigns across email, SMS, social, and ads. Tools for marketing automation like Journey Builder and Social Studio help teams plan, execute, and optimize marketing efforts, ensuring the right message reaches the right audience at the right time. Marketing Cloud includes tools like Marketing Cloud Account Engagement (formerly Pardot), helping B2B teams build smarter lead nurturing workflows and align sales and marketing efforts.

Commerce Cloud

Salesforce Commerce Cloud manages digital storefronts for both B2C and B2B businesses, centralizing catalogs, orders, and customer data. It supports multi-site and multi-language operations, enabling retailers to deliver tailored shopping experiences at scale.

Experience Cloud

Formerly Community Cloud, Salesforce Experience Cloud lets organizations build branded portals and self-service hubs for customers, partners, or employees. It improves customer relationships, enhances engagement, streamlines collaboration, and reduces support costs by securely sharing data and functionality with external users.

Salesforce 91�Թ���

Salesforce 91�Թ��� — formerly known as App Cloud and before that, — is the foundation for building and customizing apps within the Salesforce ecosystem. It supports both low-code and pro-code development, offering AI capabilities and data management tools to help teams create tailored solutions, automate workflows, and extend the functionality of existing Salesforce Clouds. Using AI and automation, ����������ڴǰ�����’s technologies help enhance customer satisfaction and deliver excellent customer service at scale.

With a wide range of Salesforce Clouds, businesses can build their own platform to connect every touchpoint across the customer journey, all while breaking down silos between departments, channels, and regions.

Who uses Salesforce?

Salesforce ������’t just for one type of business — it’s used across industries and company sizes, from startups to some of the world’s biggest brands.

Enterprise adoption

Salesforce is deeply embedded in the enterprise space. In fact, leveraged Salesforce to manage their business relationships in 2022, up from 83% in 2017. Household names like Spotify, Amazon Web Services, Toyota, and Walmart Inc. are among those using Salesforce to connect their data, streamline operations, and stay close to their customers.

SMB adoption

Small and mid‑sized businesses (SMBs) also rely on Salesforce to scale efficiently, automate key processes, and unlock insights they might otherwise miss. Its flexibility means you can start small — a single cloud, a single team — and expand as you grow.

Key verticals and industry clouds

����������ڴǰ�����’s reach spans every industry. From financial services and healthcare to retail, manufacturing, nonprofits, and education, businesses are taking advantage of ����������ڴǰ�����’s industry clouds. These tailored solutions offer pre‑built functionality and compliance features designed for specific sectors, so organizations can accelerate time to value while meeting the unique demands of their markets.

Why DevOps is unique on Salesforce

DevOps on Salesforce comes with its own set of opportunities and challenges that you won’t find on other platforms. Because Salesforce is a metadata‑driven, multi‑tenant cloud-based platform, changes aren’t just code — they include configurations, declarative customizations, and complex dependencies. Traditional DevOps practices don’t always fit neatly into the same mold, so teams need tools and processes built specifically for the Salesforce platform. When done right, Salesforce DevOps gives developers and admins the ability to move fast with confidence, automate deployments, and maintain a clear audit trail — all while protecting that shared single source of truth your business relies on.

Outcomes and how to measure impact

Salesforce delivers measurable results that directly support growth, efficiency, and smarter decision‑making. But to get the most from your investment, it’s just as important to track those outcomes as it is to achieve them.

Organizations that successfully implement Salesforce often start by defining clear objectives and key performance indicators (KPIs). Whether you’re aiming to shorten deal cycles, improve support response times, or boost customer satisfaction, aligning your goals with platform capabilities is the first step. Tools like Salesforce Analytics Cloud (also known as CRM Analytics) help teams visualize KPIs and uncover trends across large datasets.

From there, it’s essential to monitor user adoption both in terms of how teams are actually using Salesforce to capture data, but also how they automate workflows and collaborate. High adoption drives higher returns, with Salesforce reporting a when teams fully embrace the platform.

Tracking productivity metrics like sales velocity or case resolution time can help you see how Salesforce is improving day‑to‑day operations. For example, organizations using Einstein in Slack have saved by automating routine tasks and surfacing relevant insights at the right time.

Finally, a proper ROI analysis will capture the broader financial impact — from (thanks to reduced maintenance and improved system efficiency) to a when data is centralized and accessible in real time.

Measuring the impact of Salesforce ������’t a one‑off task — it’s an ongoing process that helps teams stay aligned, optimize their usage, and demonstrate value to the business.

The future of Salesforce

Salesforce is evolving fast — and three key trends are shaping what comes next: smarter AI, connected data, and more mature DevOps.

AI-driven automation

At Dreamforce 2024, Salesforce launched Agentforce, marking a shift from predictive insights to true agentic AI. Built on the foundations of Einstein and powered by the Atlas Reasoning Engine, Agentforce enables autonomous AI agents to execute tasks independently across sales, service, and marketing.

According to Salesforce, more than 5,000 businesses — including Indeed, OpenTable, and Heathrow Airport — are already using Agentforce to streamline processes and automate customer interactions at scale.

In our latest State of Salesforce DevOps report, respondents expressed excitement around AI, but also flagged concerns around trust, governance, and control. While our questions weren’t specific to Agentforce or Data Cloud, it’s clear that agentic AI is now driving the conversation. And as adoption accelerates, so does the need for new processes that balance autonomy with accountability.

Data Cloud expansion

����������ڴǰ�����’s Data Cloud has become central to how businesses activate real-time data across marketing, service, and sales. It pulls data from across systems and turns it into insights that drive personalized, scalable engagement. With new licensing models and deep platform integration, more teams are adopting Data Cloud as their customer data platform. Salesforce is continuing to expand its capabilities, strengthening its role as a foundation for better automation, smarter reporting, and faster collaboration. The entire Agentforce platform relies on Data Cloud to deliver dynamic, tailored responses — helping businesses create smarter, more connected experiences.

DevOps evolution

As Salesforce becomes more embedded in business operations, DevOps has shifted from being a developer-focused practice to a foundation that underpins the success of the entire business. Teams are waking up to the fact that DevOps goes far beyond adopting source control. By investing in observability to track and understand changes, CI/CD to ship faster, and security and compliance to meet growing audit demands, teams are able to build a complete and robust DevOps Lifecycle. Salesforce DevOps is no longer a nice-to-have — it’s how organizations scale confidently, with visibility and control at every step.

Ready to get more from Salesforce?

As Salesforce continues to evolve, with smarter AI, deeper data integrations, and a growing ecosystem of clouds and tools, the opportunity to deliver real business impact has never been greater. But unlocking that potential takes more than just buying into the platform. It takes the right strategy, the right processes, and the right tooling to support change at scale.

Whether you’re scaling development, improving collaboration, or laying the groundwork for innovation, �ұ𲹰������’s DevOps platform is built to support every Salesforce team — from developers to admins to architects. With powerful tools for automated deployments, testing, backups, and monitoring, 91�Թ��� gives you the visibility and control to move fast, stay compliant, and keep your org stable as you grow. To read more about Salesforce DevOps, take a look at our The State of Salesforce DevOps Report.

In this post, we’ll walk through what Revenue Cloud and Revenue Cloud Advanced are, the key benefits of migrating to RCA from CPQ, and best practices to keep in mind if you’re planning an implementation.

How ����������ڴǰ�����’s revenue management products have evolved

Salesforce Billing and CPQ (Configure, Price, Quote) are Salesforce revenue solutions that have been around for a while, helping to streamline revenue management by automating quoting, pricing, and invoicing directly in your CRM. But as subscription services and usage-based pricing become more common, those tools aren’t keeping pace with modern revenue management. In fact, Salesforce CPQ has now entered End of Sale (EOS), meaning it won’t be sold to new customers going forward — highlighting that CPQ is no longer a strategic priority for Salesforce and Revenue Cloud is the direction they’re steering users towards.

Revenue Cloud, more recently Revenue Cloud Advanced (RCA), supports the more challenging revenue requirements of complex, contemporary businesses.

What is Salesforce Revenue Cloud?

Salesforce is a suite of tools that helps businesses manage the entire revenue management lifecycle from within the Salesforce platform. Revenue Cloud is designed to support quoting and contract generation all the way through to billing, payments, and revenue recognition.

It brings together products like Salesforce CPQ, Billing, and Contract Lifecycle Management, and integrates them with Sales Cloud, making it easier for sales, finance, and operations teams to work together. The goal is to replace siloed systems with a unified revenue process that’s faster, more accurate, and more scalable.

Key features of Revenue Cloud

Salesforce Revenue Cloud combines several core capabilities that work together to support the entire revenue lifecycle. Here’s an overview of the key components:

• CPQ (Configure, Price, Quote). Helps sales reps build quotes faster by automating pricing rules, discount logic, and approval workflows, to reduce errors and improve deal velocity. While the specific CPQ product is being sunsetted, RCA includes CPQ functionality.
• Product management. Centralizes product and pricing data in a unified catalog. Teams can maintain consistent pricing across regions, sales channels, and bundles, while also supporting tailored offers and subscription management.
• Order management. Connects the quoting process to fulfillment, ensuring that once a deal is closed, the order flows smoothly through to delivery. It helps maintain alignment between what’s sold and what’s provisioned, reducing handoff issues between the sales team and operations.
• Automated billing and invoicing. Handles recurring, usage-based, and one-time billing scenarios with configurable schedules and payment terms. This reduces manual billing work and ensures invoices are generated accurately and on time.
• Revenue recognition. Automates how and when revenue is recognized, based on the terms of each contract. It supports compliance with accounting standards like ASC 606, helping finance teams manage deferrals, accruals, and revenue schedules without relying on spreadsheets.

What is Revenue Cloud Advanced?

Salesforce Revenue Cloud Advanced (RCA) is the latest packaging for ����������ڴǰ�����’s revenue management offering and part of their broader Revenue Lifecycle Management (RLM) strategy to automate every stage of the quote-to-revenue process. RCA builds on Revenue Cloud, introducing greater flexibility and better support for complex revenue models like subscriptions, usage-based pricing, and multi-year contracts.

While CPQ and Billing still exist and can be used alongside Revenue Cloud, RCA provides broader revenue management capabilities under a single umbrella designed for today’s more complex sales and finance operations.

RCA vs. CPQ: What are the differences?

Moving to Revenue Cloud Advanced gives you access to a platform that’s purpose-built for more complex revenue processes, and ������’t just adding extra bells and whistles.

Here’s how RCA improves on the traditional CPQ setup:

• Unified data model. Older CPQ integrations are often built on a fragmented data model, where logic, quoting, pricing, and billing run on separate logic and records. This can lead to inconsistencies that need to be manually reconciled. RCA reduces the need for customizations and workarounds with a unified, declarative data model across the entire revenue lifecycle — so teams aren’t maintaining logic in multiple places.
• Flexible pricing strategies. CPQ often requires custom logic or third-party tools to support complex pricing models like tiered pricing or usage-based billing. RCA includes support for advanced pricing configuration out of the box.
• Stronger automation. RCA includes native automation for approvals, renewals, and billing processes, minimizing errors and reducing the time spent manually progressing deals. There’s also automation for revenue recognition scheduling, to help finance teams work quickly while meeting compliance requirements.
• Better integration with finance systems. RCA is designed to connect more easily to Enterprise Resource Planning (ERP) and accounting systems, making it easier for sales and finance to stay aligned without manual reconciliation or middleware.
• Support for multi-channel selling. Whether you sell via direct reps, partners, or self-serve portals, RCA’s multi-channel support makes it easy to manage pricing for sales processes across channels.

RCA is designed for businesses that have outgrown basic CPQ and want a platform that can adapt to changing pricing models, product structures, and contract terms — without the overhead of heavy customization.

Best practices for implementing Revenue Cloud Advanced

A successful Revenue Cloud Advanced rollout relies on more than just getting the tech in place. It’s about setting the right foundations early, so you’re not fixing problems later. Here are a few things that can make a big difference.

Understand current pain points

Before jumping into implementation, take the time to do discovery with end users and understand their current pains. Are sales reps working around the system to get quotes approved? Are finance teams manually correcting invoices because billing logic doesn’t align with contracts? These pain points highlight the gaps that Revenue Cloud Advanced can help address. Identifying them up front gives your team a clearer set of goals to design around.

Review your product catalog

Your product catalog is at the core of quoting, pricing, billing, and renewals, which means poor product catalog management will cause problems fast. If you’ve got duplicate SKUs, inconsistent pricing, or legacy bundles, those issues will carry over to Salesforce Revenue Cloud Advanced. Creating a unified product catalog now will improve the success of your RCA rollout and long-term maintainability.

Align with your finance team

Understanding how a deal moves from initial quote to revenue recognition is critical. Take time to map out each step of the deal cycle including how products are configured, how discounts are applied, when a contract is signed, and how invoices are triggered. This mapping exercise helps identify what manual steps are currently needed, where systems are disconnected or the process is disjointed, and areas where automation can streamline your process.

Map your revenue flows

Take the time to fully map how a deal moves from product configuration to final net price, order, invoice, and cash. This helps you spot gaps and build a process with RCA that supports your real-world business operations.

Start small

Rather than launching across all teams or products at once, roll out to a single product line or region to give your team a chance to test, learn, and adapt before scaling. This reduces risk and provides valuable feedback you can use to improve the broader rollout.

Key considerations for migrating from Salesforce CPQ to Revenue Cloud Advanced

Moving from Salesforce CPQ to Revenue Cloud Advanced offers a lot of value, but it’s not just a quick upgrade. Here are some key areas to focus on, to make sure your implementation is as smooth and successful as possible:

Data migration complexity

Moving from CPQ to RCA is the perfect time to reassess how your products, price books, quotes, and contract data are structured. RCA’s newer data model and flexible object structure give you more configuration possibilities, but they may not align neatly with what you have today. This migration is a good time to clean up legacy data and simplify overly complex pricing bundles or discount rules. But this won’t be quick, so expect to spend time mapping fields and rebuilding key logic in the new system.

Integration touchpoints

Salesforce CPQ setups are often tightly integrated with external systems, like ERPs (e.g. SAP, NetSuite), e-signature platforms, or contract lifecycle platforms. But these integrations are frequently built on top of CPQ-specific configuration which may no longer exist in RCA. RCA introduces a more API-first design that should make integrations more straightforward and easy to manage in the long term, but you’ll need to rework existing configurations during implementation, which can be lengthy and challenging.

Customizations

Legacy CPQ orgs often include a lot of custom logic, such as custom objects to support specific quote workflows, Apex code for pricing rules, or bespoke templates for quoting and contracting.

It’s important to audit your customizations and whether RCA now offers standard features that replace them. In many cases, you should now be able to handle things like tiered pricing, discount schedules, or approval logic declaratively, reducing technical debt and simplifying future changes.

Training and enablement

Even for experienced CPQ users, Revenue Cloud Advanced introduces new concepts and different ways of working. This change will have an impact across teams but particularly for sales ops, finance, and IT who will need to get familiar with new workflows, field mappings, and approval paths. Building in time for thorough enablement and feedback is key for a smooth transition.

DevOps

Implementing Revenue Cloud Advanced brings a lot of moving parts. You’ll need to manage changes to metadata and configuration data — like price books, product rules, and quote templates — that all interact in complex ways. Since these changes often impact customer data or how revenue is tracked, they need to be tested thoroughly and deployed reliably. And because these systems sit at the heart of how the business generates revenue, you’ll want strong version control and rollback options in place.

91�Թ��� for Revenue Cloud Advanced

Working with Revenue Cloud Advanced involves dealing with complex metadata, tightly coupled configuration data, and high-stakes changes that directly impact quoting, billing, and revenue. 91�Թ��� makes RCA deployments straightforward and successful, deploying metadata and configuration in a single package.

Compare your metadata and configuration data across any two environments to quickly see what’s new, changed, or deleted, then build a deployment package in just a few clicks. Any dependencies or issues with your package will be flagged with suggested fixes before you attempt deployment, so you’re not dealing with opaque failure errors and delays. Before deploying, 91�Թ��� will sequence the metadata and configuration in your package, so any dependent items are shipped first — making sure .

Manage Revenue Cloud Advanced with confidence

As Salesforce continues to evolve its revenue management tools, Revenue Cloud Advanced offers a powerful way to streamline and scale complex quoting, billing, and revenue recognition processes. With 91�Թ���, you can deploy Revenue Cloud Advanced changes quickly and reliably, reducing risk and regaining control over your most critical revenue processes — so you can implement and leverage RCA without the headaches.

Want to see it in action? Book a demo with our team of DevOps experts or to experience the difference for yourself.

DevOps Center is ����������ڴǰ�����’s long-awaited fix for a very old headache: the pain of moving changes between environments. As the platform’s official, built-in DevOps tool, it aims to modernize the deployment process, bringing in automated change tracking, visual pipelines, and Git-based version control.

In this guide, we’ll unpack the real wins DevOps Center delivers, flag who it works best for, and highlight where its limits might nudge you toward a more heavyweight solution.

By the end, you’ll have a clear framework for judging whether DevOps Center is the right fit for your team, right now, and as you grow.

The benefits of DevOps Center

DevOps Center is ����������ڴǰ�����’s newer deployment tool that brings version control, automation, and visual pipelines to your release workflow.

DevOps Center marks a big leap forward from the days of using notoriously clunky change sets, bringing basic development best practices into the Salesforce fold. For teams making the switch, especially those accustomed to change sets, there’s an initial period of adapting to new tools like Git. However, the payoff is a clearer, more scalable workflow that provides greater control and collaboration.

At its core, DevOps Center unlocks three capabilities that improve how you handle Salesforce deployments:

1. Git-based version control that lets you manage metadata and changes collaboratively, using a single source of truth.
2. Visual pipeline management that shows exactly where your changes are and how they move between environments.
3. Automated change tracking that logs every tweak across environments — no more mystery spreadsheets or missing components.

Together, these upgrades tackle the worst parts of legacy deployment. Instead of cobbling together change sets and hoping for the best, you finally get some visibility on what’s changing, who’s changing it, and where it’s headed.

Version control integration

Unlike change sets, DevOps Center integrates with Git repos, specifically and . This means your Salesforce metadata is being version controlled, complete with commit history, branching, and a clear who-did-what-and-when trail.

For teams used to tracking changes in spreadsheets (or just crossing their fingers and hoping the dev remembers), this is a game-changer. You can preview changes before deployment, roll back in Git if needed (though not in DevOps Center itself), and finally lock down a real source of truth outside Salesforce. Crucially, it also lets admins commit changes, browse history, and work alongside devs, with no command line required.

One thing to note: while DevOps Center technically supports hybrid workflows, in practice, it’s an all-or-nothing game. Either the whole team works through its interface, or everyone sticks to Git. Mixing methods might be possible on paper, but it’s clunky in reality, and likely to frustrate any developer used to working directly with version control. DevOps Center ������’t built to flex around different workflows.

Visual pipeline management

DevOps Center offers a visual pipeline that maps out your environments and shows how changes move between them. Each stage reflects a real Salesforce environment, so everyone from experienced developers to curious stakeholders can follow the release flow without needing a translator.

This can be a real help during daily standups. No more digging through deployment logs or decoding mysterious change set names. Now your team can see:

• What’s still brewing in development sandboxes
• What’s mid-test in QA
• What’s teed up and ready for production
• Where things are starting to clog up

For release managers used to wrestling with cryptic labels and guesswork, it’s the difference between winging it and having a live dashboard with all the answers.

Automated change tracking

Perhaps the most practical benefit of Salesforce DevOps Center is that it . It keeps an eye on everything happening in your development environments and neatly lines up your changes when it’s time to promote.

Here’s what that means for your average deployment:

• Every picklist tweak, workflow nudge, and permission set update? Logged.
• Dependencies between components? Captured for immediate, directly linked metadata – but deeper, multi-step chains will require manual checks.

For admins who’ve spent entire afternoons wrestling with change sets, these solutions can offer genuine relief.

Which teams thrive with DevOps Center

Getting the most out of DevOps Center is all about finding the right fit. The teams that really make it work tend to have a few things in common:

• They’re small enough to standardize on a single workflow but don’t need the same flexibility as larger teams in terms of pipeline creation and branching workflows (which DevOps Center doesn’t support).
• Their deployments are relatively simple.
• They’re willing to roll up their sleeves and use Git without necessarily becoming Git experts.

It’s important to note that while DevOps Center brings clear wins over change sets, it’s not a natural stepping stone to enterprise DevOps. Treating it as a midway point (i.e., change sets → DevOps Center → enterprise solution) will slow you down. If you know you’ll need the power and flexibility of a platform like 91�Թ���, it’s better to start there. You get a gentler learning curve, and avoid building workflows that make the eventual shift feel steeper than it needs to be.

Small teams making their first DevOps steps

DevOps Center is a solid fit for small teams of 3–5 who’ve outgrown change sets but aren’t quite ready to dive into full-blown DevOps. These teams usually have simple deployment needs, focus on one project at a time, and are happy to standardize on GitHub or Bitbucket Cloud.

The zero-cost price tag is a win… until you factor in the hidden toll: the Git learning curve.

You’ll need a working grasp of Git to get anywhere, and adoption can take months. On top of that, if you grow into needing enterprise features, you’ll have to switch platforms entirely. The time you put into learning DevOps Center doesn’t carry over.

Teams that are comfortable with simple, linear processes

DevOps Center takes a clicks-not-code approach that feels a lot like change sets, so at first, admins might feel right at home. But don’t let that fool you into thinking it’s truly “admin-friendly.” With DevOps Center, you’ll need to wrap your head around to use it properly, whereas 91�Թ��� gives you org-to-org deployment from day one, then helps you build in version control as you go.

If your team releases on a steady, straightforward path through to production (dev → test → production), DevOps Center might do the trick. But let’s be clear: “simple” really does mean simple.

No support for complex sandbox setups (native scheduling, environment sync, conflict detection, etc).

No marathon projects running in parallel.

The second you need a hotfix environment or want to manage feature branches without holding up mainline dev, you’ll find yourself boxed in.

Where DevOps Center runs out of road

Every tool has its limits, and with DevOps Center, you’ll likely hit them sooner than you think. After a few months, most teams have nailed the basics and start testing the edges. That’s when those tiny quirks you once shrugged off .

Critical limitations that become roadblocks

Version control lock-in: The restriction to only integrating with GitHub and Bitbucket Cloud is a non-starter for teams with established DevOps practices. Enterprise orgs running on or are left with an impossible choice: ditch their company-wide version control standard, or walk away from DevOps Center altogether.

No automated rollback: DevOps Center doesn’t offer rollback. If something goes wrong, you’ll need to manually revert the changes in your source control system, then redeploy them to your target environment through DevOps Center. It’s clunky, time-consuming, and leaves plenty of room for human error. So when a deployment fails, you’re not clicking “undo” — you’re elbow-deep, manually unpicking every change.

Pipeline rigidity: DevOps Center can’t back-propagate changes. When you promote to the next environment, your other dev sandboxes are instantly out of step. With no automatic PRs to keep things in sync, teams risk integration headaches and failed deployments.

Manual everything: One of the biggest drawbacks in DevOps Center is not having built-in automation tools for setting up or managing a CI/CD process. Every promotion still needs a manual click. No scheduled deployments, no quality gates, and testing stops at basic Apex runs. It’s a far cry from the streamlined workflows most teams expect.

When you need DevOps done right: The case for enterprise platforms

Having seen both the benefits and limitations of DevOps Center, you need to make a strategic choice for your team, not just for today, but for where you’ll be 6–12 months from now.

If you’re part of a team aiming for reliable, repeatable releases — or already operating at scale with multiple production orgs, parallel dev streams, and mounting compliance pressure — skipping straight to an enterprise platform like 91�Թ��� can spare you the pain of a disruptive platform switch down the line.

DevOps Center may fit your current workflow. But if you’re aiming for DevOps that’s fast, scalable, and futureproof, it’s not the full package.

Three core principles for DevOps done right

Real DevOps rests on three foundational principles that DevOps Center struggles to support:

Breaking down silos through deep collaboration. Enterprise platforms don’t limit you to GitHub and Bitbucket; they integrate with all major Git providers, connect with work tracking systems like Jira, and send notifications through your existing communication channels. Plus, with 91�Թ���, you get even deeper Git integration, so developers can stay fully in flow within their Git environment.

Shifting left to catch problems early. DevOps Center’s generic Git diffs “might flag changes, but they won’t catch Salesforce-specific landmines that can derail a deployment. 91�Թ��� goes further, using smart, Salesforce-savvy comparison engines and to spot and fix issues before deployment.

Delivering rapidly through comprehensive automation. The best CD tools enforce policies, manage permissions and entitlements, and keep your architecture on the straight and narrow. True DevOps means native CI/CD, automated testing, scheduled deployments, and quality gates baked right in. Teams using proper automation, like Intercom with 91�Թ���, can ship releases 3 or 4 times a day instead of struggling with weekly deployments.

Beyond deployment: The complete DevOps lifecycle

DevOps Center covers just one slice of the DevOps lifecycle: basic metadata movement. 91�Թ���, on the other hand, knows modern DevOps ������’t one-and-done — it’s a full relay:

• Plan: Integration with work tracking systems.
• Build: Support for complex metadata types and parallel development.
• Validate: Automated testing, static code analysis, and proactive monitoring.
• Release: True CI/CD pipelines with automatic back-propagation. Intelligent deployment with automatic conflict resolution and easy rollback.
• Operate: Backups and data archiving to protect and streamline production.
• Observe: Real-time error tracking.

This end-to-end approach turns DevOps into a full-blown strategic advantage. Take Pilot Company, for example — they use 91�Թ��� Pipelines to deliver smooth, large-scale releases for 30,000 users, with a process that handles far more than just shuffling metadata around.

The choice between DevOps Center and 91�Թ��� comes down to the trajectory of your organization’s DevOps maturity. DevOps Center can help you take the first steps away from change sets, but it can’t take you where you need to go.

DevOps Center is free on paper, but its hidden costs become apparent when you try to execute the full DevOps lifecycle — from planning through deployment and monitoring. Enterprise solutions cost more upfront, but they deliver end-to-end DevOps capabilities, integrated workflows, and expert support that free tools simply can’t match.

Why 91�Թ��� delivers what DevOps Center only promises

DevOps Center beats change sets — that’s clear. But “better than change sets” ������’t enough. Although DevOps Center offers some short-term relief, within 6–12 months, you’ll likely be dealing with a new kind of bottleneck.

The real question ������’t whether DevOps Center is better than change sets; it’s whether starting with DevOps Center moves you closer to your DevOps goals, or just creates a detour you’ll have to backtrack from later.

Plenty of teams make that first leap only to stall out later, chained to limitations they didn’t see coming.

For teams ready to embrace modern DevOps practices, starting with an enterprise platform like 91�Թ��� allows you to avoid future pain and gain immediate access to the automation, intelligence, and flexibility that make DevOps transformative:

• Deployment success rates leap to over 99%.
• Weekly release scrambles become calm, daily rollouts.
• Fixes take minutes, not hours of painstaking rollback.
• Every team member can contribute effectively, regardless of Git expertise.

Your business needs more than visibility into deployments. It needs delivery that’s fast, automated, and scales when you do. That’s why high-performing Salesforce teams skip the half-measures and start with tools built for the full DevOps journey, not just the first escape route from change sets.

Book a demo see true DevOps in action, or to experience the difference for yourself.

This post explores strategies for handling Apex errors, improving the debugging process, and enhancing overall org performance through proactive Salesforce Apex error monitoring. We’ll walk through how �ұ𲹰������’s error monitoring solution can help teams monitor, catch, and resolve errors before end users even know they exist.

What is Apex code?

Apex is ����������ڴǰ�����’s own programming language, designed for running flow and transaction control statements directly on the platform’s servers. It works hand in hand with the Salesforce API, giving developers the tools they need to shape how data and processes behave behind the scenes.

In practice, you’ll see Apex used to automate everyday business logic, build out custom features that go beyond what’s available out of the box, and generally push Salesforce further to meet specific business needs. It’s a powerful way to tailor the platform so it works exactly how your organization needs it to.

Different types of Apex and why they matter

There are several ways to execute Apex code, and each way behaves slightly differently:

• Triggers: run automatically when records are inserted, updated, or deleted
• Anonymous Apex: executed on the fly in the Developer Console, VS Code, Salesforce CLI, or third-party tools
• Scheduled Apex: runs at specific times you define
• Batch Apex: processes large numbers of records asynchronously
• Queueable Apex: similar to Future Apex, but more flexible and chainable
• Future Apex: runs in its own thread asynchronously when resources are free

Different types of Apex handle errors differently and may trigger different error emails. Understanding these differences helps you interpret errors faster.

What are Apex exceptions?

Apex exceptions are events that occur when something unexpected happens during the execution of your Apex code, disrupting the normal flow of a transaction. They act as signals that an operation couldn’t complete as intended — for example, when a governor limit is exceeded, a record you’re trying to access is null, or a DML operation fails.

It’s worth noting that some governor limits don’t actually throw a catchable exception. Instead, they stop the execution immediately. These limits can’t be wrapped in a try/catch, so it’s worth being aware of them when designing your code.

Salesforce provides a range of standard exceptions (such as NullPointerException or DmlException). Each exception type carries details — like an error message and stack trace — to help pinpoint the cause.

You can also define custom exceptions to suit specific use cases in your org. So instead of relying only on ����������ڴǰ�����’s standard exceptions, you can create your own exception types to represent specific error conditions in your org or business logic. This means the error is handled inside your code and no error email is sent.

Understanding how handled and unhandled Apex exceptions present and how they’re structured is the first step toward building more resilient Apex code and troubleshooting issues more efficiently.

Why Apex errors are a big pain point in Salesforce development

Apex is powerful, but when something goes wrong, it’s rarely obvious why. Errors can leave you in the dark, especially in larger or more complex Salesforce orgs. The biggest issue is that Salesforce doesn’t always give you clear, actionable feedback.

Here’s why teams struggle with Apex errors:

Vague error messages

Apex exception errors are often generic. Instead of telling you exactly what failed, they might simply say something like “Attempt to de‑reference a null object.” Without additional context, developers are left hunting through code and logs to find the real cause. Salesforce also surfaces error messages directly in the UI — but these can be just as vague, like “An unexpected error has occurred”.

Asynchronous complexity

Many Apex processes, such as future calls, batch jobs, or queued operations, run in the background. When errors happen there, they don’t always surface immediately in the UI. This makes them harder to trace and diagnose, especially if they occur outside of a user-triggered action.

Governor limits and hidden constraints

Salesforce enforces strict execution limits to keep multi‑tenant environments healthy. When you hit those limits (too many SOQL queries, DML statements, or heap size), the resulting errors can be abrupt and disruptive — often appearing only after significant processing has already happened.

Impact on users and releases

Unresolved Apex errors can lead to broken automation and frustrating user experiences. While they don’t usually block a deployment outright, they can lurk unnoticed if your tests don’t catch them. That means a deployment might succeed, but the code could still fail when it runs in production. Without robust error handling and monitoring, teams can spend hours digging through debug logs or reproducing scenarios, slowing down delivery and response times.

Apex errors are a big pain point for teams because they’re often hard to see, harder to understand, and time‑consuming to fix — unless you put the right monitoring, coding practices, and troubleshooting strategies in place.

How to check Apex errors natively in Salesforce

To tackle these challenges, Salesforce provides several native tools that help you spot and investigate Apex errors.

Apex exception email notifications

Salesforce automatically sends emails to admins when an unhandled exception occurs in a synchronous transaction, including the exception type, message, and stack trace. These emails are limited in detail and frequency but are an important first alert.

Via the Tooling API

You can query objects like ApexExceptionEvent through the Tooling API to pull error data programmatically. This lets you feed error details into custom dashboards or external monitoring tools.

Salesforce UI error messages

Users may see generic messages like “An unexpected error has occurred,” which offer little context. Correlating these with debug logs or exception emails is key to identifying the root cause.

Apex debug logs

Debug logs capture detailed execution traces, governor limit usage, and stack traces. Filtering these logs helps you pinpoint the exact point of failure in your code.

91�Թ��� events

You can publish error details as platform events for real‑time monitoring. External systems or alerting frameworks can then subscribe to these events to catch issues quickly.

Common Apex errors

Once you know where to look, it helps to understand the types of errors you’re likely to see and how they typically arise. Most Apex errors are runtime exceptions — issues that occur when your code executes. These include common problems like null pointer errors, out-of-bounds list access, unhandled query issues, DML failures, and governor limit violations:

• NullPointerException: Happens when attempting to access a null object or uninitialized variable. Always check that an object or variable ������’t null before you use it.
• ListIndexOutOfBoundsException: Occurs when trying to access an index outside the bounds of a list. Always validate list sizes before referencing indices.
• QueryException: Thrown when a SOQL query doesn’t return the expected data or references invalid fields. Review your query conditions and field access.
• DmlException: Raised when a DML operation fails, such as inserting a record that violates validation rules or required fields. Handle these in try‑catch blocks and validate data before performing DML.
• TypeException: Happens when assigning or casting incompatible data types. Review variable declarations and type conversions carefully.
• NoAccessException: Raised when a user attempts to access an object or field they don’t have permission for, even if their profile seems permissive — check FLS and sharing rules. This only occurs when your Apex code explicitly enforces field or object‑level security.

Some of these runtime exceptions can be caught early with static code analysis or flagged during peer reviews, reducing the chance they make it into production.

Governor limit exceptions

Salesforce enforces strict governor limits to protect overall platform performance. When these limits are exceeded, some will throw a catchable runtime exception, while others won’t — they simply halt execution.

• TooManySOQLQueries: Triggered when a transaction runs more SOQL queries than the limit allows. Optimize your code by batching queries and avoiding queries inside loops.
• TooManyDMLStatements: Occurs when you perform too many DML operations in a single transaction. Combine operations where possible and ensure you’re not running unnecessary DML inside loops.
• Heap Size Limit Exceeded: Raised when your code uses more memory than allowed during a transaction. Limit large collections, process data in smaller batches, and release unused references where possible. This exception is uncatchable.

Trigger-related errors

Triggers can introduce complex behavior when they fire automatically in response to data changes, and without safeguards they can easily cause unexpected failures.

• Recursive Trigger Execution: Occurs when triggers call each other repeatedly without checks, causing infinite loops. Use static variables or custom logic to prevent recursion.
• Mixed DML Operation: Happens when trying to perform DML on setup and non-setup objects in the same transaction (e.g., updating a user and account together). Use @future methods or separate transactions to resolve.

Callout and asynchronous errors

Errors in asynchronous processes or external callouts can be harder to catch because they don’t always surface immediately in the UI or logs.

• CalloutException: Triggered when a callout fails due to timeout, improper request format, or synchronous callout in a non-callout context (like a trigger). Ensure you’re using @future(callout=true) or Queueable interfaces correctly.
• Asynchronous Errors: Can be trickier to debug since they don’t always surface immediately. Monitor logs and set up alerting for unhandled async failures using 91�Թ��� Events or exception email notifications.

Error handling and prevention in Apex

A robust error‑handling strategy ������’t just about catching problems when they happen — it’s about designing your code, monitoring, and following best practices to prevent errors in the first place.

Handle errors gracefully

Use try-catch blocks to manage exceptions gracefully. In Lightning components (Aura and LWC), throw and catch AuraHandledException to return meaningful messages to the UI. Custom error messages that include class names and line numbers make it easier to trace and fix issues.

Apex exception emails are only sent for unhandled exceptions in asynchronous transactions. For example, they’re sent for the first unhandled exception in a Batch, but Salesforce limits them to one email per hour per unique exception and caps them at around 50,000 emails per day. In some async operations, Salesforce may also pause email delivery to avoid rapid‑fire notifications. These emails contain less detail than Flow error emails, but they’re a crucial signal that something has gone wrong behind the scenes.

Apex code optimization to avoid errors

Optimizing your Apex code is a preventative strategy that helps reduce errors and improve overall performance. Batching your operations to handle large datasets efficiently, and reduce SOQL queries by avoiding queries inside loops. Validate data thoroughly to prevent DmlException errors, and simplify your logic for better readability and maintainability. You can also use wrapper classes to standardize how error data is returned, making it easier for teams to collaborate on handling and resolving issues.

Monitor your org for issues

Beyond fixing issues as they arise, monitoring your org for early signs of errors can save time and prevent user disruption. Tools like 91�Թ��� provide observability for Apex and Flow errors. With customizable alerts based on error content or volume, your team can react quickly and collaboratively.

While monitoring is available for up to two orgs by default, scaling this coverage requires contacting support — well worth it for growing teams.

Implement structured logging and analysis

Effective error analysis starts with good logging. Use 91�Թ��� Events for real‑time error tracking and alerting, and build or adopt exception logging frameworks to capture detailed information. Review logs regularly to spot trends and prevent recurring issues. Salesforce can also send Apex exception email notifications for unhandled errors — particularly in asynchronous processing — so make sure email deliverability is configured and the right people are receiving these alerts.

Review code to maintain quality

Regular code reviews help teams catch problems before they reach production. Review SOQL and DML usage, check error‑handling patterns, and assess overall logic to ensure the code is efficient and resilient. Static analysis tools can automate parts of the process, while peer reviews keep quality high and reduce debugging time.

The importance of observability in Salesforce DevOps

Effectively managing Apex errors is a critical part of observability — but it’s only one piece of the puzzle. As your Salesforce DevOps processes scale and you deliver changes more rapidly, your orgs can quickly become riddled with blind spots, undetected issues, and tricky bottlenecks — all of which might impact users before you even know there’s a problem.

That’s where observability becomes essential. It gives you a deeper understanding of your Apex code’s behavior, so you can uncover the why behind failures — not just that they happened — and make smarter decisions when it’s time to troubleshoot.

Why observability matters

Observability helps teams spot issues before they impact users, block deployments, or force a costly release rollback. By monitoring Apex exceptions, runtime patterns, and deployment outcomes, you gain visibility into test coverage, governor limits, and exception trends, reducing failures, and preventing recurring problems.

When errors do happen, observability tools like debug logs, exception reporting, and integrated alerts make it faster to identify and fix the root cause. Shared visibility across development, QA, and release teams improves collaboration and accelerates recovery times.

Resolving errors quickly also protects the user experience, especially in customer‑facing processes or high‑volume data jobs. Observability helps you see performance bottlenecks in triggers, asynchronous jobs, and callouts, helping you keep your org fast and reliable.

Error trends and telemetry inform smarter decisions during sprint planning and retrospectives. By targeting problem areas and refining practices, teams drive continuous improvement while working more efficiently and releasing with greater confidence.

For a deeper dive into how observability supports Salesforce DevOps, our observability whitepaper unpacks its role in helping teams build scalable, maintainable orgs that stay healthy over time.

�ұ𲹰������’s error monitoring solution

�ұ𲹰������’s error monitoring solution keeps teams in control of Flow and Apex errors in their Salesforce orgs by delivering alerts and detailed insights into error patterns. With automatic aggregation and instant notifications, you can rapidly identify, diagnose, and resolve issues, keeping your business processes running smoothly.

Performance dashboard

As Flow and Apex errors occur, key performance metrics are displayed on �ұ𲹰������’s intuitive dashboard, giving you complete visibility over error activity. The dashboard includes:

• A visualization of impacted users and when errors occurred over any chosen time range.
• A breakdown of the most common error types causing Flow errors.
• A list of your top 10 worst Flow and Apex errors.
• Total number of impacted users and error counts across both Flows and Apex.

Spot errors before they impact users

91�Թ��� begins tracking and recording errors from the moment a monitoring job is created and the first error is detected. Flow and Apex errors are plotted across your selected time range, helping you spot trends or spikes worth investigating.

You can:

• Filter errors by date using preset ranges or custom selections.
• Click, drag and zoom across the timeline to quickly focus on a specific period.
• See all your deployments plotted alongside the errors to pinpoint changes that may have caused them.
• Use free‑text search to find any Flow name or Apex component, element, or error type, with the timeline updating dynamically based on your search.
• View total error counts across all Flows and Apex, or drill down to individual errors when applying a specific Flow or Apex filter.

Error results

Errors are grouped by Flow name or Apex category, with expandable sections that reveal detailed breakdowns of error types and instances.

Each group shows:

• First seen: The earliest recorded occurrence within your selected time range.
• Last seen: The most recent occurrence recorded within your chosen time range, again considering when the job was created.
• Users: The count of distinct users who triggered the error (based on the Flow interview’s current user).
• Error count: The total number of recorded instances of the error.

Expanding an Apex group reveals the specific errors and associated namespace or method, along with date information, error counts, and impacted user metrics.

Expanding a Flow group reveals details about problem types and Flow elements, with metrics like dates, counts, and impacted users.

You can also click View errors to access specific error reports, with numbers and percentages shown in relation to that Flow.

Ready to take control of Apex errors?

Apex errors don’t have to slow your team down or disrupt your users. With �ұ𲹰������’s error monitoring, you’ll gain full visibility into Flow and Apex issues as soon as they happen. Get real‑time alerts, track error trends over time, and dive into detailed diagnostics so you can pinpoint the root cause and resolve problems before they impact your business.

Empower your team to work proactively, ship with confidence, and keep your Salesforce org running at its best. Start a 30-day free trial of 91�Թ��� today.

In this post, we’ll break down what Autolaunched Flows are, when to use them, and how they can streamline your background automation.

What is an Autolaunched Flow?

Autolaunched Flows are one of the two main categories of Salesforce Flow and cover a wide range of behind-the-scenes automation. Many of the most commonly used Flow types, like Record-Triggered Flows, Schedule-Triggered Flows, and 91�Թ��� Event-Triggered Flows, are subtypes of the Autolaunched category, because they don’t involve user interaction. Each subtype aligns with a different process type — whether you’re responding to data changes, scheduled events, or custom triggers.

In this blog post, we’re focusing on a specific type of Autolaunched Flow — one that doesn’t have a trigger defined within the Flow itself. These Autolaunched Flows run only when something else starts them manually — such as another Flow, a custom button, custom link, or Apex class — rather than running automatically when a record changes or on a schedule.

Unlike Screen Flows, the other main Flow category, Autolaunched Flows don’t include any user interaction — no forms, prompts, or buttons. They’re designed to do their work silently in the background, which makes them a great choice to run automation for repetitive, logic-heavy tasks that don’t require human input.

What to consider when designing an Autolaunched Flow

Salesforce Autolaunched Flows are powerful — but without careful design, they can quickly become hard to manage or prone to failure. Here are a few key things to keep in mind when building yours.

Naming conventions

Flows are easier to maintain when everything’s clearly named. Stick to a consistent naming pattern, like the . Instead of naming a flow something vague like “Assign Tier”, follow the convention of “Object_Flow Type_Purpose_Flow” to create a name like “Opportunity_SFL_AssignTierFromAmount” that makes it obvious what the Flow does, when it runs, and what object it’s tied to. This also helps to map your Flow logic to your business requirements — so you can clearly see how each variable, condition, or action supports what you want to achieve.

Variables

Use consistent naming patterns and include descriptions that show each variable’s purpose and data type. Only set input/output access when needed — especially for Flows called by buttons, Apex, or other Flows. And make sure variables referencing records use the correct object type and fields to avoid runtime errors.

Security and permissions

When building Autolaunched Flows, remember that session timeouts don’t roll back in-progress Flow interviews. Actions like Create Records will still complete, which can result in unintended data changes if a session expires mid-process — a potential security concern in regulated environments. Autolaunched Flows also can’t filter or sort encrypted fields in elements like Get Records or Update Records. If your automation relies on Shield 91�Թ��� Encryption, this can affect logic accuracy or lead to exposure risks if not handled correctly.

Bulkification

Autolaunched Flows don’t always run one record at a time — sometimes they’re triggered by hundreds at once. That’s why it’s important to build them with bulk processing in mind. Instead of looping through records individually, use collection variables and actions to handle them in batches. Skip the hard-coded IDs, keep loops to a minimum, and make sure your Flow stays well within ����������ڴǰ�����’s governor limits. Bulkifying your Flow keeps it fast, safe, and ready for real-world scale.

How to build an Autolaunched Flow using Flow Builder

Flow Builder is your visual workspace for designing automations — it’s a declarative tool so there’s no code needed.

To find Flow Builder in Salesforce, go to Setup and search ‘Flows’. In the Flows panel, click New Flow. You can also do the same from the Automation Lightning app, just click New to launch the Flow Builder in a new tab.

1. Start a new Autolaunched Flow

Select Autolaunched Flow (No Trigger) and Create to start configuring your Flow.

In this example, we’re building an Autolaunched Flow to streamline follow-up for high-priority Cases. Support agents often create a manual Task to check in a week later. This Flow creates that Task automatically, prefilled with Case details, and can be triggered with a custom button on the Case record.

2. Define input variables

To give the Flow the right context — like which Case it should create a Task for — you need to create input variables. To do this, open the Toolbox and click New Resource. Select Variable as the Resource Type, then define its API name, data type, and whether it accepts input from outside the Flow.

3. Add elements

The next step is to add elements that tell the Flow what to do with the variables. In this scenario, we’re using a Create Records element to build the follow-up Task, using the case and Flow details that were passed in as input variables — such as the record ID (Case ID) and Owner ID, along with any other values the Flow needs to make decisions or populate fields. You can also use merge fields here to personalise the Task, such as including the Case Subject or Customer Name in the Task’s subject line or description.

To add an element, switch the canvas to Free-Form and drag the element onto the canvas from the toolbox. This will open a new window where you can define your element and click Save to add it to your Flow.

4. Connect and save

Once your elements are added, draw a connector from your Start element to your other elements in order to connect the Flow. When you’re done, click Save to name your Flow and give it a description and then click Activate. Your Flow is now ready to be called.

Now that your Autolaunched Flow is built and activated, you’ll need a way to call it — because it doesn’t run on its own. This could be Apex, another Flow, an external system, a custom button, or a Visualforce page that calls Apex to launch the Flow behind the scenes.

You can create a button on the related object (like a Case) that links to the Flow URL and passes in the input variables needed for the Flow to work. This lets users launch the Flow directly from the record page. If the Flow is triggered from a custom button, you’ll also need to make sure the button is added to the relevant page layout so it’s visible to users. You can also use dynamic actions to control when the button appears on the record page — for example, only showing it when certain criteria are met.

Autolaunched Flow limitations

Autolaunched Flows come with the usual Flow quirks — they’re great when they work, but can get tricky when things go wrong. These include a steep learning curve for complex logic, limited version control support, and challenges with bulkification and error handling in large-scale implementations. While Flow is a powerful low-code tool, it doesn’t always offer the precision, flexibility, or reusability that pro-code alternatives like Apex provide.

Here are some more limitations of Autolaunched Flows to keep in mind:

• No screen support: Autolaunched Flows don’t support screens, so they can’t collect or display information during execution.
• Trigger restrictions: While they can be initiated by a variety of events, they don’t support all Salesforce event triggers.
• Lack of support for local actions: Because they run in the background, Autolaunched Flows can’t make use of local actions that interact with the user’s browser session.
• Harder to debug: With no user interaction or UI feedback, debugging Autolaunched Flows can be more difficult — especially if the Flow fails silently or mid-process.
• Dependent on external triggers: Autolaunched Flows don’t have built-in Flow triggers, so they only run when started by something else, such as another Flow, Apex, or a Process Builder.

How to deploy an Autolaunched Flow with change sets

If you want to deploy an Autolaunched Flow with change sets, there are a few key considerations:

• Autolaunched Flows often reference other components like Apex classes, objects, fields, and subflows. With change sets, there’s no automatic way to identify or include these dependencies, you’ll need to track them down yourself and manually add them to the outbound change set. Miss one, and your deployment could fail.
• You’ll also need to be careful with Flow versions. Change sets can only deploy one version at a time, and they always create a new version in the target org. That’s not ideal if your Flow is already active and running smoothly, especially in environments with multiple versions.
• Change sets always deploy Flows as inactive. So even if your Flow is active in the source org, it won’t be active after deployment. You’ll need to log into the target org and activate it manually — something that’s easy to forget and can leave business processes broken until it’s fixed.
• Change sets don’t support destructive changes, so any cleanup of old or unused Flows needs to happen manually in production.

So while the actual deployment process follows the standard change set flow — create your outbound set, add the Flow and its dependencies, upload to the target org, then deploy and activate — the manual effort involved makes this approach error-prone and time-consuming. A purpose-built DevOps like 91�Թ��� can handle Autolaunched Flow deployments more reliably, helping you track dependencies, manage versions, and even deploy deletions safely.

How to deploy an autolaunched flow using 91�Թ���

Deploying Autolaunched Flows is quick and straightforward with 91�Թ���. Its smart problem analyzers, automatic dependency handling, and visual Flow comparison take the guesswork out of deployments — so you’re far less likely to hit errors or miss components. If you’d like to follow along with the walkthrough and you’re not already using 91�Թ���, start a free trial.

1. Select your source and target orgs

Start off by selecting your source and target orgs, then click Compare now.

2. Filter metadata and compare changes

Use the menu on the left to select the metadata types you want to compare. You can create custom filters to target specific types, or use �ұ𲹰������’s default — which covers the most commonly updated metadata, including Flows.

In the comparison list, choose the Flow you want to deploy. �ұ𲹰������’s Flow Navigator will display the Flow just as it looks in ����������ڴǰ�����’s Flow Builder, with any changes highlighted, and you can easily toggle back to view the XML.

91�Թ��� will flag metadata changes that relate to your Flow — such as:

• Apex classes that call or are called by the Flow
• Custom fields used in Flow conditions or record updates
• Email templates or custom labels referenced in Flow actions
• Permission sets that control access to objects or fields touched by the Flow

Selecting these alongside your Flow ensures all dependencies are deployed together. Once you’re happy with your selection, click Next to continue.

3. Review your Flow deployment with �ұ𲹰������’s problem analyzers

�ұ𲹰������’s advanced analyzers scan your deployment for issues like missing dependencies or static code analysis failures. There are also dedicated problem analyzers for Flows. If any problems are found, 91�Թ��� suggests fixes you can accept with a click without rebuilding your package. Once you’re happy with your Flow’s deployment package, continue to the Pre-deployment summary.

4. Deploy successfully

In the deployment summary, you can give your deployment a friendly name and description to help your team keep track of changes. 91�Թ��� lets you link the deployment to a user story ticket so you get full traceability and your team can easily see what’s changing and why.

And never get caught out by forgetting manual Flow activation — simply toggle on Flow activation to automatically activate your Flow once it’s in your target environment.

Once you’re done, click Deploy now to release your changes.

Catch autolaunched Flow errors proactively

�ұ𲹰������’s Flow error monitoring gives your team full visibility into failing autolaunched Flows — so you can catch issues early, before they affect business processes or user experience.

Whenever an error occurs, 91�Թ��� automatically logs the failure with all the context you need: the Flow name, error message, triggering record, and timestamp. Instant alerts and detailed error logs appear directly in the 91�Թ��� UI.

Built for admins and developers, this feature helps you troubleshoot quickly — no digging through debug logs or relying on user-reported issues. And with historical tracking and trend insights, you can spot recurring problems and strengthen your automation over time.

Launch into better Flow deployments

Autolaunched Flows are great for background automation, but getting them deployed without errors can be tricky. With 91�Թ���, you can build, test, and release Flows that work like you want them to.

Ready to deploy Autolaunched Flows with ease? Start a of 91�Թ��� today.

But here’s what many teams discover too late: DevOps Center requires you to adopt version control (Git) from day one. For teams already struggling with change sets, adding Git to the mix creates another technical hurdle to overcome. And even after you clear that hurdle, you’ll soon find DevOps Center has its limitations.

This is where a platform like 91�Թ��� offers a different approach. Yes, it costs money. But it lets you escape change sets without forcing you into version control before you’re ready. You get immediate improvements to your deployment process, plus the capabilities that DevOps Center lacks to take you all the way to full DevOps adoption.

Understanding these trade-offs upfront helps you choose the right path for your team’s current skills and future needs. Some teams are ready to make the jump to DevOps Center, and don’t see a current need for the functionality it lacks. Other teams need the immediate impact of a deployment solution that doesn’t require version control from day one. They benefit from a gentler learning curve for DevOps. And they foresee needing the expanded feature set that paid platforms provide, so they can keep scaling and improving their performance. The best choice depends on where your team is now and where you want to be.

Yes, Salesforce DevOps Center is free — here’s what that really means

DevOps Center is genuinely free for Professional, Enterprise, and Unlimited editions of Salesforce.

Salesforce DevOps Center brings some much-needed improvements over change sets, such as change tracking, Git integration, visual pipelines, and work items that bundle up changes into logical units. However, it’s not a magic bullet that solves every challenge out of the box. It comes with some noteworthy limitations that will most likely prevent you from getting the most value out of Salesforce:

• Limited support for version control systems: DevOps Center works with and (though support for the latter is currently a beta service), but it doesn’t support , , , or other version control systems. If you’re already using one of those unsupported providers, switching to GitHub just so you can integrate your VCS with Salesforce DevOps Center means reconfiguring your setup, which is far from ideal. If you’re not using a version control system yet, you’ll need to choose GitHub.
• No automated rollback: If a deployment goes wrong, DevOps Center doesn’t offer an automatic way to roll things back. You’ll have to fix things manually, wasting a lot of time and increasing the risk of errors.
• No backup capabilities: There’s no built-in backup or restore functionality in DevOps Center. In a worst-case scenario, releases can cause data or metadata loss, and with DevOps Center, you’re on your own unless you set up a separate backup system.
• Lack of relational data deployment: While DevOps Center supports metadata, it doesn’t handle data deployment. If you need to move customer records or config data (like CPQ) along with your code, you’ll need a separate data deployment tool.
• Limited CI/CD automation: DevOps Center has begun introducing automated testing, but overall the automation options are limited for achieving continuous delivery.
• ALM and project management integrations: DevOps Center doesn’t integrate with popular Application Lifecycle Management (ALM) tools like or . This massively complicates work tracking and coordination, especially as your team grows and adds specialized roles like release managers or QA testers.

Given these limitations, DevOps Center might be free in terms of upfront costs, but there are hidden costs you need to consider.

• Your version control provider (GitHub seats are $4–21/user).
• Integrations with third-party tools for the full DevOps lifecycle.
• The disruption caused by manual workarounds for rollbacks.
• A backup solution — or the loss of data and metadata that’s not protected with backups.
• The time wasted troubleshooting failed deployments.

These costs are particularly challenging to budget for. GitHub pricing scales with team size, integration costs vary by vendor and (sometimes) usage, manual workarounds eat up unpredictable amounts of developer time, and failed deployments can trigger emergency fixes at any moment. Unlike a fixed subscription fee, these variable expenses make it nearly impossible to forecast your actual DevOps spending.

Now, compare that to using a powerful Salesforce DevOps platform with a predictable and transparent pricing structure, such as 91�Թ���. You’ll be paying $200–$300 per user for our deployment solution, with proven ROI for time savings. As you prove the returns for your business and decide to invest further, you can pay for the functionality you need across the entire DevOps lifecycle: CI/CD pipelines, automated testing and code reviews, data backups and archiving, data deployments, error monitoring, and more.

DevOps Center is still a relatively new entrant to the Salesforce DevOps landscape — it still lacks the key features most teams will need. As such, Salesforce is offering DevOps Center for free to encourage teams away from using change sets towards modern DevOps, even while they continue its early development.

Salesforce is actively developing DevOps Center (with , for example), but progress has been slower than expected. As we’ve explored, the platform still lacks support for widely used version control systems, automated rollback, and CI/CD automation. These are not coming anytime soon, according to .

Looking ahead, it’s unclear whether Salesforce will introduce premium tiers for more advanced functionality, and if so, when. So, while DevOps Center is free for now, it’s important to realize that its “free” status could change in the future. As your team’s needs grow, the platform’s limitations might start to hold you back, so it’s worth considering potential future costs and what you might need to fill in the gaps.

When free actually works: Success scenarios

Despite its limitations, Salesforce DevOps Center can be a great choice in the right scenarios.

If you’re a solo developer or a small team of 2–5 developers working on straightforward Salesforce projects, DevOps Center may be more than enough. This is especially true if your team:

• Is already using (not GitHub Enterprise Server) and is comfortable with basic Git workflows.
• Is moving away from change sets, but doesn’t yet need more advanced functionalities like automated rollback or CI/CD pipelines.
• Doesn’t require complex configurations, such as CPQ.
• Doesn’t deal with heavy compliance requirements.
• Works with basic, straightforward metadata deployments and no complicated data handling.

Setting up Salesforce DevOps Center is also a relatively straightforward process. Here’s a quick rundown:

1. Go to the Salesforce Setup page and search for “DevOps Center” using the Quick Find.

2. Toggle Enable DevOps Center to “on”, then click Install Package.

   

3. You can install DevOps Center for admins only, all users, or specific profiles. Click Install for All Users and click Install.

   

   You’ll need to approve third-party access from other Salesforce domains.

   

   It’s normal to get the notification, ”This app is taking a long time to install. You will receive an email after the installation has completed.” The notification usually comes through a few minutes later.

   

4. After installing DevOps Center, search “Installed Packages” in Quick Find and check that the DevOps Center package is listed on the Installed Packages page.

   

5. DevOps Center needs a connected app to appear in App Launcher. To create a new connected app, search for “External Client App Manager” and select the Settings page. Turn on Allow creation of connected apps, if it’s off.

6. Click New Connected App, then fill out the details for DevOps Center, following if needed. Then click Save.

   

7. From the Manage Connected Apps page, click Manage, scroll down to Permissions Sets and click Manage Permission Sets. Assign sf_devops_NamedCredentials for DevOps Center users, then click Save.

8. Search for “Session Settings” and make sure the box for “Lock sessions to the IP from which they were originated” is unchecked.

By this point, you’ve just successfully installed and configured DevOps Center — congratulations! Now, you can set up your first project. You can do this by going to the App Launcher, searching for “DevOps Center”, launching the app, then clicking the New Project button in the top right corner.

The first time you create a project, you’ll need to authenticate with GitHub. Click Connect to GitHub and provide your GitHub credentials. After successful authentication, enter the project details, then click Save to create the project.

You can then move on to setting up your deployment pipeline and creating work items.

The three obstacles you’ll hit (and when)

Let’s take a closer look at the common challenges teams face as they grow and why DevOps Center may eventually hit a wall as your organization expands.

Obstacle #1: Teams with other version control systems are locked out

As we explained earlier, DevOps Center won’t support any version control system other than and Bitbucket Cloud. This creates a significant roadblock for teams already relying on other Git hosting providers, and locks out teams using self-hosted platforms like GitHub Enterprise Server for security, compliance, or other organizational requirements. In this case, organizations are left with three options:

• Switch to GitHub — a major undertaking with lots of organizational friction.
• Build their own custom CI/CD pipeline to handle the integration with their version control system — an option that’s difficult and costly to set up and maintain.
• Look for a more robust DevOps platform that supports all major version control systems without restrictions.

Obstacle #2: Deployment failures and no rollbacks hamper performance improvements

Salesforce DevOps Center provides basic pre-deployment validation only, making it possible for issues to slip through the cracks. This lack of automated detection puts the onus on you and your team to catch errors manually, which can lead to some major headaches.

As a result, deployments frequently fail, undermining your release velocity and the ROI of your Salesforce investment. You’ll need to dig into the details yourself to figure out what went wrong, which can turn what should be a 30-minute task into a time-consuming investigation. Deployment failures are a barrier to increasing release cadence and reducing the time spent on release management.

What’s more, the lack of rollback functionality means even more time spent unpicking deployments that cause a regression. When a deployment goes wrong and things break in production, you’ll need to manually undo the changes in your Git repository, then redeploy the previous version.

91�Թ��� uses 70+ problem analyzers to catch issues before they become failures, helping customers achieve a deployment success rate of 99%.

Obstacle #3: Lack of automation functionality prevents mature CI/CD

Once teams have built their release pipeline around version control, the next step is to add automation and work towards continuous delivery. DevOps Center lacks the tools and functionality needed to make this ambition a reality.

91�Թ��� automates testing, code reviews, pull requests, and back propagation to keep environments in sync. There’s flexibility for the branching and pipelines setup, so your team can release on the cadence that’s right for you and be confident in every deployment to production.

Your breaking point checklist

This checklist will help you identify the signs that you’re nearing your breaking point and whether it’s time to make a change before things become too difficult to manage.

• 91�Թ��� requirements: As we explained earlier, DevOps Center is tied specifically to GitHub.com and Bitbucket Cloud. If your team uses GitLab, Azure DevOps, GitHub Enterprise Server, or any other version control system, you simply can’t use DevOps Center. Unlike the other limitations that become problems as you scale, this one stops you before you even start.
• Team size trigger: If your team grows beyond 3–4 developers, you may begin to run into issues coordinating workflows, tracking changes, and keeping everyone aligned.
• Deployment complexity: When your deployments involve complex objects, advanced configuration, or large amounts of data, DevOps Center doesn’t provide the tools you need to handle these more sophisticated use cases. Things like CPQ configuration, Industries DataPacks, or complex metadata require specialized tooling.
• Compliance demands: Salesforce maintains an extensive set of compliance certifications that apply to its core services, including DevOps Center. However, organizations working in regulated industries (such as finance, healthcare, or government) still need to supplement DevOps Center with additional tools, audit trails, and robust security certifications to fully meet their specific compliance requirements.
• First production failure: It’s extremely frustrating when you experience a deployment failure in production and realize that you have no automated rollback option. Without a quick recovery mechanism, your team will be forced into the stressful and error-prone process of manually undoing changes, which can severely impact your credibility with stakeholders and clients.

DevOps Center alternatives: two paths to explore

Path 1: Maximize free tools and platforms

This path is best for technically-savvy teams that have experience with the , aren’t afraid to get hands-on with scripts, and are comfortable managing their DevOps workflows with minimal automation.

This includes:

• Leveraging for basic automation of CI/CD tasks.
• Building your own backup and rollback systems.
• Optionally using Salesforce DevOps Center for admins, but it’s not required.

Obviously, this approach requires a significant amount of manual work to keep things running smoothly. You’ll be dealing with manual fixes for deployment failures, managing external backup systems, and using custom scripts for more advanced CI/CD automation.

The DIY approach might seem cost-effective at first, but teams often discover they need a full-time developer just to manage and maintain their custom DevOps setup. Every time Salesforce releases a platform update (which happens three times a year), your entire workflow and toolchain need to be readjusted and updated. Scripts break, integrations fail, and someone has to drop everything to fix them.

With 91�Թ���, these Salesforce updates happen seamlessly in the background. You won’t even notice when changes roll out because �ұ𲹰������’s team handles all the compatibility updates for you. What starts as a “free” solution often becomes one of your most expensive hidden costs when you factor in the salary of the developer maintaining it all.

Path 2: Graduated platform adoption

This path is ideal for growing teams or those hitting the limits of Salesforce DevOps Center’s capabilities.

If your team is experiencing growing pains or if you find that manual processes are starting to slow down your deployment cycles, it’s time to consider a more powerful DevOps platform.

Rather than a free tool with limitations that require multiple workarounds, paid platforms provide complete functionality with predictable pricing. With a platform like 91�Թ���, you get capabilities that go far beyond what DevOps Center offers:

• Comprehensive CI/CD automation with visual tracking and automated org synchronization
• Automated code reviews to catch quality and security issues before they reach production
• Robust backup and restore for both data and metadata
• Flow and Apex error monitoring and analysis

This saves you time, reduces risk, and ultimately maximizes your Salesforce investment.

If this path sounds right for your team, don’t hold it off until it’s too late. You might be thinking:

• “Salesforce will fix its limitations eventually.” Based on , key limitations like GitHub Enterprise Server support and automated rollback are not in the pipeline. Additionally, Salesforce expects partners to fill these gaps, which means it’s unlikely that these critical functionalities will come soon.
• “We can just use DevOps Center until we outgrow it.” Migrating to a new platform later on can be costly and time-consuming. Planning for this transition ahead of time ensures that you aren’t stuck trying to change systems when you’re already facing complex deployments.
• “Our deployments are simple.” Deployments rarely stay simple. As your team grows and your Salesforce environment becomes more complex, you’ll quickly hit the limitations of DevOps Center.

Your business is spending a lot of money on Salesforce, which can make it hard to justify additional spending. But the value of investing in a platform that lets you get the most out of Salesforce cannot be overstated.

And with a platform like 91�Թ���, the ROI you get far exceeds the initial costs. According to our State of Salesforce DevOps 2024 report, 60% of teams with a unified DevOps process report monthly Salesforce ROI of more than $20,000, which is twice as much as teams with split processes. And you can see similar success stories among many 91�Թ��� users, who have reported significant reductions in deployment time and a decrease in the reliance on outsourced resources:

• Veolia UK & IRE saw at least 500% ROI in the first year by reducing development time by 100 hours every two weeks, and cutting costs on outsourcing by £3,000 per week.
• UCLA’s Salesforce team saved up to 75% of their deployment time, cutting a two-week process down to one week or less.
• Granicus reported that their team “got hours back in our lives,” with one manager personally saving 3-5 hours every week because of deployments taking less time.

Making your decision: What’s your move?

The cheapest platform ������’t always the most cost-effective in the long run. DevOps Center is free, but it won’t take you all the way to a mature DevOps process. Investing in a platform like 91�Թ��� is the more strategic choice if you’re really serious about streamlining your Salesforce development.

With 91�Թ���, you get a solution that grows with your team, supports all Git platforms, and streamlines every part of your DevOps lifecycle.

If you’re ready to see how 91�Թ��� can specifically address your needs, book a demo now. Let’s talk about your current process and how 91�Թ��� can help your team make smarter, faster, and more reliable deployments.

And to find out firsthand how 91�Թ��� can transform your Salesforce DevOps processes and deliver a higher ROI, .

In our latest State of Salesforce DevOps report, we asked professionals in the Salesforce ecosystem about their view of AI adoption: the current state of play across their businesses, the barriers to uptake, and the appetite for the opportunity presented by new AI models.

AI enthusiasm outweighs reluctance

New and disruptive technology always has the capacity to provoke a mixture of excitement and concern, and the arrival of generative AI has been no exception. But the data from our survey is clear: individuals and businesses alike are accelerating their AI adoption.

• 86% of respondents are exploring new use cases for AI in 2025
• 37% plan to optimize existing applications of AI
• Just 9% report pulling back on AI in some areas

The adoption of AI is grassroots

The sentiment towards AI among Salesforce professionals is broadly positive, and one of the most striking findings is the grassroots nature of AI adoption. Many Salesforce professionals feel that they’re ahead of their team in using AI — and that their team is ahead of the wider business.

• 61% of respondents personally use AI in their work
• 41% report team-wide adoption of AI
• 37% report AI-driven business initiatives

This suggests that developers, administrators, and team leads are often the early adopters of new technology, experimenting with generative AI tools and techniques in their routine tasks, which then gradually influences their team and business-level strategies. Some respondents even questioned whether their wider business would catch up at all — highlighting a growing gap between early experimentation and broader strategic commitment.

To harness this grassroots momentum, IT leaders should create a clear AI strategy, communicate it widely, and put the right guardrails in place to maintain security and compliance.

The rate of AI adoption varies considerably by industry. Among respondents working in tech firms, 34% report business-wide uptake. In contrast, no respondents working in government reported adoption at an organizational level. This difference reflects the differing regulatory environments, risk appetites, and strategic priorities across sectors.

The hurdles to AI adoption

While individuals, teams and businesses are adopting AI at pace, there are still hurdles to overcome. Security, compliance, and cost are three major barriers. But just as often, the real barrier is that teams simply don’t have a clear use case. For almost one fifth of respondents, the biggest blocker for AI adoption is that it’s a solution in search of a problem — a powerful tool that doesn’t immediately resolve the pressing challenges they face.

The pace of AI adoption is fairly consistent across small, mid-sized, and large companies, but the hurdles are very different for an SME compared to a global enterprise. For organizations with fewer than 500 employees, cost is the most common hindrance. Whereas for enterprises with more than 10,000 employees, compliance and security concerns become the dominant factors.

Salesforce AI adoption: how the platform has evolved

For the last few years, Salesforce has been investing heavily in AI capabilities designed to improve everything from customer engagement to sales team productivity. It began with generative AI technology opening up AI-powered customer insights, and has evolved quickly to ����������ڴǰ�����’s vision of a “digital workforce” increasing productivity thanks to agentic AI.

Salesforce Einstein GPT: new generative AI capabilities

Salesforce unveiled Einstein GPT at TrailblazerDX in 2023, showing how the generative capabilities of large language models (LLMs) could provide writing assistance for specific tasks such as drafting emails or product descriptions. Marketed as AI Cloud for the Salesforce CRM, Einstein GPT promised AI-powered insights based on access to real-time data for every employee — without the need for custom code.

A blend of publicly available AI models and ����������ڴǰ�����’s private AI models helped Einstein GPT to provide clear business benefits. Sales and marketing departments could increase productivity with the ability to generate personalized content tailored around customer data. Customer satisfaction could be improved thanks to an overhaul in customer experiences, with conversational AI assistants quickly providing accurate responses to natural language prompts.

Einstein Copilot: Data Cloud and dynamic grounding

In 2024, Salesforce took things forward by releasing Einstein Copilot. With Data Cloud, it became possible for a company’s customer data to be available for use by AI, while maintaining strict data governance — combining the power of LLMs with live CRM data. With Prompt Builder, teams could create prompt templates for their users, bringing greater consistency and quality to AI prompts. With Einstein Trust Layer, Salesforce bolstered security and compliance for customer data, while dynamic grounding enhanced the relevance of AI-generated content.

Agentforce: the rise of AI agents

At Dreamforce 2024, Salesforce launched Agentforce — introducing agentic AI to the platform. Built on the foundation of Einstein, but with the addition of ����������ڴǰ�����’s Atlas Reasoning Engine, Agentforce agents can execute tasks independently.

Our State of Salesforce DevOps survey questions on AI weren’t specific to Agentforce, Data Cloud or Einstein GPT, but within the Salesforce ecosystem Agentforce is clearly where there’s momentum. Since the survey ran, the adoption of AI agents among Salesforce customers has only accelerated.

According to Salesforce, more than 5,000 businesses — including Indeed, OpenTable, and Heathrow Airport — are using Agentforce to automate customer interactions and streamline processes.

Challenges for agentic AI on Salesforce

Data quality and availability

AI is only as good as the data it ingests. There’s the obvious problem that AI will retrieve wrong information from bad data. But analyzing data sets for trends and intelligent insights also becomes meaningless if some of the data ������’t reliable. As a result most teams will need to spend time on data cleansing, removing historical data and inaccurate records from their data sets, and making sure the remaining data is structured and accessible for AI to use effectively.

On the Salesforce platform, Data Cloud plays a key role in helping businesses securely pull together data into a unified structure. 91�Թ��� supports deploying Data Cloud metadata, so you can set up Data Cloud as a solid foundation for AI success.

Security and compliance concerns with customer data

It’s vital that AI doesn’t undermine customer trust. Einstein Trust Layer helps protect customer information on the Salesforce platform. But businesses also need to invest in data management and ensure that sensitive data ������’t compromised while AI agents are being built, tested and deployed between environments.

Agentforce and deployments

Building and deploying agents comes with its challenges. Agentforce metadata can be complex, using JSON, XML, and prompt markup, as well as new metadata types having dependencies on classic types such as Flow and Apex.

�ұ𲹰������’s solution for Agentforce deployments makes it easy to deploy agents quickly and safely through testing environments and on to production. Our dependency mapping and problem analysis helps you include all necessary components for successful deployments. And our precision deployments let you select and deploy granular changes, without overwriting anything else.

91�Թ��� brings Agentforce into your DevOps workflow, so you can manage GenAI metadata types just like any others and deploy AI agents with confidence.

AI in DevOps: the wider picture

Software development teams are presented with a dizzying range of possible options for leveraging AI across the software development lifecycle. AI-assisted coding means developers can now get more expansive code suggestions in their IDE. AI can play a role in improving code quality, highlighting code issues and security vulnerabilities. Intelligent insights can be surfaced throughout the development cycle with automated testing, mitigating human error. Continuous monitoring with AI has the potential to enhance security and stability with better anomaly detection, and even predictive analytics.

�ҴǴDz�����’s presented findings on AI adoption among DevOps teams over the last year. 76% of developers now rely on AI to write, refactor, and debug code — a similar but slightly higher percentage than we found among Salesforce professionals.

Interestingly, that 76% adoption rate for AI in DevOps processes outpaces trust in AI among developers surveyed (61%). Other more general surveys confirm the trend. The found that 81% of workers believe AI is improving their productivity, while at same time just 7% think its outputs are trustworthy.

Adopting AI improves developer productivity and job satisfaction overall, but the picture ������’t a simple one. Developers don’t feel they’re doing any less “toilsome” work (defined by DORA as “repetitive, manual tasks that offer little long-term value”). And developers’ AI usage also correlates with a drop in throughput and stability.

What are the right use cases for AI? DORA’s research shows that the most promising use cases are in code reviews and documentation. AI is helping teams to review code faster and improve code quality. Automating repetitive tasks and manual processes in relatively low-risk areas is an obvious application for AI in DevOps, of which �ұ𲹰������’s are a good example.

There’s a clear expectation that AI will bring productivity and efficiency to enterprises, but far less clarity about how exactly that will be delivered. ����������ڴǰ�����’s own uncovered that 66% anticipated securing ROI from their investments, but 68% say their colleagues expect that return to come faster than is realistic.

Salesforce teams’ approach to AI and Agentforce follows DORA’s recommendations: define an AI strategy, experiment in sandbox environments, and avoid over-reliance while building trust and confidence.

Challenges for AI in DevOps

Teams implementing AI in the development cycle will need both general AI training and specific enablement on DevOps tools that now include AI capabilities. Leaders will also need to ensure consistency among their teams, and maintain human oversight of AI-driven automation.

Addressing questions and concerns around AI openly and carefully will be key to building trust in new ways of working. In the spirit of continuous learning and continuous improvement, AI should be implemented in stages. Gaining confidence in AI-enabled monitoring tools that can perform root cause analysis, for example, will build trust for using AI in code deployments and even incident management.

Trace more industry trends

The State of Salesforce DevOps 2025 covers more than AI. Find out about rates of DevOps adoption among Salesforce development teams, how they perform for software delivery based on DORA performance metrics, and how they view the business case for Salesforce DevOps. Read the full, ungated report to get actionable insights and help chart your course through the rest of the year.

This post will be looking at Salesforce Prompt Builder, outlining what prompts are, how to create one, and prompt engineering best practices.

What is a prompt?

Prompts are questions or examples that you input into a Large Language Model (LLM) to give guidelines for how AI should respond, helping it create more relevant, high quality, and consistent outputs for users.

In Salesforce, prompts can be written to use relevant data from across the business through merge fields, so AI functions in your orgs can deliver dynamic outputs tailored specifically to your business context. For example, prompts can support your sales teams by generating personalized emails or summarising key account or opportunity details.

An introduction to Prompt Builder

While prompts are a valuable way to help your users and customers get more tailored and specific outcomes from AI, they can be difficult to engineer. Without the right structure, prompts can give vague, inconsistent, or even incorrect outputs — especially when they’re not grounded in real business data. Effective prompts need to give details on tone, formatting, and safety, which can be hard to get right without clear examples or testing tools. is designed to make that process easier.

What is Prompt Builder?

To streamline the process of creating and managing prompts, Salesforce introduced Prompt Builder as a native prompt engineering solution — allowing you to build AI prompts declaratively and with natural language instructions, making it an accessible way to leverage AI without code.

Although Prompt Builder and are separate, the prompts written in Prompt Builder can also be invoked by agents to augment their actions with generative AI capabilities, helping them make context-aware decisions.

How to enable Prompt Builder

There are three steps you need to follow to set up and use Prompt Builder in your orgs:

• Enable Einstein by going to Setup > Einstein Setup > toggle on Turn on Einstein
• Enable Copilot through Setup > Einstein Copilots > toggle on Einstein Copilot for Salesforce
• Assign the necessary Copilot permissions Einstein Copilot for Salesforce Admin and Einstein Copilot for Salesforce User

Once you’ve completed these steps, you’ll need to refresh your browser window before Prompt Builder becomes visible.

How to create a prompt in Prompt Builder

With Prompt Builder enabled in your org, you’re ready to start writing prompts. Navigate to Setup then search for Prompt Builder to get started.

Step 1. Configure the prompt details

To start writing a new prompt, you need to complete the New Prompt Template details which include selecting a prompt type. There are a number of different prompt types available in Salesforce that relate to specific use cases:

• Sales email. Drafts personalized emails for outreach or follow-up based on the customer’s data.
• Field generation. Uses record context to autofill specific fields on a record page.
• Record summary. Creates structured summaries of record pages to help users get up to speed quickly.
• Knowledge answers. Provides answers to user queries based on Salesforce Knowledge articles.
• Flex templates. A flex prompt template can generate content for use cases that aren’t covered by the other prompt types.

You also need to give the prompt template a name, as well as an API name that acts as an unique identifier, and select the object the prompt relates to.

Step 2. Fill out the prompt template

In the prompt template workspace, write a prompt in natural language that clearly and concisely describes the task you want AI to perform. We’ll look at prompt engineering and best practices below, to help you hit the ground running with effective prompt writing.

You can also include CRM data that AI should draw on when completing the task, known as merge fields. Grounding the prompt in your Salesforce and Data Cloud data is key to getting the most relevant, personalized responses from your prompts.

Prompts are protected by the Einstein Trust Layer, so you can be confident your customer’s sensitive data is secure.

Step 3. Test the prompt output

To check that your prompt generates the output you expect, you can preview an example in the prompt builder preview. Simply select a record and preview language to see an example of how the prompt will work when live.

If the preview output ������’t quite what you’re looking for, you can continue to iterate on your prompt and re-test until you’re confident it will generate the expected content for users.

Step 4. Activate your prompt

When you’re happy with the prompt you can activate and embed it in your workflows and agent actions.

Effective prompt engineering for Salesforce Prompt Builder

Getting the most from your prompt ������’t always straightforward. Let’s look at common prompt engineering techniques that help guide the writing process.

Role-task-format prompt engineering

Role-task-format is the prompt format you’ll see recommended in Prompt Builder. This involves telling AI who it should act like (the role), what it should do (the task), and how the response should be structured (the format). By approaching prompt writing in this way, it sets clear intent and expectations for the output, making the responses more predictable and effective.

Depending on the type of action you’re prompting, there are additional techniques you can use within the role-task-format framework that help make the prompt more effective and fit for purpose.

• Few-shot prompting. When creating prompts to produce written output, including a number of input-output examples in the ‘format’ section of the prompt helps ensure accurate responses that align with your expected tone, length, and other criteria.
• Chain-of-thought prompting. If the task you’re asking the LLM to carry out involves multi-step reasoning, there’s a greater chance that the output will veer off track through the different stages of reasoning. With chain-of-thought prompting you guide the model through step-by-step logic that needs to be taken at each stage of the ‘task’, helping to deliver more accurate outcomes. It also increases transparency of AI decision making by highlighting how the model reached the given output.
• Reason-and-acting prompting. If the prompt involves a task that needs to be context-specific rather than generic (such as prioritization tasks), reason-and-acting prompting can help AI make the right decision. This approach separates out analysis (reasoning) and the specific action/output (acting) into separate instructions within the prompt, to ensure that AI assesses the relevant data before carrying out a task.

By following the role-task-format approach, and including other prompt engineering techniques where relevant, you can help ensure you’re using GenAI to deliver valuable outputs to your end users.

Prompt engineering best practices

While these engineering techniques lay a solid foundation for effective prompt writing, they don’t cover all the elements of a successful prompt. Here are some key considerations to keep in mind when writing Salesforce prompts:

• Define a clear objective for the prompt. Prompts shouldn’t be created for the sake of using AI — each prompt should be aimed at delivering value to end users through achieving specific goals. Having a clear idea of what you’d like the prompt to deliver will help you design a clearer, more focused prompt. It also makes it easier to identify the relevant KPIs to measure whether a prompt is achieving its intended outcome.
• Measure performance and iterate. Prompts shouldn’t be “set and forget”. 37% of Salesforce teams are refining their AI use cases this year, proving that prompt tuning really pays off. By regularly measuring how your prompts are performing, you can iterate and improve them over time to make sure they’re still fit for purpose and delivering value to users. While Agentforce Analytics doesn’t directly analyse prompt success (such as quality of output, or hallucination detection), it can be used to get proximate measures of prompt performance such as usage, acceptance of AI-generated content, or impact KPIs such as the average handle time of support cases. Without regularly reviewing and improving your prompts, they can quickly become outdated and defunct.
• Include guardrails. Including clear instructions in your prompt helps set guardrails and avoid hallucinations that make the output inaccurate. By following the prompt engineering techniques covered above, you’ll most likely have included instructional, contextual, and structural guardrails in your prompt. But it’s easy to overlook instructions for what the model should do when there’s not enough context. This is a common cause of hallucinations or false assumptions. Including guardrails on what to do when the necessary context ������’t available (which could be as simple as ‘select the unknown option’) helps avoid this.
• Establish internal processes for AI. Planning for scalability is key to avoid bottlenecks or dropping prompt quality as your organization and demand for prompts grows. Defining a clear AI strategy that includes how to write and manage prompt templates ensures consistency in prompt creation — delivering better user experiences without slowing the team down.

Delivering Salesforce AI securely with DevOps

Prompts are a powerful way to boost efficiency by tailoring generative AI to your business — but they’re only one piece of what’s possible with Agentforce. Learn more in the comprehensive guide to Salesforce Agentforce and find out how to build agents and deliver them successfully with DevOps.

Instead of relying on ����������ڴǰ�����’s own first-party data centers, Hyperforce moves the platform onto public cloud infrastructure like Amazon Web Services (AWS), Google Cloud 91�Թ��� (GCP), and Microsoft Azure. Migrating to public cloud providers unlocks new possibilities for data residency, scalability, and performance — all while keeping the familiar Salesforce experience intact.

But for DevOps teams, infrastructure changes are never just a technical detail. Whether you’re managing releases, handling metadata, or building pipelines, it’s worth understanding what Salesforce Hyperforce migration means in practice.

How Hyperforce works: Infrastructure

By moving to public cloud platforms like AWS, Hyperforce delivers not just better performance, but also greater flexibility and more control over where and how customer data is stored.

Salesforce Hyperforce infrastructure is built to utilize availability zones and regions. A region is a specific geographic area — Frankfurt or Tokyo — where a cloud provider has physical data centers. Each region contains multiple availability zones — isolated locations designed to keep services running even if one zone goes down.

When a Salesforce organization is deployed on Hyperforce, it’s hosted in a specific region based on the customer’s data residency needs. Within that region, Salesforce uses multiple availability zones to ensure high availability and fault tolerance — enabling horizontal scaling across distributed infrastructure, rather than relying on vertical scaling of individual servers.

The benefits of Hyperforce

Hyperforce gives teams a faster and more flexible way to run Salesforce — with benefits that improve how you build, scale, and secure your environments.

Increased scalability and performance

Hyperforce’s infrastructure takes advantage of the scalability and redundancy of cloud-native architecture. Resources can scale dynamically based on demand — whether that’s more processing power during peak business hours or faster throughput for large metadata deployments. For DevOps teams, that translates to quicker build times, faster test execution, and smoother CI/CD performance across orgs.

Enhanced security controls

By running on modern cloud infrastructure, Hyperforce strengthens ����������ڴǰ�����’s data security posture with the application of Zero Trust architecture. That means no implicit trust — every user, device, and connection must be continuously verified. Hyperforce also supports data encryption both at rest and in transit and organization-specific encryption keys. These Zero Trust principles build on ����������ڴǰ�����’s existing security model while aligning with the rigorous standards of cloud-native platforms — ensuring that access is always intentional, auditable, and secure.

Data residency and compliance

With Hyperforce, businesses can choose the geographic region where customer data is physically stored and processed. This is especially valuable for global-scale businesses in regulated industries, where control over data residency is essential for meeting compliance requirements like GDPR, HIPAA, or CCPA — and for maintaining the auditability and access controls required by standards like SOX. Or for businesses who need to comply with local regulations like Singapore’s Personal Data Protection Act (PDPA), where sensitive data like Personally Identifiable Information (PII) has to be kept within Singapore. Beyond simply meeting compliance checkboxes, Hyperforce data residency helps businesses expand business operations into new markets with confidence, knowing their data architecture can adapt for local data storage and regulations from day one.

Faster time to market

The Hyperforce platform’s flexible and scalable infrastructure helps accelerate release cycles. All Hyperforce sandboxes benefit from , a feature that lets teams create new sandbox orgs by cloning an existing one — with all its metadata and setup — in just a few minutes. Instead of waiting for a full refresh from a production org, developers get a consistent, ready-to-use environment almost instantly. That means less downtime between workstreams and faster testing, helping teams move through development and deployment cycles more quickly. Hyperforce automatically scales cloud resources to handle demand spikes — so even during high-traffic events like Black Friday, performance remains reliable. And by eliminating the need for on-premise hardware and physical resources, teams avoid lengthy procurement and maintenance cycles, moving faster with a streamlined, pay-as-you-go model.

Improved disaster recovery and higher availability

Hyperforce is built for resilience, using multiple availability zones within the same region to deliver high reliability. If one zone experiences an outage, traffic is automatically rerouted to another zone in-region — ensuring uninterrupted service. For more serious disruptions, Hyperforce also supports Out of Region Disaster Recovery by replicating a Salesforce instance from its primary region to a secondary geographic location. This safeguards Salesforce data and helps maintain business continuity even during large-scale regional failures, reinforcing ����������ڴǰ�����’s strong uptime commitments.

Unlocks Data Cloud and Agentforce

Some of ����������ڴǰ�����’s newest innovations, including Data Cloud and Agentforce, rely on the Hyperforce architecture for real-time data processing and streaming from sources like websites, apps, and service interactions. Data Cloud uses this to update unified customer profiles in real time and trigger personalized actions, while Agentforce surfaces live context and AI-powered recommendations. By integrating Data Cloud with Hyperforce, organizations can also take advantage of other big data tools without the burden of managing maintenance or underlying infrastructure. Migrating to Hyperforce not only unlocks these advanced capabilities but also positions teams for future innovation across the Salesforce ecosystem.

Public-cloud-powered innovation

Moving to the public cloud makes faster innovation possible across the entire Salesforce platform. By shifting to cloud service providers like AWS, GCP, and Azure, Salesforce no longer needs to manage the overhead of maintaining its own physical data centers. That means engineering teams can focus more on developing and delivering new features across Sales Cloud, Service Cloud, and beyond — and get those updates into customers’ hands faster.

Hyperforce security

When it comes to encryption on Hyperforce, you don’t have to choose between Hyperforce’s built-in protections and Salesforce Shield as the two work together to provide layered security.

Hyperforce applies volume-level encryption by default. This means that data at rest is encrypted with one encryption key, which Salesforce owns and manages. Salesforce Shield 91�Թ��� Encryption adds another layer of security, which lets you encrypt data with keys you control and manage. Shield encryption also supports more granular use cases — like encrypting specific fields, controlling key rotation, or enforcing encryption policies.

This layered approach means that even if your organization doesn’t use Shield, your data is still encrypted by default in Hyperforce. But if you need more control over how sensitive data is secured, audited, or accessed, Shield can top up what Hyperforce already provides.

Beyond encryption, Hyperforce also changes how access to your data is handled. Salesforce uses a Just-in-Time access (JIT) model, which means internal Salesforce teams don’t have standing access to customer environments. Instead, access is granted temporarily, for specific support tasks, and with strict controls and logging to reduce the risk of unauthorized access to sensitive data.

How to manage a Hyperforce org

Moving to a Hyperforce instance changes the way some core infrastructure is handled — especially around URLs, domains, and network security settings.

URL and domain changes

Hyperforce’s new infrastructure model separates infrastructure from domain structure — this means that when you migrate your org’s URL will change. Instead of using the old shorthand instance-based format (like na123.salesforce.com), Hyperforce orgs will have a new domain, like yourInstance.my.salesforce-sites.com.

These changes can impact any tool, script, or integration that relies on a hardcoded domain — including bookmarked links, custom scripts, API clients, CI/CD pipelines, and webhooks. To prevent disruptions, it’s important to audit and update these references ahead of your migration.

To support this new model, My Domain is a requirement for all orgs migrating to Hyperforce. My Domain gives your org a unique, branded login URL (typically yourcompany.my.salesforce.com) and plays a key role in identity, access control, and authentication flows like SSO. Hyperforce depends on this consistent domain structure to route traffic securely and reliably across its public cloud infrastructure. If your org already uses My Domain, users will continue to access Salesforce through the same familiar custom domain — but the underlying domain and instance name will still change behind the scenes. If you’re not already using My Domain, you’ll need to enable and deploy it before your migration.

IP allowlisting and domain-based access

Salesforce previously relied heavily on a static list of IP ranges for allowlisting — formerly called whitelisting, this is a security control where specific network sources, like IP addresses or IP domains, are approved to access Salesforce applications.

Hyperforce’s public cloud infrastructure means the IP addresses powering your Salesforce org can change dynamically, making static IP allowlists difficult to maintain. Salesforce recommends allowlisting domains instead of IP addresses. This uses DNS patterns like *.force.com or *.my.salesforce.com to define what’s trusted.

How to migrate to Hyperforce

Salesforce Hyperforce migration is a strategic move — not just an infrastructure update. It unlocks better scalability, regional data residency, and faster innovation. Salesforce manages the migration process, but your team plays a crucial role in preparing your org and ensuring continuity. Here are some steps for a smooth migration:

1. Get notified by Salesforce. Salesforce will contact you in advance if your org is scheduled to move to Hyperforce. You’ll receive migration notices containing the Org ID, migration date, and the new target instance name 30 or 90 days before migration based on your support level.

2. Run Salesforce Optimizer. Use the tool to surface potential blockers ahead of time. It highlights hardcoded URLs, outdated features, API usage, and security risks — all of which can affect your readiness for Hyperforce.

3. Review hard-coded references. Check for instance-specific Salesforce URLs in integrations, custom code (Apex, Lightning components), external systems and APIs, Bookmarks, SSO configs, or browser extensions. Update these references to use My Domain or your new Hyperforce-compatible URLs. Salesforce has some .

4. Plan for allowlist updates. Switch from IP-based allowlists to domain-based rules where possible — this helps avoid breakages if cloud infrastructure changes dynamically. If your organization still relies on static IP rules, you’ll need to review and update your lists to include the latest Salesforce IP ranges.

5. Update CI/CD and automation tools. Make sure your DevOps tools, test automation, and CI/CD systems aren’t relying on legacy endpoints or fixed IPs — including static hostnames in test scripts, deployment tools, or proxies. If your team uses 91�Թ���, you won’t need to make any changes as it orgs on Hyperforce and connects via My Domain. You’ll just want to double-check for any hardcoded URLs, static hostnames, or IP-based rules in your wider setup. If you have any questions about connecting to your org or validating and deploying post-migration, you can get in touch with your 91�Թ��� account manager.

6. Communicate internally. Let stakeholders — including admins, developers, security teams, and integration partners — know about the timing and impact of the move.

7. Schedule go-live support. Make sure your internal teams are available during and after the migration window to test key processes and escalate any issues.

How to tell if your Salesforce org has already migrated to Hyperforce

Most new Salesforce instances are provisioned on Hyperforce by default, and a growing number of existing orgs have been migrated, especially in key regions like North America, Europe, and Asia-Pacific. However, not all existing orgs are on Hyperforce yet — the migration is ongoing and prioritized by region, industry, and compliance needs.

You can check if your org is on Hyperforce by finding your instance name:

1. Go to Setup and search Company Information in the Quick Find box.
2. Find the Instance field in the Organization Detail section. Depending on the type of Salesforce infrastructure your org is on, your instance’s name is represented by two or three alphabetical characters followed by numbers. If you know your Domain Name, you can also search on the to find your instance name.
3. You can then search by Instance ID on the Salesforce to see your instance’s location and whether it is operating on Hyperforce or Non-Hyperforce infrastructure.

How much does Hyperforce cost

There is no separate or additional cost to use Hyperforce — it’s included as part of your existing Salesforce licenses, and Salesforce manages the infrastructure transition at no extra charge. However, if you need to comply with the European Union’s regulatory frameworks and choose to host your org in the (EU OZ), this option does come with an additional cost.

What impact does Hyperforce have on your DevOps workflow?

Hyperforce is designed to be an invisible shift — but with very real benefits for teams looking to develop a more complete DevOps lifecycle. Your Salesforce instance still works the same way, but it’s now powered by a more modern computing infrastructure. Hyperforce’s easily scalable platform means faster deployments, reduced test run times, and the ability to clone sandboxes almost instantly through Quick Clone.

One of the biggest benefits Hyperforce brings to DevOps is environment consistency. By standardising the core infrastructure, it reduces the kind of variability that can cause issues during deployment. CI/CD execution becomes more stable, performance holds steady even under pressure, and large metadata changes flow through with fewer bottlenecks.

And because Hyperforce lets you choose where to store data, it also opens up compliance-ready deployments in locations worldwide — ideal for businesses that need to align with regional regulations or want to expand into new global regions without rebuilding their infrastructure.

Start building on a platform that’s equipped for scale and security

If your Salesforce team needs to release faster, scale more confidently, and stay ahead of architectural changes like Hyperforce, it’s time to get your DevOps workflow in shape.

91�Թ��� supports Salesforce services across classic, Hyperforce, and non-Hyperforce environments — with native support for My Domain, flexible deployment pipelines, and guardrails for every release. We’re already supporting many large enterprises with their app releases on Hyperforce, so you can be confident your team is set up for success from day one.

In this post, we’ll explore what IP restrictions are, how they enhance your company’s security posture, and what you need to bear in mind when deploying them — whether manually with change sets or using complete DevOps platforms like 91�Թ���.

Why IP restrictions matter in Salesforce

Controlling access to your Salesforce org based on IP address helps prevent unauthorized access — allowing log-ins only by the users, integrations, or applications on networks you trust. So even if credentials are compromised, attackers can’t get access to your org without being on an approved network.

IP range restrictions help teams:

• Prevent unauthorized access to Salesforce from unknown or unsafe locations
• Enhance trust and security within corporate and partner networks
• Support regulatory compliance by ensuring data can only be accessed from approved sources
• Secure integrations and API access, reducing the risk of data exfiltration
• Layer security controls in conjunction with SSO, MFA, and role-based permissions

Teams often refer to trusted IP ranges as allowlists — or historically, whitelists — to designate safe, pre-approved networks.

Understanding IP address management in Salesforce

Salesforce provides two main ways to control access and safeguard data using IP restrictions: organization-wide trusted IP ranges and profile-level login IP ranges. Both serve different purposes, but when used together they form a robust approach to access control and data privacy.

Organization-wide trusted IP ranges

Trusted IP ranges are defined in Network Access settings and apply across the entire org. When users log in from a trusted Salesforce IP address or range, they can skip the verification code usually required for new devices or locations — even if multi-factor authentication (MFA) is enabled.

This type of IP range offers a smoother login experience for users within known, secure networks, like your corporate office or VPN. For example, employees working from your headquarters or internal network won’t be prompted to verify their identity with a code, but if they try to log in from home or a public location, Salesforce will enforce the usual verification process.

This setup is especially useful for minimizing authentication steps in high-trust environments, making it easier for teams working behind secure firewalls to access Salesforce, balancing user experience with authentication requirements, and to enforce access controls for compliance and auditing.

When defining your IP ranges in Salesforce it’s important to note that only a single IP address should be entered for each start and end field. Avoid using the same address for both field values — the end value should be the higher IP address.

Login IP ranges on profiles

Login IP ranges offer stricter access control by defining which IPs users can log in from — and blocking all access outside those IPs. These ranges are set on a per-profile basis, enabling different levels of restriction depending on role, location, or team function.

For example, you might configure:

• A customer support profile that can only log in from the call center network
• An external contractor profile that’s restricted to a specific range of approved IPs
• A system administrator profile with broader IP access to support flexibility

If a user tries to log in from an IP outside their profile’s allowed range, the login is blocked entirely — they won’t even reach the verification stage. You can also configure multiple ranges for a single profile to account for hybrid work setups or VPN fallbacks.

What are the differences between trusted and login IP ranges?

This table breaks down the key differences between trusted IP and login IP ranges:

To explore all available metadata types, Salesforce support provides a .

Regularly reviewing the approved IPs across your orgs is essential. If allowlists contain IPs that are no longer relevant then you’re increasing the risk of unauthorized access to your orgs.

Don’t get confused by IPAddressRange: Email tracking based on IP ranges

To confuse things, Salesforce also have a metadata type called IPAddressRange. This can be a common source of confusion — especially if you’re searching for the metadata behind an IP range you just updated. Unlike login or network access IPs, this type of IP range ������’t about access control; it’s focused on keeping your marketing data clean. When sending large campaigns like newsletters, product announcements, or release notes, it’s common to include internal team members for visibility within the business. But if those internal users open or click the email, they can skew your engagement metrics.

To prevent test data from inflating engagement metrics you can exclude internal IP addresses using Setup > Filter Email Tracking. When deployed, these filters appear under the IpAddressRange metadata type.

You can also filter tracking for entire domains like @yourcompany.com.

How to deploy IP ranges using 91�Թ���

In this walkthrough we will be deploying the metadata types Settings and Profiles with 91�Թ���.

91�Թ��� retrieves and compares metadata between your Salesforce orgs, highlighting what’s different between environments. So you can easily identify changes and deploy with confidence, knowing you’ve not forgotten what modifications have been made.

To follow along with this walkthrough, start your free trial today.

Compare your orgs

From the Compare & Deploy screen, choose the environments you want to compare.

Click Compare now and 91�Թ��� will retrieve the metadata from both orgs and highlight all the differences between them. You’ll see changes, deletions and new items.

Filter for IP range metadata

To focus on your IP range changes, use the metadata filter down the left-hand side to compare the metadata types you’re looking to deploy.

Network access changes (trusted IP ranges) can be found under Settings > Security.

Profile changes (login IP ranges) can be found under Profiles.

91�Թ��� makes it easy to review your changes before you deploy. You’ll see the IP ranges side by side — what’s currently in the target, and what’s coming from the source. Simply select the items you want to include in your deployment package from the comparison grid.

Once you’re happy with the changes, click Next to build your deployment package.

Run the problem analyzers

Before deploying, 91�Թ��� automatically runs problem analyzers — smart pre-deployment checks designed to catch common issues that might cause your deployment to fail or behave unexpectedly.

Deploy your changes

Once you’re happy with the changes, click Next to finalize your deployment package. You can add deployment notes, assign user stories, and run pre-deployment validation checks.

When you’re ready, click Deploy or schedule the deployment for an off-peak time. 91�Թ��� will apply the changes and give you a detailed deployment summary.

Roll back if needed

If something goes wrong — for example, if you accidentally remove a trusted range or block a key user — 91�Թ��� makes it easy to roll back. Simply navigate to Deployment history, select the relevant deployment, and hit Roll back to revert the deployment partially or in full.

Manage IP restrictions with ease

Managing IP ranges in Salesforce ������’t just about ticking compliance boxes — it’s about building a secure foundation for everything your users do on the platform. Whether you’re enforcing tight login control or simplifying trusted access, IP restrictions are often a key component of a business’s security posture and compliance measures.

But getting it right across multiple environments can be challenging — especially when manual steps and limited tooling slow you down or introduce risk.

With powerful comparisons, reliable deployments, and built-in rollback, 91�Թ��� gives you the confidence to manage sensitive metadata like IP ranges with speed and control — all while keeping your environments in sync and your users securely connected. Sign up for your free 30-day trial now!

But as with any powerful tool in the Salesforce ecosystem, adopting Data 360 comes with new complexities — especially for DevOps teams managing change across multiple Salesforce orgs.

In this post, we’ll explore what Salesforce Data 360 is, how it integrates with platforms like Agentforce, and what DevOps teams need to consider when bringing it into their workflows.

What is Salesforce Data 360?

Data 360 is one of the many clouds on offer from Salesforce. Formerly known as Salesforce CDP or Salesforce Genie — Data 360 is ����������ڴǰ�����’s customer data platform, built to process huge amounts of data, from many different systems, very quickly, and at scale. This enables teams to explore real-time insights, personalization, and AI capabilities.

It powers Customer 360 and Agentforce by bringing together all of your structured and unstructured data into a single, trusted customer view, natively integrated with Salesforce. Data 360 unlocks Agentforce by giving agents access to proprietary data and enabling automation through data-triggered workflows, advanced analytics, and AI-powered applications.

Data 360 enables everyone in your organization, from developers to business users, to access and act on data. With both pro-code and low-code tools, it fuels self-service, smart decisions, and innovation across all teams.

The Salesforce Data Model explained

uses a flexible data model to bring together customer information from different sources into one clear view. It starts by pulling data from systems like your CRM, website, or data lake or warehouse — these are called data streams. That data is then organized into standard categories, known as data model objects (DMOs), which represent things like people, products, or purchases. Data 360 uses identity resolution to link related records and build a real-time customer graph — a live, up-to-date profile that reflects each customer’s latest activity. This model makes it possible to create accurate segments, trigger personalized experiences, and power AI tools across Salesforce.

Why Salesforce teams are using Data 360

Salesforce Data 360 ������’t just another customer database. Here are some of the reasons Data 360 is becoming a critical part of how modern Salesforce teams operate.

• Break down data silos by connecting disparate sources, including CRM systems, marketing platforms, and external data lake objects. This unified data layer means teams across sales, service, and marketing can work from the same set of insights — without relying on manual syncs or data duplication.

• Activate data in real time with live profile updates, segmentation, and event-based triggers. Whether it’s tailoring a product recommendation or updating a support priority, actions can be taken as customer behavior changes — not hours or days later.

• Amplify the value of existing data through native Salesforce connectors — built-in integrations that connect Salesforce to external systems — and zero-copy integrations, which allow you to access and use data in-place without duplicating or moving it.

• Unlock AI and automation by powering Agentforce agents and personalization engines with rich, unified data. With access to contextual, real-time insights, AI can deliver more accurate predictions, automate next best actions, and create seamless user experiences.

• Enable business teams to take action using intuitive, low-code tools and built-in governance controls. From defining customer segments to launching automated customer journeys, non-technical users can safely work with live data while DevOps teams maintain oversight and compliance.

With support for over 200 pre-built connectors and real-time streaming capabilities, Data 360 collates data across multiple departments, breaking down silos and bringing data from both external platforms and Salesforce applications into a unified layer.

Key features of Salesforce Data 360

To understand how Data 360 supports smarter customer experiences and operational agility, let’s break down some of its most impactful features.

• Zero-copy connectors: Streamline access to enterprise data stored in external data warehouses like Snowflake or BigQuery. Zero-copy connectors allow Salesforce applications to query customer data in real time, without physically moving or duplicating it — reducing latency and keeping data secure at the source.

• Real-time customer graph: Build dynamic, unified customer profiles across multiple sources in real time. This continuously updated graph maps identities, behaviors, and preferences, giving you a real time view of each individual across touchpoints.

• Vector search: Support advanced semantic and generative AI use cases by retrieving records based on meaning, not just exact matches. This feature helps AI agents like Agentforce surface contextually relevant insights, even when the input is vague or unstructured.

• Identity resolution: Automatically deduplicate and merge records into a single Golden Record per customer. By matching across emails, device IDs, account numbers, and more, Data 360 ensures every interaction is tied to the right profile.

• Segmentation and activation: Empower marketing teams to define dynamic audiences using real-time attributes and behavioral data. These segments can then be used to trigger personalized journeys or be pushed into channels like Marketing Cloud for targeted outreach.

• Data 360 sandboxes: Provide metadata-only environments to safely test identity resolution logic, segment criteria, and activation strategies without affecting production data. These sandboxes support collaboration between DevOps and business teams when validating changes.

• Policy and data governance: Maintain fine-grained control over how data is accessed, shared, and used across your enterprise. Built-in policies help teams stay compliant with internal standards and external regulations, while audit trails ensure transparency.

Data 360 brings your data to life — giving every team the insights they need, exactly when they need them.

Data 360 in action: powering Agentforce

Agentforce is a standout example of what’s possible when Salesforce Data 360 meets real-time AI. Acting as an intelligent assistant embedded across the Salesforce 91�Թ���, Agentforce supports users’ existing workflows — helping them solve problems, answer questions, and automate tasks using live data. Its effectiveness hinges entirely on having access to accurate, contextual, and up-to-date information.

Here’s how Data 360 empowers Agentforce to deliver truly intelligent experiences:

• Unified customer profiles: Data 360 brings together data from sales, service, marketing, commerce, and external sources — including data lakes and legacy systems — into a single, dynamic view of each customer. This holistic context means Agentforce can understand the full picture and tailor its responses accordingly, whether this is helping a rep troubleshoot an issue or suggesting next best actions.

• Real-time access with zero-copy: Thanks to zero-copy integrations, Agentforce doesn’t rely on stale or pre-synced datasets. Instead, it queries customer data in real time — directly from the original source. This allows the assistant to respond based on the latest transactions, interactions, or support cases, without waiting for scheduled data refreshes or risking inconsistent duplicates.

• Vector search and semantic understanding: Agentforce leverages Data 360’s vector search capabilities to interpret user intent, even when phrased ambiguously. This means it can surface relevant results from vast, unstructured datasets — like past emails, knowledge articles, or web activity — by understanding meaning rather than relying solely on keyword matches.

• Personalization and automation: By tapping into real-time segmentation, identity resolution, and activation logic built in Data 360, Agentforce can deliver responses that feel deeply personalized. For example, it can adapt its tone and actions based on the customer’s profile, segment, recent behavior, or product usage — and then trigger automated workflows that follow through on that context.

Agentforce is only as powerful as the data behind it — and Data 360 ensures that data is always accurate, well-governed, and instantly accessible. Together, they allow companies to create intelligent, responsive, and personalized customer experiences at scale.

DevOps considerations for Salesforce Data 360

As teams begin working with Salesforce Data 360, this new level of data connectivity will inevitably introduce new challenges. Its metadata model and environment setup differ from traditional Salesforce projects, so existing workflows may need to be adjusted. To manage changes reliably and support the platform’s scale, here are the key areas DevOps teams should pay attention to:

Packaging and version control

Salesforce has introduced new metadata types specific to Data 360, such as identity resolution rules, calculated insights, and segment definitions. To support deployment and reuse of these assets, Salesforce offers Data Kits — packages that bundle related metadata into a shareable format. While this is a step forward, these Data Kits aren’t yet fully integrated with many standard deployment tools, which can make version control more challenging. Teams need to adopt consistent conventions for tracking changes to Data 360 metadata and may need to rely on custom scripts or manual exports until full tool support is available.

Version control becomes especially important for collaborative teams working across multiple sandboxes or environments. Identity rules or segment criteria can change frequently, and without proper tracking, it’s easy for configuration drift to occur. Investing in clear documentation, naming conventions, and structured review processes will help teams manage these changes more reliably.

Environment strategy

One of the limitations DevOps teams need to be aware of is that Data 360 sandboxes are currently metadata-only. Unlike traditional Salesforce environments, they don’t contain sample data or support full previewing of identity resolution and segmentation outcomes. This creates a challenge when testing logic or validating changes before promoting them to production.

To overcome this, teams may need to automate synthetic data generation or set up mirrored preview environments using subsets of production metadata. Creating dedicated preview pipelines and defining test cases for rules and activations can help simulate how changes will behave in real-world scenarios. It’s also worth aligning with business stakeholders early in the testing process, especially for changes that impact audience targeting or personalization strategies.

CI/CD with Data 360

Continuous integration and continuous deployment (CI/CD) with Data 360 is achievable, but it’s not plug-and-play. Teams need to build out structured pipelines that can accommodate the unique nature of Data 360 metadata. This includes organizing identity resolution rules, calculated insights, and segmentation logic into modular, versioned components.

It’s also essential to introduce quality gates along the deployment path. That might mean using JSON linting tools to validate metadata syntax, running automated checks for compliance with naming standards, and testing segment outputs using synthetic customer data. Robust monitoring and alerting mechanisms are also critical — especially since data-driven errors may not be immediately visible but can have significant downstream effects on automation or reporting.

Rollback planning is another key consideration for teams. For example, if a segmentation rule inadvertently removes high-value customers from a journey, teams need a fast and reliable way to revert the change. Maintaining snapshots of metadata and clearly documenting dependencies between components can support faster recovery when needed.

Governance and security

Data 360’s real-time access to sensitive customer data raises the bar for governance and security — and DevOps teams play a vital role in upholding those standards. Role-based access controls should be enforced not just within Salesforce, but across all connected platforms. Every action — from metadata changes to data access events — must be auditable and traceable.

When working with personally identifiable information (PII) or regulated data, clearly defined policy frameworks are critical. Teams need to demonstrate how access is granted, how data is used, and who is accountable at every stage of the development lifecycle.

Visibility into metadata changes is equally important. Teams should maintain a complete audit trail showing what was changed, by whom, and when — especially for high-risk components such as identity rules and data classification policies.

Zero-copy architecture complements your existing data lake rather than replacing it. That means your current security and governance controls remain intact, with no need to rebuild policies or replace trusted data stores. IT owners can stay in control without compromise.

Best practices and common pitfalls

To build a reliable and repeatable DevOps process around Salesforce Data 360, it’s important to recognize both the opportunities and the potential pitfalls. Here are several best practices that can help teams stay on the right track:

Deploying Data 360 metadata with Data Kits

One of the biggest surprises for teams working with Data 360 is that many components — including Data Streams, Data Model Objects, Data Lake Objects, and Calculated Insights — can’t be deployed on their own. Salesforce requires them to be packaged inside a Data Kit, which acts as a container for related Data 360 metadata.

This is where teams most often get stuck. A Data Stream, for example, won’t deploy unless it sits inside the correct kit, and teams often only discover this when a deployment fails or the stream doesn’t activate properly in the target org.

Use JSON linting tools to validate metadata

Many of Data 360’s configuration files — such as identity resolution rules and segment definitions — are stored in JSON format. Simple syntax errors can lead to deployment failures or unexpected behavior. Incorporating JSON linting into your CI pipeline helps catch issues early and ensures metadata adheres to expected structures.

Automate preview processes for segmentation and identity rules

Because Data 360 sandboxes are metadata-only, previewing the effects of new or updated logic can be tricky. Where possible, automate previews using synthetic test data and scripted validation steps. This gives you more confidence that changes will behave as expected in production — and helps avoid surprises with live audience activation.

Document rollback plans and fallback segments

If a deployment causes an issue, especially around segmentation or identity resolution, you’ll need a quick way to revert. Keeping rollback plans up to date — including fallback segment definitions and backup metadata — can significantly reduce the time and stress involved in recovering from mistakes.

Track changes in a version control system

Even if you’re working with metadata that ������’t fully supported in standard tooling yet, it’s still worth tracking every change. Storing configurations in version control gives you visibility into how your Data 360 implementation evolves over time, making it easier to collaborate across teams, and enabling safe experimentation through branching and reviews.

Collaborate with business teams

Changes in Data 360 often impact more than just the technical team — particularly when it comes to how segments are built or how customer identities are resolved. Working closely with marketing, service, and data teams to define validation criteria and sample test cases will help ensure deployments meet business expectations and reduce the risk of misaligned logic.

By building a strong DevOps foundation from the start, teams can avoid common pitfalls like misconfigured segments, poor visibility into changes, or unexpected data behavior in production — and instead create a reliable, scalable deployment process that grows with their use of Data 360.

Deploying Data 360 metadata with 91�Թ���

91�Թ��� removes the complexity of deploying Data 360 metadata completely by deploying your Data Kits — and everything inside them — right alongside the rest of your metadata.

And because 91�Թ��� fully understands Salesforce Data Cloud’s ALM model, it handles the extra steps you’d normally need to think about when working with Data Kits. Here’s what the workflow looks like in practice:

Easy discovery of Data Cloud components

In the comparison screen, you can use the dedicated Data Cloud tab to quickly filter and select all relevant Data Cloud metadata. This includes items you can deploy directly (like Segments or Data Model Objects) as well as components that must live inside a Data Kit.

Deploy metadata inside a Data Kit

Salesforce requires that all your Data Cloud components — like Data Streams, Data Model Objects, Data Lake Objects, Calculated Insights, and Search Indexes — are packaged into a . Once the kit is created, 91�Թ��� lets you deploy the kit definition and all its contents in one go.

Using �ұ𲹰������’s pre-set Data Cloud filters helps ensure all the required dependent metadata types are selected. If anything is still missing, �ұ𲹰������’s problem analyzers flag the gaps so you can add the dependencies before validation.

Automatic handling of dependencies

When you retrieve a DataPackageKitDefinition, Salesforce doesn’t automatically pull the components inside it. 91�Թ��� does the heavy lifting for you by prompting you to add any missing Data Cloud components and dependency metadata before you deploy. If anything is still missing, �ұ𲹰������’s problem analyzers highlight it so you can correct the package before validation.

Straightforward validation and deployment

Once your package looks good, 91�Թ��� walks you through validation, then deployment to the target environment — treating your Data Kit and Data Cloud components just like any other metadata bundle.

Optional automatic activation

Perhaps the biggest win: 91�Թ��� can activate your Data Kit automatically after deployment. On the final summary screen, just enable Activate Data Kits after deployment and 91�Թ��� will take care of the post-deployment activation step in the target org — removing yet another piece of manual effort that typically trips teams up.

Unlocking the power of Salesforce Data 360

Salesforce Data 360 has redefined what’s possible when it comes to connecting systems, activating data, and delivering truly personalized customer experiences. With the ability to unify data in real time and power AI-driven tools like Agentforce, it opens the door to faster decisions, smarter automation, and more meaningful engagement across every touchpoint.

With 91�Թ��� you can deploy your Data Cloud Data Kits with ease, eliminate common deployment blockers, and maintain a reliable DevOps process as your Data 360 implementation grows. Try your 30-day free trial now.