Preflight QC

Preflight QC ist eine Premium-Zusatzoption, die Ihnen professionelle Release-Qualitätskontrolle bietet. Reichen Sie ein Release ein, und Preflight QC analysiert es von Anfang bis Ende: Metadaten, Release-Daten, Audio, Artwork, KI-Inhalte, Katalog-Kennungen, frühere Distribution und Lizenznachweise. Sie erhalten einen klaren, umsetzbaren Qualitätsbericht. Beheben Sie in Ihrem eigenen Tempo, was er meldet, und bestätigen Sie das Release zur Prüfung, wenn Sie zufrieden sind.

Für Labels und API-Integratoren ist Preflight QC ein Baustein. Rufen Sie den Qualitätsbericht programmatisch ab, binden Sie ihn in Ihre eigene QA-Pipeline ein, machen Sie Ihren internen Freigabeprozess davon abhängig und bestätigen Sie Releases automatisch zur Prüfung. Ihr Team setzt die Qualitätslatte, Preflight QC übernimmt die Analyse.

Ein Release, das sauber ankommt, kommt schnell durch die Prüfung. Preflight QC bringt Sie dorthin, bevor Sie einreichen.

Was Preflight QC ist

Mit aktiviertem Preflight QC gelangt ein zum Vertrieb eingereichtes Release nicht direkt in die Prüfwarteschlange. Stattdessen kommt es in eine Wartephase vor der Prüfung („wartet auf Ihre Prüfung”), während Preflight QC seine Qualitätsanalyse durchführt: Metadaten, Release-Daten, Audio, Artwork, KI-Inhalte, Katalog-Kennungen, frühere Distribution und Lizenznachweise. Das Ergebnis ist ein Qualitätsbericht, und was Sie darauf aufbauen, liegt bei Ihnen:

• Ihr eigener QA-Workflow (API). Lassen Sie Ihren Katalog durch die Qualitätsanalyse laufen, rufen Sie den Bericht programmatisch in Ihrer eigenen QA-Pipeline ab, machen Sie Ihren internen Freigabeprozess von den Ergebnissen abhängig und bestätigen Sie jedes Release erst dann zur Prüfung, wenn es Ihre Messlatte nimmt. Siehe Die API nutzen für Integrationen.
• Der Ablauf in der App. Lesen Sie den Bericht auf der Release-Seite, beheben Sie, was er meldet, und bestätigen Sie, wenn Sie zufrieden sind.

In beiden Fällen ist es die Bestätigung, die das Release in die normale Prüfwarteschlange verschiebt: Nichts geht in die Prüfung, bevor Sie grünes Licht geben.

Preflight QC fügt vor der Prüfung eine Qualitätsstufe hinzu. Es ändert nichts an dem, was danach passiert: Sobald Sie bestätigen, durchläuft Ihr Release denselben Validierungs- und Prüfprozess wie jedes andere Release.

So erhalten Sie Preflight QC

Preflight QC ist eine Premium-Zusatzoption, die unser Team pro Konto aktiviert. Um sie für Ihr Konto einzuschalten, kontaktieren Sie unser Vertriebsteam und teilen Sie mit, dass Sie Preflight QC möchten.

Sobald es aktiviert ist, sehen Sie den neuen Warte- und Bestätigungsschritt, wenn Sie das nächste Mal ein Release zum Vertrieb einreichen.

Der Ablauf von Preflight QC

Hier ist der vollständige Weg eines Releases mit aktiviertem Preflight QC, vom Einreichen bis zur Prüfung.

1. Reichen Sie Ihr Release zum Vertrieb ein

Erstellen und vervollständigen Sie Ihr Release wie gewohnt und reichen Sie es dann zum Vertrieb ein. Mit aktiviertem Preflight QC stellt das Release nicht sofort in die Prüfwarteschlange. Stattdessen wechselt das Release in eine Wartephase vor der Prüfung und wird als wartet auf Ihre Prüfung markiert.

2. Die Qualitätsanalyse läuft

Während sich Ihr Release in der Wartephase befindet, analysiert Preflight QC es von Anfang bis Ende. Die Analyse umfasst:

