OmniStudio Clean Metadata Deployment: Components Finally Deploy Like Normal Metadata

TL;DR

• Clean Metadata Deployment lets OmniStudio components move through the same pipeline as the rest of your metadata: sf CLI, change sets, and 1GP and 2GP packages.
• Three things change underneath it. Each component exposes a single version, dependencies are detected automatically, and source files use clean, version-agnostic names.
• Salesforce's own summary of the old world is worth quoting: deploying OmniStudio components "required extra steps to work around the limitations of the old metadata".
• The eligibility line is the whole story. It applies to the standard runtime and standard designer only. On the managed package runtime you have to migrate first, and that migration is a project, not a setting.
• If you already treat OmniStudio as a special case in your release process, this is the change that lets you stop.

What You'll Learn

• What Clean Metadata Deployment actually changes about the metadata itself
• How to tell in a minute which runtime your org is on
• Why version-agnostic filenames matter more than they sound
• What to do if you are on the managed package runtime and cannot migrate yet

The Problem

OmniStudio has always deployed differently from everything else in Salesforce, and everyone who has run a release with it in scope knows the shape of that difference.

The components carried versions in their names, so the thing you exported was Some_Omniscript_2_1 rather than Some_Omniscript, and a deployment that worked in UAT referenced a version that did not exist in production. Dependencies between an OmniScript, the DataRaptors it called, and the Integration Procedures underneath were not expressed in a way the platform could resolve, so somebody had to know the order. And the export format was DataPacks, which is its own toolchain sitting beside the one your Apex and LWC already used.

The practical result was a second release process. Teams either ran OmniStudio deployments by hand, or wrote scripts to paper over the difference, or accepted that one part of the org was outside the pipeline that governed everything else. None of those are good, and all of them are common.

Winter '27 removes the reason that second process existed.

Common questions this article answers:

• What changed in the metadata itself, as opposed to the tooling around it?
• How do I tell which runtime my org is on?
• What do I do if I am on the managed package runtime?

Quick Answer

Clean Metadata Deployment lets OmniStudio components deploy with the same tools as standard metadata: sf CLI, change sets, and both 1GP and 2GP packages, in the same pipeline as your LWC, Flows and Apex classes. It works by changing the metadata, not the tooling: each component now exposes a single version instead of a version-suffixed name per revision, dependencies between components are detected automatically, so nobody has to know the order, and source files use clean names that do not encode a version. That combination is what removes the need for DataPacks and for the hand-built workarounds most teams wrote around them. The constraint that decides whether any of this reaches you is the runtime: Clean Metadata Deployment applies to the standard runtime and standard designer only. If your org is on the managed package runtime and designer, you migrate to standard first, and the migration is the real work here, not adopting the deployment change.

What actually changed

Worth being precise here, because "OmniStudio deploys normally now" is the headline and the mechanism is more interesting than the headline.

A single version per component. Previously a component's identity included its version, so every revision produced a differently named artefact and environments drifted apart by name instead of by content. Now a component exposes one version, so a deployment can target it by name and mean the same thing everywhere.

Automatic dependency detection. An OmniScript that calls a DataRaptor which calls an Integration Procedure has a dependency graph. Previously that graph lived in somebody's head or in a runbook. The platform now detects it, so an ordinary metadata deploy works without a documented sequence.

Version-agnostic source filenames. This sounds cosmetic and is not. A filename that does not encode a version is a filename that produces a clean diff. It means a change to an OmniScript shows up in a pull request as a modification instead of one file deleted and a differently named file added, and that is the difference between OmniStudio being reviewable in the same way as the rest of your codebase and it being an opaque blob that somebody approves on trust.

Taken together, these are the three properties that standard metadata always had and OmniStudio never did.

Which runtime are you on

Everything above depends on this, so check before planning anything.

The distinction is between the standard runtime and designer, which is the native OmniStudio built into the platform, and the managed package runtime and designer, which is the older Vlocity-derived packaged implementation. Orgs that adopted OmniStudio through an industry cloud several years ago are frequently still on the managed package one.

The quickest signal is what is installed. A managed package runtime org carries the OmniStudio managed package with its namespace:

sf package installed list --target-org yourorg

Look for an OmniStudio or Vlocity namespace in the result. You can also check in Setup under Installed Packages, and the OmniStudio setup pages themselves differ between the two.

