---
sourceDocument: Yokohama Now Platform-Fähigkeiten
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/de-DE/yokohama/servicenow-platform

 Release :

    - yokohama

ft:locale :

    - de-DE

ft:publication_title :

    - Yokohama Now Platform-Fähigkeiten

ft:clusterId :

    - platcap

bundleId :

    - platcap

workflow :

    - Platform


---

# Doppelte Workflows werden vermieden

# Doppelte Workflows werden vermieden {#ariaid-title1}

* Freigeben Version: Yokohama
* 
* Aktualisiert 30. Januar 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 1 Minute Lesedauer

Update-Sätze verwalten den veröffentlichten Status aller Versionen eines Workflows, bevor die Workflow-Version auf einer lokalen Instanz bestätigt wird.

Die letzte Version eines Workflows, der als Einfügen oder Aktualisieren mit einem Update-Satz festgelegt wurde, wird unabhängig von der Veröffentlichungssequenz für die Workflow-Versionen zur aktuell veröffentlichten Version.

## Commit für einen Workflow in einem Update-Satz {#ariaid-title2}

Führen Sie die Schritte auf dieser Seite aus, um einen Workflow in einem Update-Satz zu bestätigen.

### Prozedur

1. Workflow A -- Version 1 wird in Update-Satz A erstellt und veröffentlicht
2. Update-Satz A wurde abgeschlossen und zu einer lokalen Instanz migriert.
3. Wenn der Update-Satz bestätigt wird, legt das System alle vorherigen Versionen von Workflow A auf „veröffentlicht" = „falsch" fest.  
   In der ersten Migration sind keine vorherigen Versionen vorhanden.
4. Workflow A: Version 1 wird zur einzigen veröffentlichten Version des Workflows.

## Beispiel für Update-Satz-Migration {#ariaid-title3}

Es ist nicht möglich, mehrere veröffentlichte Versionen als Ergebnis von Update-Satz-Commits zu haben. Dies beseitigt jedoch nicht das Risiko, und bei der Migration von Update-Sätzen ist Vorsicht geboten.
Betrachten Sie dieses Beispiel:

1. Workflow A -- Version 1 wird migriert und an die Produktionsinstanz übergeben.
2. Update-Satz B wird erstellt.
3. Update-Satz C wird erstellt.
4. Workflow A -- Version 2 wird in Update-Satz B veröffentlichtDem Update-Satz B wird ein Kundenupdate-Datensatz mit der Nutzlast der Version 2 hinzugefügt.

   Ein Kundenaktualisierungsdatensatz wird dem Update-Satz B hinzugefügt, wobei der Version 1-Workflow nicht veröffentlicht wird.
5. Update-Satz B ist abgeschlossen.
6. Workflow A -- Version 3 wird im Update-Satz C veröffentlichtEin Kundenaktualisierungsdatensatz wird dem Update-Satz C mit der Nutzlast der Version 3 hinzugefügt.

   Ein Kundenaktualisierungsdatensatz wird dem Update-Satz C hinzugefügt, wobei der Version 2-Workflow nicht veröffentlicht wird.
7. Update-Satz C ist abgeschlossen.
8. Update-Satz C wird migriert und an die Produktionsinstanz übergeben.Workflow A -- Version 1 ist auf „nicht veröffentlicht" festgelegt.

   Workflow A -- Update der Version 2 wird übersprungen, da Update-Satz B, der Version 2 enthält, nie migriert wurde.

   Workflow A: Version 3 wird bestätigt und wird zur einzigen veröffentlichten Version des Workflows.
{#r_UpdateSetMigrationExample__ol_xg3_zrz_gr}

## Update-Satz-Migrationsrisiko {#ariaid-title4}

Update-Satz B wird migriert und an die Produktionsinstanz übergeben.
1. Workflow A -- Version 3 ist auf „nicht veröffentlicht" festgelegt.
2. Workflow A: Version 1 bleibt nicht veröffentlicht.
3. Workflow A: Version 2 wird bestätigt und wird zur einzigen veröffentlichten Version des Workflows.Der Workflow wurde möglicherweise unbeabsichtigt in einer Version zurückgesetzt. Die zurückgesetzte Version wird zur derzeit veröffentlichten Version.

{#r_UpdateSetMigrationRisk__ol_szq_3vz_gr}