• Metadaten: Titel, Interpreten, Credits und andere Angaben zum Release und zu den Tracks
• Release-Daten: Ihre Datumseinstellungen und Release-Versionen
• Audio: die von Ihnen hochgeladenen Audiodateien
• Artwork: Ihr Coverbild
• KI-Inhalte: ob der Einsatz von KI angegeben ist, sowie von uns erkannte KI-generierte Musik oder Cover
• Katalog-Kennungen: ob Ihre ISRCs gültig sind und ob eine Aufnahme bereits von einem anderen Rechteinhaber beansprucht wurde
• Frühere Distribution: ob das Release oder seine Tracks bereits über einen anderen Vertrieb in den Stores sind
• Lizenzen: wenn eine Coverversion, ein Sample oder Ähnliches einen Nachweis benötigt

Die Analyse ist in der Regel wenige Minuten nach Abschluss von Upload und Transkodierung fertig. Solange sie noch läuft, zeigt der Qualitätsbericht an, dass die Prüfungen in Bearbeitung sind, und listet noch keine Probleme auf.

3. Lesen Sie Ihren Qualitätsbericht

Sobald die Analyse abgeschlossen ist, öffnen Sie den Qualitätsbericht des Releases, um zu sehen, was Ihre Aufmerksamkeit erfordert, falls überhaupt etwas. Sie können ihn an zwei Stellen lesen:

• Über die öffentliche API, für Ihre eigene QA-Pipeline; siehe Die API nutzen weiter unten.
• In der App, auf der Release-Seite.

Der Bericht listet jedes Problem mit einem klaren Titel und einer Nachricht auf, die beschreibt, was zu beheben ist. Siehe Den Qualitätsbericht verstehen, um die Felder zu lesen.

4. Beheben Sie, was gemeldet wird

Arbeiten Sie die Probleme in Ihrem Bericht durch:

• Metadaten-Probleme: Bearbeiten Sie die Angaben zum Release oder Track.
• Audio- oder Artwork-Probleme: Ersetzen Sie die betroffene Datei.
• Probleme, die eine Rückmeldung erfordern: Antworten Sie im Notizen-Thread des Problems oder laden Sie das angeforderte Dokument hoch (zum Beispiel eine Lizenz für eine Coverversion oder ein Sample).

Wenn Sie Ihr Release während der Wartephase bearbeiten, wird der aktuelle Bericht als veraltet markiert: Die Ergebnisse spiegeln nicht mehr den neuesten Stand Ihres Releases wider. Bearbeiten Sie so viel Sie möchten, und fordern Sie dann eine neue Analyse an, über die Release-Seite in der App oder für Integrationen über den Aktualisierungs-Endpunkt. Die Analyse läuft erneut und der Bericht aktualisiert sich mit den neuen Ergebnissen. Sie können diesen Kreislauf so oft durchlaufen, wie Sie möchten, im Rahmen einer Fair-Use-Grenze dafür, wie viele neue Analysen Sie pro Release und Stunde starten können.

5. Bestätigen Sie das Release

Wenn Ihr Bericht sauber ist, oder Sie alles Nötige erledigt haben, bestätigen Sie das Release. In der App ist das eine Bestätigen-Schaltfläche auf dem Release; für Integrationen ist es der Bestätigungs-Endpunkt.

Die Bestätigung nimmt das Release aus der Wartephase und verschiebt es in die normale Prüfwarteschlange. Für die Bestätigung ist eine abgeschlossene, aktuelle Analyse erforderlich: Wenn Sie das Release nach dem letzten Lauf bearbeitet haben, ist der Bericht veraltet; fordern Sie also eine neue Analyse an und lassen Sie sie abschließen, bevor Sie bestätigen.

6. Normale Prüfung

Nach der Bestätigung wird Ihr Release genau wie jedes andere geprüft. Was während der Prüfung passiert, wie lange sie dauert und welche Ergebnisse möglich sind, erfahren Sie unter Validierung und Prüfung.

Den Qualitätsbericht verstehen

Der Qualitätsbericht hat zwei Teile: eine Liste von Problemen und einen kleinen Block mit Bericht-Details zum Analyselauf selbst.

Probleme

Jedes Problem im Bericht beschreibt einen Punkt zum Ansehen. Die Felder, mit denen Sie arbeiten:

