---
sourceDocument: Capacidades da Now Platform da Yokohama
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/pt-BR/yokohama/servicenow-platform

 Release :

    - yokohama

ft:locale :

    - pt-BR

ft:publication_title :

    - Capacidades da Now Platform da Yokohama

ft:clusterId :

    - platcap

bundleId :

    - platcap

workflow :

    - Platform


---

# Como evitar fluxos de trabalho duplicados

# Como evitar fluxos de trabalho duplicados {#ariaid-title1}

* Versão de lançamento: Yokohama
* 
* Atualizado 30 de jan. de 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 min. de leitura

Os conjuntos de atualizações gerenciam o estado publicado de todas as versões de um fluxo de trabalho antes de confirmar a versão em uma instância local.

A última versão de um fluxo de trabalho confirmada como inserção ou atualização usando um conjunto de atualizações se torna a versão publicada no momento, seja qual for a sequência de publicação das versões.

## Confirmação de um fluxo de trabalho em um conjunto de atualizações {#ariaid-title2}

Siga as etapas nesta página para confirmar um fluxo de trabalho em um conjunto de atualizações.

### Procedimento

1. Fluxo de trabalho A --- a versão 1 é criada e publicada no conjunto de atualizações A.
2. O conjunto de atualizações A foi concluído e migrado para uma instância local.
3. Quando o conjunto de atualizações é confirmado, o sistema define todas as versões anteriores do fluxo de trabalho A como publicado = falso.  
   Na primeira migração, não há versões anteriores.
4. Fluxo de trabalho A --- a versão 1 se torna a única versão publicada do fluxo de trabalho.

## Exemplo de migração de conjunto de atualizações {#ariaid-title3}

Não é possível ter várias versões publicadas como resultado de confirmações de conjunto de atualizações. No entanto, isso não elimina o risco e deve-se ter cuidado ao migrar conjuntos de atualizações.
Considere este exemplo:

1. Fluxo de trabalho A --- a versão 1 é migrada e confirmada para a instância de produção.
2. O conjunto de atualizações B é criado.
3. O conjunto de atualizações C é criado.
4. Fluxo de trabalho A --- a versão 2 é publicada no conjunto de atualizações B.Um registro de atualização do cliente é adicionado ao conjunto de atualizações B com a carga da versão 2.

   Um registro de atualização do cliente é adicionado ao conjunto de atualizações B com a versão 1 do fluxo de trabalho não publicada.
5. O conjunto de atualizações B é concluído.
6. Fluxo de trabalho A --- a versão 3 é publicada no conjunto de atualizações C.Um registro de atualização do cliente é adicionado ao conjunto de atualizações C com a carga da versão 3.

   Um registro de atualização do cliente é adicionado ao conjunto de atualizações C com a versão 2 do fluxo de trabalho não publicada.
7. O conjunto de atualizações C é concluído.
8. O conjunto de atualizações C é migrado e confirmado para a instância de produção.Fluxo de trabalho A --- a versão 1 é definida como não publicada.

   Fluxo de trabalho A --- a atualização da versão 2 é ignorada, já que o conjunto de atualizações B, que contém a versão 2, nunca foi migrado.

   Fluxo de trabalho A --- a versão 3 é confirmada e se torna a única versão publicada do fluxo de trabalho.
{#r_UpdateSetMigrationExample__ol_xg3_zrz_gr}

## Risco de migração do conjunto de atualizações {#ariaid-title4}

O conjunto de atualizações B é migrado e confirmado para a instância de produção.
1. Fluxo de trabalho A --- a versão 3 é definida como não publicada.
2. Fluxo de trabalho A --- a versão 1 permanece não publicada.
3. Fluxo de trabalho A --- a versão 2 é confirmada e se torna a única versão publicada do fluxo de trabalho.O fluxo de trabalho retrocedeu uma versão, talvez de maneira não intencional. A versão regredida se torna a versão publicada no momento.

{#r_UpdateSetMigrationRisk__ol_szq_3vz_gr}