If you are on standard, Clean Metadata Deployment is available to you. If you are on the managed package runtime, it is not, and the migration to standard comes first.

If you are on the managed package runtime

Be realistic about what this is. Migrating from the managed package runtime to the standard runtime is not a deployment setting, it is a platform migration with testing, regression risk and a schedule.

That does not make it avoidable. The direction of travel is clear from where Salesforce is putting new capability, and this release is an example: a substantial improvement to the development lifecycle that is simply not offered on the older runtime. The gap between the two runtimes widens with each release that does this.

The useful thing you can do now, without committing to the migration, is to stop building new workarounds. If your team is currently writing tooling to manage DataPack exports, that tooling has a finite life. Knowing that changes what is worth investing in.

What this does not change

It does not retrofit your existing deployments. Components already in your org keep whatever shape they have until they move through the new path.

It does not make OmniStudio components reviewable by people who do not know OmniStudio. A clean diff on an OmniScript is still a diff on an OmniScript. What changes is that the diff exists and is meaningful, not that it becomes self-explanatory.

It does not remove the need to test. Automatic dependency detection resolving the graph correctly is a claim worth verifying on your own components in a sandbox before you trust it in a release, particularly where a component is referenced by something outside OmniStudio.

Frequently Asked Questions

Q: Does this mean DataPacks are gone?

A: It means the reason for them is gone on the standard runtime. If your components deploy as ordinary metadata through the CLI, you no longer need a separate export format to move them. Whether you retire your existing DataPack tooling immediately is a different question, and the answer usually depends on how much of your pipeline is built around it and whether every environment you deploy to is on the standard runtime yet.

Q: We are on the standard runtime already. Is there anything to do?

A: Yes, and it is mostly deletion. Find the workarounds your release process carries for OmniStudio, whether that is an ordering runbook, a script that rewrites version-suffixed names, or a manual step somebody performs at deployment time, and test whether they are still needed. The value of this change is realised by removing that work, not by adopting a feature.

Q: Can we mix runtimes across environments?

A: You can have different orgs on different runtimes, and plenty of estates do during a migration, but it makes your pipeline the lowest common denominator. A production org on the managed package runtime means the deployment path into production cannot use Clean Metadata Deployment, whatever your sandboxes are on. Plan the migration production-first in terms of sequencing your thinking, even though you will test it elsewhere first.

Q: How does this interact with retrieving OmniStudio metadata for source control?

A: Favourably, and this is the part most likely to change how a team works day to day. Version-agnostic filenames mean a retrieve produces stable paths, so the same component lands in the same file every time and git can show a real history for it. The retrieval mechanics are covered in Fetching OmniStudio Metadata with sf CLI, and the commands there still apply; what improves is what you get back.

Q: Is this a Release Update with an enforcement date?

A: No. It is a capability that arrives with Winter '27 rather than a change enforced on a date, so nothing breaks if you ignore it. That also means nothing will remind you it exists, which is the usual fate of improvements that are not deadlines.

Key Takeaways

• OmniStudio components deploy through the normal pipeline now: sf CLI, change sets, 1GP and 2GP packages.
• Three metadata changes make it work: single version per component, automatic dependency detection, and version-agnostic filenames.
• Version-agnostic filenames give you real diffs, which is what makes OmniStudio reviewable in a pull request rather than approved on trust.
• Standard runtime and designer only. On the managed package runtime, migration comes first and it is a project.
• The value is in deleting your workarounds, so go and find them rather than waiting to notice the improvement.

What's Next?

Run sf package installed list against production and find out which runtime you are actually on. That answer determines whether this is a cleanup task or a migration conversation, and teams are often wrong about which one they are in.

If you are on standard, audit your release process for OmniStudio-specific steps and start removing them. If you are on the managed package runtime, the useful next move is to stop investing in DataPack tooling rather than to start the migration tomorrow.

For the retrieval side of the same workflow, see Fetching OmniStudio Metadata with sf CLI. For the rest of what Winter '27 carries, including what is enforced rather than merely available, see Salesforce Winter '27 Security Readiness.

Resources & References

• Salesforce Winter '27 Release Notes, OmniStudio section, in Salesforce Help.
• Salesforce Help documentation for Clean Metadata Deployment, for the per-component detail.
• Fetching OmniStudio Metadata with sf CLI for retrieving components into source control.
• Salesforce Winter '27 Security Readiness for the release as a whole.