Feld	Was es Ihnen sagt
Titel	Ein kurzer, verständlicher Name für das Problem.
Nachricht	Worum es sich handelt und was zu tun ist.
Schweregrad	Wie wichtig das Problem ist, um Ihnen die Priorisierung zu erleichtern.
Blockierend	Ob das Problem gelöst sein muss, bevor Sie bestätigen können (siehe unten).
Erfordert Rückmeldung	Ob das Problem eine schriftliche Antwort oder ein hochgeladenes Dokument von Ihnen benötigt.
Benutzerdefinierte Beschreibung	Zusätzliche, für Ihr Release spezifische Details, sofern verfügbar.
Betroffene Tracks	Auf welche Tracks sich das Problem bezieht. Probleme auf Release-Ebene nennen keine bestimmten Tracks.
Belege	Bei Problemen zu Datum, Duplikaten und vorherigem Vertrieb die von uns gefundenen übereinstimmenden Releases, damit Sie den Konflikt selbst prüfen können (siehe unten).

Blockierend oder informativ

• Blockierende Probleme müssen gelöst sein, bevor Sie das Release zur Prüfung bestätigen können. Beheben Sie, was sie beschreiben, führen Sie eine neue Analyse durch, und sie verschwinden aus Ihrem Bericht.
• Informative Probleme weisen auf etwas hin, das einen Blick wert ist, hindern Sie aber nicht am Bestätigen. Sehen Sie sie sich an und bestätigen Sie, wenn Sie bereit sind.

Probleme, die eine Rückmeldung erfordern

Manche Probleme lassen sich nicht allein durch Bearbeiten lösen: Sie brauchen etwas von Ihnen, etwa eine schriftliche Erläuterung oder einen Nachweis (zum Beispiel eine Lizenz für eine Coverversion oder ein Sample). Diese sind als erfordert Rückmeldung markiert. Um ein solches Problem zu lösen, antworten Sie im Notizen-Thread des Problems oder laden Sie das angeforderte Dokument hoch, bevor Sie bestätigen.

Belege zu einem Problem

Manche Probleme enthalten Belege, damit Sie einen Hinweis ohne Rätselraten prüfen können: die vorhandenen Releases, die wir mit Ihrem abgeglichen haben. Sie sehen sie bei Problemen zu Datum, Duplikaten und vorherigem Vertrieb. Jede Übereinstimmung zeigt Titel und Interpret des übereinstimmenden Tracks, dessen Release-Titel, Release-Datum und ISRC sowie einen Link zu einem Store, in dem dieses Release verfügbar ist, und welche Ihrer Tracks betroffen sind. Pro Track werden bis zu drei Übereinstimmungen aufgeführt. Nutzen Sie die Belege, um zu bestätigen, ob der Konflikt real ist (zum Beispiel ein früherer Upload von Ihnen selbst), bevor Sie entscheiden, wie Sie reagieren.

Die Bericht-Details

Neben den Problemen enthält der Bericht einige Details zum Analyselauf:

Feld	Was es Ihnen sagt
generated_at	Wann der aktuelle Bericht erstellt wurde. Leer, solange die erste Analyse noch läuft.
checks_in_progress	true, solange die Analyse noch läuft; die Problemliste bleibt leer, bis sie abgeschlossen ist.
stale	true, wenn Sie das Release (oder einen seiner Tracks) nach der letzten abgeschlossenen Analyse bearbeitet haben, sodass die Ergebnisse nicht mehr den aktuellen Stand widerspiegeln. Jede Bearbeitung zählt. Fordern Sie eine neue Analyse an, um den Bericht zu aktualisieren.
hold	Ob sich das Release derzeit in der Wartephase vor der Prüfung befindet.
review_status	Der aktuelle Prüfstatus des Releases.
release_status	Der Gesamtstatus des Releases selbst, neben dem prüfungsspezifischen Status.
profile	Das auf dieses Release angewendete Qualitätsprofil, mit Name und Version.

Die API nutzen (für Integrationen)

Wenn Sie auf der öffentlichen LabelGrid-API aufbauen, können Sie Preflight QC in Ihre eigene Pipeline einbinden: Lassen Sie jedes Release durch die Qualitätsanalyse laufen, holen Sie den Bericht in Ihren eigenen QA-Workflow, machen Sie Ihren internen Freigabeprozess davon abhängig und bestätigen Sie zur Prüfung aus Ihrem eigenen Tooling heraus. Dafür stellt Preflight QC drei Endpunkte bereit; alle verwenden dieselbe Bearer-Token-Authentifizierung wie der Rest der öffentlichen API. Die vollständigen und stets aktuellen Anfrage- und Antwortschemata finden Sie in der API-Referenz.

Webhook: erfahren, wann der Bericht bereit ist

