Publisher und Präfix in Dynamics 365 richtig wählen

Beim Anlegen der ersten eigenen Lösung fragt Dataverse nach einem Publisher und einem Präfix. Der Dialog wirkt unscheinbar, und viele unerfahre Consultants neigen dazu ihn schnell durchzuklicken. Das Präfix landet danach vor jedem Feld, jeder Tabelle und jeder Option, die das Team jemals anlegt, und lässt sich im Nachhinein nicht mehr ändern.

Was das Präfix technisch bewirkt

Legen Sie in einer Lösung mit dem Präfix "contoso" ein Feld namens "Kundennummer" an, heißt es nun technisch "contoso_kundennummer". Dieser Name steht danach in jedem Skript, in jeder Abfrage und in jeder Integration.

Der Zweck ist Kollisionsfreiheit. Zwei Lösungen unterschiedlicher Herkunft können beide ein Feld „Status“ anlegen, ohne sich in die Quere zu kommen, weil sie sich in ihrem technischen Namen sich unterscheiden. Außerdem kann identifiziert werden, welche Abhängigkeiten zu Fremdlösungen es innerhalb der Lösung gibt.

Der häufigste Fehler: das Standardpräfix behalten

Wer keinen eigenen Publisher anlegt, arbeitet mit dem Standard-Publisher der Umgebung, und dessen Präfix lautet "new". Dementsprechend heißen dann alle so angelegten Spalten z.B. "new_kundennummer`, "new_projekt" oder "new_status".

Das funktioniert technisch tadellos und fällt oft deshalb jahrelang niemandem auf. Unangenehm wird es an zwei Stellen. Erstens sagt der Name nichts mehr darüber aus, wer eine Komponente gebaut hat, und in einer über Jahre gewachsenen Umgebung ist das die einzige Spur, die bleibt. Zweitens verwenden auch andere Lösungen gern das Standardpräfix, weshalb ausgerechnet dort Kollisionen wahrscheinlicher werden.

Der zweithäufigste Fehler: zu viele Präfixe

Das andere Extrem ist ebenso verbreitet. Jedes Teilprojekt legt seinen eigenen Publisher an, und nach drei Jahren tragen die Komponenten einer einzigen Umgebung fünf verschiedene Präfixe.

Für den Betrieb bedeutet das: Man kann nicht mehr auf einen Blick sehen, was zusammengehört. Filtert man in der Feldliste nach einem Präfix, fehlt die Hälfte. Ein einheitliches Präfix pro Organisation ist in den allermeisten Fällen die bessere Wahl, auch wenn mehrere Dienstleister beteiligt sind.

Meine Faustregeln für die Wahl

• Kurz halten. Zwei bis drei Zeichen. Das Präfix steht vor jedem Namen und verbraucht Platz in der Zeichenbegrenzung technischer Namen.
• Nur Kleinbuchstaben und nicht mit einer Ziffer beginnen. Andere Zeichen sind nicht erlaubt.
• Am Unternehmen orientieren, nicht am Projekt. "con" überlebt, "contoso2024" nicht.
• Nicht "new" verwenden und auch keines der von Microsoft verwendeten Präfixe wie "msdyn" oder "msdynce"
• Einmal festlegen und dokumentieren. Der nächste Dienstleister muss wissen, welches Präfix zu verwenden ist, sonst entsteht das nächste.

Wenn es zu spät ist

Ein bestehendes Präfix zu ändern bedeutet, jede betroffene Komponente neu anzulegen und die Daten zu migrieren. Für eine gewachsene Umgebung ist das praktisch ausgeschlossen.

Was realistisch bleibt: den Zustand kennen und für alles Neue eine klare Regel setzen. Aus einem Solution-Export lässt sich auslesen, wie viele Präfixe im Einsatz sind und wie sich die eigenen Komponenten darauf verteilen. Ein dominantes Präfix mit über neunzig Prozent Anteil ist ein gutes Zeichen. Drei Präfixe mit je einem Drittel bedeuten, dass hier drei Teams unabhängig voneinander gearbeitet haben, und das erklärt oft, warum sich die Lösung uneinheitlich anfühlt.