Tekunda Team

Tekunda Team

Was ein Salesforce PDO macht, und wann Sie einen beauftragen

Was ein Salesforce PDO macht, und wann Sie einen beauftragen

Kurze Antwort: Ein Salesforce PDO (Product Development Outsourcer) ist ein Beratungspartner, der kommerzielle Apps auf der Salesforce-Plattform fuer Softwareanbieter baut, sauber paketiert und durch die AppExchange Security Review bringt. Sie beauftragen einen, wenn Sie ein Produkt auf Salesforce ausliefern wollen, nicht wenn Ihnen ein Entwickler fehlt. Dieser Unterschied bestimmt Zuschnitt, Preis und Bewertung der Zusammenarbeit.

Was ist ein Salesforce PDO?

Ein Product Development Outsourcer ist ein Salesforce-Partner, der darauf spezialisiert ist, Produkte auf der Plattform zu bauen, statt die Plattform fuer ein einzelnes Unternehmen einzurichten. ISVs (unabhaengige Softwareanbieter) geben ihm die Teile der Produktlieferung, die Salesforce-spezifisch sind: Paketarchitektur, Namespace- und Abhaengigkeitsstrategie, Lizenzierung, das AppExchange-Listing und die Security Review, die alles davon absichert.

Der Unterschied in einer Zeile:

  • Ein Systemintegrator passt Salesforce an Ihr Unternehmen an.
  • Ein PDO macht aus Ihrer Idee etwas, das andere Unternehmen bei sich installieren.

Was macht ein Salesforce PDO konkret?

  • Produktarchitektur. Was gehoert in das Managed Package, was bleibt in Ihrem eigenen Dienst, was muss pro Subscriber konfigurierbar sein.
  • Paketierung. 1GP oder 2GP, Namespace-Registrierung, Abhaengigkeiten zwischen Paketen und eine Versionsstrategie, die Jahre traegt.
  • Security Review. Vorbereitung, Einreichung und Nacharbeit, wenn die Pruefer mit Findings zurueckkommen.
  • Lizenzierung und Provisionierung. Die License Management App, Trial-Flows und das Listing selbst.
  • Release Engineering nach dem Launch. Patches, Upgrades und gepushte Versionen, die Orgs nicht zerlegen, die Sie nicht sehen koennen.
  • Supportmodell. Ein ISV betreut Installationen, die er nicht kontrolliert. Das ist eine andere Disziplin als der Support einer einzelnen Org.

Nur der erste Punkt sieht nach gewoehnlicher Salesforce-Arbeit aus. Der Rest ist Produktbetrieb, und genau dort verlieren erstmalige ISVs ganze Quartale.

Wann sollten Sie einen Salesforce PDO beauftragen?

Fuenf Signale, grob nach Dringlichkeit:

  1. Sie haben eine Produktthese und einen ersten Designpartner, aber keinen Namespace und keine schriftliche Paketierungsentscheidung. Das ist der guenstigste Moment, denn noch ist nichts festgelegt.
  2. Ihre App laeuft in der Sandbox und bricht als Paket. Namespace-Praefixe, dynamisches SOQL und Abhaengigkeiten zwischen Paketen scheitern auf Wegen, die unpaketierter Code nie zeigt.
  3. Sie gehen zum ersten Mal in die Security Review. Das Risiko ist selten eine einzelne Ablehnung, sondern drei Ablehnungen und zwei verlorene Quartale.
  4. Sie sind auf 1GP und wollen nach 2GP. Salesforce hat Package Migrations mit Summer '25 allgemein verfuegbar gemacht: Die Funktion konvertiert ein 1GP-Paket nach 2GP und migriert installierte Subscriber mit. Die Frage ist nicht mehr ob, sondern wann und in welcher Reihenfolge.
  5. Sie haben Subscriber und jedes Release ist zum Risiko geworden. Sobald andere Unternehmen an Ihren Versionsnummern haengen, ist Release Engineering nicht mehr optional.

Warum ist ein PDO eine Produktentscheidung und keine Personalentscheidung?

Staff Augmentation beantwortet eine Kapazitaetsfrage: Wir brauchen sechs Monate lang zwei zusaetzliche Apex-Entwickler. Ein PDO-Auftrag beantwortet eine Produktfrage: Version 1.0 muss im zweiten Quartal gelistet, geprueft und installierbar sein. Der zweite Rahmen ist schwerer einzukaufen und deutlich besser zu verantworten, denn fast jeder teure Fehler in der ISV-Lieferung ist eine Entscheidung und kein Mangel an Haenden.