Statt die Ergebnisse abzufragen, können Sie sich von LabelGrid benachrichtigen lassen, sobald ein Bericht bereit ist. Abonnieren Sie das Webhook-Ereignis release.preflight.report_ready: Es wird ausgelöst, sobald Preflight QC ein Release in der Wartephase vor der Prüfung fertig analysiert hat, auch jedes Mal, wenn eine von Ihnen angeforderte erneute Analyse abgeschlossen ist. Sie erhalten genau ein Ereignis pro Analysezyklus.

Abonnieren Sie es genauso, wie Sie die anderen Release-Webhook-Ereignisse von LabelGrid abonnieren: über Ihre Webhook-Einstellungen in der App oder per API. Jedes Ereignis enthält eine kompakte Zusammenfassung des Laufs, niemals die Probleme selbst:

• Release-Kennungen: release_id, label_id, release_cat und release_title.
• generated_at: wann dieser Bericht erstellt wurde. Entspricht dem generated_at des Berichts selbst.
• profile: das Qualitätsprofil, mit dem die Zähler berechnet wurden, als {name, version}.
• counts: die Gesamtzahlen für blocking, informational und requires_feedback. Der requires_feedback-Zähler überschneidet sich mit den beiden anderen.

Nutzen Sie die Zähler, um zu entscheiden, ob Sie handeln müssen, und holen Sie sich dann den Bericht selbst für die Details. Das empfohlene Integrationsmuster:

1. Abonnieren Sie release.preflight.report_ready.
2. Bei jedem Ereignis rufen Sie Den Qualitätsbericht abrufen auf, um die vollständige Liste der Probleme zu lesen.
3. Beheben und erneut ausführen: Nachdem Sie ein Release in der Wartephase bearbeitet haben, rufen Sie den Aktualisierungs-Endpunkt auf, um eine neue Analyse zu starten; der Webhook wird erneut ausgelöst, wenn sie abgeschlossen ist.
4. Entscheiden und bestätigen Sie aus Ihrem eigenen Tooling heraus, sobald das Release Ihre Messlatte nimmt.

Die vollständige Payload-Referenz und die Webhook-Mechanik (Signierung, Wiederholungsversuche und den Umschlag) finden Sie unter Webhooks.

Den Qualitätsbericht abrufen

GET /api/public/releases/{id}/quality-report
Authorization: Bearer YOUR_API_TOKEN

Gibt den aktuellen Qualitätsbericht des Releases zurück. Die Antwort enthält:

• issues[]: ein Eintrag pro Problem, jeweils mit id, code (ein stabiler String; siehe Mit den Problemcodes arbeiten), title, message, status, severity, is_blocking, requires_feedback, custom_description und affected_tracks. Bei Problemen zu Datum, Duplikaten und vorherigem Vertrieb enthält der Eintrag zusätzlich ein evidence-Array (siehe unten).
• report: generated_at, checks_in_progress, stale, hold, review_status, release_status und profile (ein Objekt mit name und version). stale ist true, wenn das Release oder einer seiner Tracks nach der letzten abgeschlossenen Analyse bearbeitet wurde; führen Sie die Analyse mit dem Aktualisierungs-Endpunkt erneut aus, bevor Sie bestätigen.

Solange die Analyse noch läuft, gibt der Bericht checks_in_progress: true mit einer leeren issues-Liste zurück. Wenn Sie keine Webhooks verwenden möchten, fragen Sie diesen Endpunkt wiederholt ab, bis generated_at gesetzt ist, in der Regel wenige Minuten nach Abschluss von Upload und Transkodierung, und lesen Sie dann die Probleme. Um stattdessen sofort benachrichtigt zu werden, sobald der Bericht bereit ist, nutzen Sie den Report-Ready-Webhook.

Eine Beispielantwort nach abgeschlossener Analyse:

{
  "issues": [
    {
      "id": "12345",
      "code": "example.issue-code",
      "title": "Short issue title",
      "message": "What to fix and how.",
      "status": "confirmed",
      "severity": "…",
      "is_blocking": true,
      "requires_feedback": false,
      "custom_description": null,
      "affected_tracks": [456],
      "evidence": [
        {
          "affected_track_id": 456,
          "track_title": "Matched track title",
          "artist": "Matched artist",
          "release_title": "Matched release",
          "release_date": "2024-03-01",
          "isrc": "USRC12345678",
          "store_url": "https://…"
        }
      ]
    }
  ],
  "report": {
    "generated_at": "2026-07-07T12:00:00Z",
    "checks_in_progress": false,
    "stale": false,
    "hold": true,
    "review_status": "…",
    "release_status": "…",
    "profile": { "name": "quality_report", "version": 2 }
  }
}

