Clean Metadata Deployment: implantação de componentes Omnistudio sem gambiarra

O que é

Clean Metadata Deployment é a nova forma de gerenciar e implantar componentes Omnistudio usando as mesmas ferramentas e processos que já usamos para metadata padrão do Salesforce. Isso significa Salesforce CLI, change sets e pacotes de primeira geração (1GP) e segunda geração (2GP), tudo no mesmo pipeline que já carrega Lightning web components, Flows, classes Apex e metadata semelhante.

O texto oficial destaca três características técnicas do novo formato: cada componente expõe uma única versão, as dependências são detectadas automaticamente, e os arquivos-fonte usam nomes limpos, sem referência a versão específica. Antes disso, implantar componentes Omnistudio exigia passos extras para contornar as limitações do metadata antigo, que carregava múltiplas versões e nomenclaturas dependentes de versão dentro do mesmo componente.

Junto com essa mudança, a nota também menciona a disponibilidade geral do reuso de Autolaunched Flow em Flexcards: dá para configurar um Flow autolançado ativo como fonte de dados de um Flexcard, ou invocar o Flow diretamente a partir de uma ação do Flexcard. Essa fonte de dados aparece no designer padrão do Omnistudio, permitindo centralizar lógica de negócio que antes ficava duplicada entre cards diferentes.

Por que importa

Quem já implantou Omnistudio em orgs com múltiplos sandboxes e pipelines de CI/CD sabe a dor de versionamento estranho, nomes de componentes acoplados a número de versão e dependências que só apareciam quando o deploy falhava em produção. Já perdi tempo demais depurando falha de deploy Omnistudio que no fim era só nomenclatura de versão desalinhada entre ambientes, e isso é exatamente o tipo de problema que Clean Metadata Deployment ataca. Ao alinhar Omnistudio ao mesmo modelo de metadata que Flow, Apex e LWC já usam, reduz a superfície de erro humano e os scripts paralelos que times de DevOps mantinham só para lidar com essa particularidade.

O reuso de Autolaunched Flow em Flexcards também é relevante do ponto de vista arquitetural: em vez de replicar lógica de negócio em múltiplos Flexcards ou recorrer a Integration Procedures para tudo, dá para centralizar regras em um Flow autolançado único e reaproveitá-lo como fonte de dados ou ação. Isso aproxima o padrão de governança que já aplicamos a Flows de uso geral também ao mundo Omnistudio.

Como se preparar

• Revise seu pipeline de deploy atual de Omnistudio e identifique quais workarounds manuais existem hoje só para contornar o metadata antigo, esses passos tendem a desaparecer.
• Mapeie change sets e pacotes 1GP/2GP que hoje tratam Omnistudio separadamente e planeje a consolidação com o pipeline padrão de Apex, LWC e Flow.
• Audite Flexcards que duplicam a mesma lógica de negócio em componentes distintos e avalie migrar essa lógica para um Flow autolançado único, reaproveitado como fonte de dados.
• Valide no designer padrão do Omnistudio se a opção de fonte de dados via Autolaunched Flow já aparece na sua org antes de replanejar a arquitetura de Flexcards.

Nível de aplicação: Médio

Exige replanejar pipeline de CI/CD e migrar metadata Omnistudio existente, mas não envolve reengenharia profunda de lógica de negócio.

Considerações de arquiteto

• Antes de migrar, mapeie todos os workarounds manuais e scripts paralelos que hoje contornam o metadata antigo do Omnistudio para não deixar dívida técnica escondida no pipeline novo.
• A consolidação de change sets e pacotes 1GP/2GP de Omnistudio com o pipeline padrão de Apex, LWC e Flow deve ser testada primeiro em sandbox de integração antes de tocar produção.
• Centralizar lógica duplicada de Flexcards em um Autolaunched Flow único exige também revisar a governança de versionamento desse Flow, já que ele passa a ser ponto único de falha para múltiplos cards.
• Vale validar com o time de DevOps se as ferramentas de CLI já usadas para Apex e Flow cobrem adequadamente os cenários de rollback específicos de componentes Omnistudio.

Pegadinhas:

• Orgs que ainda carregam componentes Omnistudio com nomenclatura antiga dependente de versão podem precisar de um passo de conversão antes de aproveitar o formato limpo.

Este artigo faz parte do guia Flow na Winter '27, um item oficial por artigo. Fonte: release notes de Automation.