Ein Namespace wird einmal registriert und bleibt am Paket. Die Wahl zwischen 1GP und 2GP legt Ihr Releasemodell fuer Jahre fest. Was im Paket liegt, bestimmt, was Sie spaeter aendern koennen, ohne jeden Subscriber um Erlaubnis zu bitten. Nichts davon loest sich, indem man einem Team Kapazitaet hinzufuegt, das noch nie ein Paket ausgeliefert hat.

Wenn Ihre Salesforce-Arbeit eine Roadmap, Subscriber und eine Versionsnummer hat, kaufen Sie Produktengineering ein. Kaufen Sie es auch so ein.

Worauf prueft die AppExchange Security Review wirklich?

Die Security Review ist ein Produkttor, keine Stilpruefung fuer Code. Sie sieht sich an, wie Ihr Paket mit Daten, Secrets, Sharing und Zugriffen umgeht, und sie kommt wieder, sobald die Anforderungen der Plattform strenger werden.

Das aktuelle Beispiel, das jeder ISV auf der Roadmap haben sollte, sind Connected Apps. Der ISVforce Guide von Salesforce verlangt von Partnern, OAuth PKCE, Refresh Token Rotation, eine Idle-Refresh-Token-Lebensdauer von 30 Tagen und eine IP-Allowlist fuer Refresh Tokens zu aktivieren und bis zum 11. Mai 2026 selbst zu attestieren, dass die App auf alle vier Kontrollen umgestellt ist. Nach der Attestierung sind die Kontrollen gesperrt und lassen sich nicht mehr deaktivieren; bei Verstoessen drohen De-Listing oder die Aussetzung der Interoperation. Genau solche Fristen verfolgt ein PDO fuer Sie.

Wie waehlen Sie einen Salesforce PDO aus?

Stellen Sie vier Fragen und gewichten Sie die Antworten hoch:

  • Welche Pakete haben Sie durch die Security Review gebracht, und in welchen Branchen? Regulierte Branchen legen die Latte hoeher.
  • Zeigen Sie mir ein 2GP-Paket, das Sie heute pflegen. Eines zu bauen ist nicht dasselbe, wie es ueber Subscriber-Orgs zu versionieren.
  • Wer behebt die Findings, wenn die Review zurueckkommt? Die Antwort sollte lauten: sie.
  • Was passiert nach dem Launch? Ein Partner, der beim Listing verschwindet, laesst Ihnen den schwersten Teil.

Tekunda beantwortet das aus der Lieferung heraus, nicht aus einer Broschuere. Wir sind zertifizierter Salesforce SI, ISV und PDO, haben die AppExchange Security Review in Gesundheitswesen, Logistik und Fertigung bestanden und pflegen Pakete im Produktivbetrieb: Syntilio CareHub bedient 12 oder mehr Pflegeorganisationen auf der AppExchange, und unser 2GP Managed Package fuer ASSA ABLOY traegt deren Connected-Device-Last. ISV und PDO zu sein macht uns ausserdem zum schnelleren Integrator, weil Komponenten in Produktqualitaet wiederverwendet statt neu gebaut werden. So arbeiten wir.

FAQ

Wofuer steht PDO bei Salesforce?

Product Development Outsourcer: ein Salesforce-Beratungspartner, spezialisiert auf Bau, Paketierung und Listing kommerzieller Apps auf der AppExchange fuer Softwareanbieter.

Was ist der Unterschied zwischen einem PDO und einem Salesforce-Implementierungspartner?

Ein Implementierungspartner richtet Salesforce fuer den Eigenbedarf eines Unternehmens ein. Ein PDO baut ein paketiertes Produkt, das viele Unternehmen installieren, was Namespace, Versionierung, Lizenzierung und Security Review hinzufuegt.

Brauche ich einen PDO, um die AppExchange Security Review zu bestehen?

Nein. Viele ISVs schaffen das allein. Ein PDO spart vor allem Reviewzyklen, weil die typischen Findings berechenbar werden, wenn man den Prozess mehrfach durchlaufen hat.

Sollte eine neue AppExchange-App mit 1GP oder 2GP starten?

2GP ist der moderne Weg fuer neue Pakete. Bestehende 1GP-Anbieter sitzen ebenfalls nicht fest: Package Migrations ist seit Summer '25 allgemein verfuegbar und konvertiert ein 1GP-Paket nach 2GP samt installierter Subscriber.

Wie frueh sollte ein ISV einen PDO einbinden?

Bevor die Entscheidungen zu Namespace und Paketierung fallen. Genau die sind teuer rueckgaengig zu machen, und sie fallen meist in der ersten Woche.

Ähnliche Artikel