Jedes evidence-Element beschreibt ein vorhandenes Release, das mit Ihrem übereinstimmt: affected_track_id (auf welchen Ihrer Tracks die Übereinstimmung zutrifft), das übereinstimmende track_title, artist, release_title, release_date und isrc sowie eine store_url, die auf eine Store-Seite verweist, auf der die Übereinstimmung verfügbar ist. Pro Track werden höchstens drei Übereinstimmungen aufgeführt, und der Schlüssel ist nur bei den oben genannten Problemarten vorhanden.

Eine neue Analyse anfordern

POST /api/public/releases/{id}/quality-report/refresh
Authorization: Bearer YOUR_API_TOKEN

Startet einen neuen Preflight-QC-Analysezyklus für ein Release in der Wartephase. Ein Release in der Wartephase zu bearbeiten führt die Prüfungen nicht von selbst erneut aus: Es markiert nur den aktuellen Bericht als veraltet (report.stale: true). Wenn Sie mit dem Bearbeiten fertig sind, rufen Sie diesen Endpunkt auf, um die Analyse erneut auszuführen; wenn der Zyklus abgeschlossen ist, wird der Report-Ready-Webhook ausgelöst und report.stale kehrt zu false zurück.

Ein erfolgreicher Aufruf gibt 202 Accepted zurück:

{
  "status": "refreshing",
  "checks_in_progress": true,
  "review_status": "pending_customer_review",
  "release_status": "to_review"
}

Der Aufruf ist idempotent, solange ein Zyklus läuft: Ein erneuter Aufruf gibt denselben In-Progress-Body zurück, reiht keine zweite Analyse ein und wird nicht auf Ihr Budget angerechnet. Weitere Antworten, die Sie behandeln sollten:

• 409 not_in_customer_review_hold: Das Release befindet sich derzeit nicht in der Wartephase für Ihre Preflight-QC-Prüfung.
• 409 refresh_coalesced: Eine Analyse für dieses Release wurde gerade eben abgeschlossen, daher wurde nichts eingereiht. Versuchen Sie es nach dem Retry-After-Header (in Sekunden) erneut.
• 429 preflight_recheck_limit_reached: Sie haben das Fair-Use-Budget von 6 gestarteten Analysezyklen pro Release je gleitender Stunde erreicht. Der Retry-After-Header (in Sekunden) gibt an, wann die nächste Aktualisierung erlaubt ist. Das Abfragen einer laufenden Analyse ist kostenlos; nur das Starten eines neuen Zyklus verbraucht Budget.
• 403 RELEASE_NOT_VALIDATED: Das Release muss die Validierung bestehen, bevor eine erneute Analyse starten kann (dieselbe Regel wie beim Vertrieb); führen Sie zuerst die Validierung durch.
• 403 pre_review_qc_not_enabled: Preflight QC ist für das zugehörige Konto nicht aktiviert.

Das Release zur Prüfung bestätigen

POST /api/public/releases/{id}/confirm-review
Authorization: Bearer YOUR_API_TOKEN

Nimmt das Release aus der Wartephase und verschiebt es in die normale Prüfwarteschlange: das API-Äquivalent der Bestätigen-Schaltfläche in der App.

Für die Bestätigung ist eine abgeschlossene, aktuelle Analyse erforderlich. Zwei Konflikte sind zu behandeln:

• 409 checks_in_progress: Die Analyse läuft noch. Warten Sie auf den Report-Ready-Webhook (oder fragen Sie ab, bis generated_at gesetzt ist), und versuchen Sie es dann erneut.
• 409 checks_stale: Das Release wurde nach der letzten abgeschlossenen Analyse bearbeitet (report.stale ist true). Rufen Sie den Aktualisierungs-Endpunkt auf, warten Sie auf den neuen Bericht und versuchen Sie die Bestätigung dann erneut.

Hinweis

Solange sich ein Release in der Wartephase vor der Prüfung befindet, gibt das Einreichen über den normalen Vertriebsweg 409 preflight_recheck_required zurück: Ein Release in der Wartephase verlässt diese nur über den hier beschriebenen Ablauf aus Aktualisieren und Bestätigen.

Mit den Problemcodes arbeiten

Wenn Sie Logik auf dem Qualitätsbericht aufbauen, stützen Sie sie auf den code des Problems:

• code ist ein stabiler String im Slug-Format (zum Beispiel audio.trailing-silence). Sie können Codes gefahrlos in Ihrem System abbilden und Logik darauf aufbauen.
• Titel und Nachrichten sind Texte für Menschen. Sie können mit der Zeit überarbeitet werden; stützen Sie Ihre Logik nie auf den Text, sondern nutzen Sie ihn nur zur Anzeige.
• Neue Codes können hinzukommen, wenn die Abdeckung von Preflight QC erweitert wird. Behandeln Sie unbekannte Codes generisch: Zeigen Sie title und message aus der Antwort an, statt einen Fehler auszulösen.
• Ihre Berichte zeigen Ihnen die Codes, die zählen. Während Sie Releases durch Preflight QC laufen lassen, tauchen die für Ihren Katalog relevanten Codes ganz natürlich in Ihren eigenen Qualitätsberichten auf.
• Was die Analyse abdeckt. Die Probleme fallen in diese Kategorien: Release- und Track-Metadaten, Release-Daten und -Versionen, Audioqualität, Artwork, KI-Inhalte, Katalog-Kennungen, frühere Distribution sowie Lizenzen und Nachweise.

Der Problemkatalog

Um die Probleme beim Aufbau Ihres eigenen QA-Workflows zu mappen, rufen Sie den vollständigen Katalog programmatisch ab:

GET /api/public/issue-definitions
Authorization: Bearer YOUR_API_TOKEN

Er liefert jedes Problem, das in einem Qualitätsbericht auftauchen kann, indiziert nach seinem stabilen String-Code, mit Titel, Nachrichtenvorlage, Schweregrad, Blockierend-Kennzeichen, requires_feedback und seiner Kategorie (type). Die Antwort enthält außerdem das Qualitätsprofil, mit dem der Katalog berechnet wurde, als {name, version}. Der Endpunkt steht nur Konten mit der Preflight-QC-Zusatzoption zur Verfügung.

Häufige Fragen

Was, wenn die Analyse noch läuft?

Der Bericht zeigt checks_in_progress: true an, ohne dass bereits Probleme aufgeführt sind. Das ist direkt nach dem Einreichen normal. Warten Sie einige Minuten nach Abschluss von Upload und Transkodierung und sehen Sie dann erneut nach: In der App aktualisiert sich der Bericht von selbst. Über die API können Sie den Report-Ready-Webhook abonnieren, um in dem Moment benachrichtigt zu werden, in dem er bereit ist, oder wiederholt abfragen, bis generated_at gesetzt ist.

Kann ich mein Release während der Wartephase bearbeiten?

Ja, bearbeiten Sie so frei, wie Sie möchten: Ein Release in der Wartephase vor der Prüfung bleibt vollständig bearbeitbar. Das Bearbeiten führt die Prüfungen nicht von selbst erneut aus; es markiert den aktuellen Bericht als veraltet. Wenn Sie mit Ihren Änderungen fertig sind, fordern Sie eine neue Analyse an (über die Release-Seite in der App oder für Integrationen über den Aktualisierungs-Endpunkt), um die aktualisierten Ergebnisse zu sehen, ohne die Wartephase zu verlassen. Die neue Analyse muss abgeschlossen sein, bevor Sie bestätigen können.

Was passiert, nachdem ich bestätigt habe?

Ihr Release verlässt die Wartephase und reiht sich in die normale Prüfwarteschlange ein, wo es wie jedes andere geprüft wird. Siehe Validierung und Prüfung dazu, wie die Prüfung abläuft, wie lange sie dauert und welche Ergebnisse möglich sind.

Kann ich ein Release wieder in den Entwurf zurücksetzen?

Ja: Solange sich Ihr Release in der Wartephase vor der Prüfung befindet und Sie es noch nicht bestätigt haben, ist es nicht in die Prüfung gelangt. Sie können es also weiter bearbeiten oder als Entwurf liegen lassen und später zurückkehren. Es gelangt erst in die Prüfwarteschlange, wenn Sie es bestätigen.

Muss ich jedes Problem beheben, bevor ich bestätige?

Sie müssen blockierende Probleme beheben, bevor Sie bestätigen können. Informative Probleme hindern Sie nicht am Bestätigen, sind aber einen Blick wert: So viel wie möglich vor der Prüfung zu bereinigen, ist der schnellste Weg zur Freigabe.

---

Fragen zu Preflight QC? Kontaktieren Sie unser Team. Wir helfen Ihnen gern.