Salesforce-DevOps für Field Service

Field-Service-Terminplanungskonfiguration existiert als Daten, nicht als Metadaten. Das bedeutet das für Deployments.

Was schwer zu deployen ist

Servicegebiete, Öffnungszeiten und Serviceressourcen sind Standardobjekte, ihre Konfiguration ist also Datensatzdaten, keine Metadaten, und bewegt sich nicht mit einem Change Set. Planungsrichtlinien referenzieren Optimierungsregeln über eine interne Datensatz-ID, die sich zwischen Orgs unterscheidet, sodass ein sauberes Metadaten-Deployment die Planungs-Engine einer Sandbox trotzdem auf Regeln zeigen lassen kann, die erst nach der Datenmigration wieder aufgelöst werden. Education Cloud trifft auf dasselbe Muster mit seinen TDTM-Trigger-Handler-Datensätzen.

Wo es schwierig wird

Gebiete und Ressourcen sind Daten, keine Metadaten

Servicegebiete, Öffnungszeiten und Serviceressourcen sind Standardobjekte, ihre Einrichtung ist also Datensatzdaten und bewegt sich nicht mit einem Change Set.

Planungsrichtlinien verweisen auf IDs, die sich zwischen Orgs ändern

Planungsrichtlinien referenzieren Optimierungsregeln über eine interne Datensatz-ID, und diese IDs unterscheiden sich pro Org, sodass ein sauberes Metadaten-Deployment die Planungs-Engine trotzdem auf Regeln zeigen lassen kann, die erst nach der Datenmigration aufgelöst werden.

In der Praxis

Wie Serpent hilft

Serpent bündelt und synchronisiert jede Sandbox und Scratch Org, gegen die Ihr Field-Service-Team testet, sodass Gebiets- und Ressourceneinrichtung über Umgebungen hinweg konsistent bleibt, statt zwischen der Org, in der eine Änderung erstellt wurde, und der, in die sie ausgeliefert wird, abzuweichen. Siehe Org-Management in Serpent dafür, wie Umgebungen aufeinander abgestimmt bleiben. Für Teams, die ein dediziertes Datenmigrationstool vergleichen, siehe, wie Serpent im Vergleich zu Prodly abschneidet.

Jede Salesforce-Umgebung zentral verwaltet in Serpent

Typischer Release für Salesforce-DevOps für Field Service

Die Planungsänderung als Task erfassen
Bündeln Sie die Richtlinien- oder Regeländerung mit den Gebiets- und Ressourcendaten, von denen sie abhängt, in einem Task.
Die referenzierten Datensätze migrieren
Die Datenoperationen von Serpent verschieben die Optimierungsregeln und Ressourcendatensätze, auf die die Richtlinie tatsächlich zeigt, nicht nur die Metadatenhülle.
Den Rest per Delta-Deployment ausliefern
Alles andere, Apex, Flow, Permission Sets, wird über die Standard-Delta-Pipeline ausgeliefert.
Planung in einer synchronisierten Sandbox validieren
Bestätigen Sie, dass die Planungs-Engine korrekt gegen eine mit der Produktion synchron gehaltene Umgebung auflöst, keine veraltete Kopie.

Häufige Fragen

Field Service DevOps, beantwortet

Deployt Serpent Field-Service-Gebiete und -Ressourcen?

Ja. Es handelt sich um Standardobjektdaten, daher migrieren die Datenoperationen von Serpent sie als nachverfolgten Schritt im selben Release wie die Metadaten, die sie unterstützen.

Warum bricht eine Planungsrichtlinie nach einem reinen Metadaten-Deployment ab?

Sie zeigt über eine Datensatz-ID auf eine Optimierungsregel, und diese ID existiert in der Zielorg noch nicht. Die Daten müssen ebenfalls migrieren, nicht nur die Metadaten.

Können wir Test-Sandboxes mit der Produktions-Field-Service-Konfiguration synchron halten?

Ja, durch Org-Pooling und -Synchronisierung, sodass Gebiets- und Ressourceneinrichtung nicht zwischen dem Ort, an dem eine Änderung erstellt wurde, und dem Ort, an den sie ausgeliefert wird, abweicht.

Kostenlos starten. Keine Kreditkarte, keine Installation, keine Verpflichtung.

Einrichtung in unter 15 Minuten. Keine DevOps-Einstellung nötig.

Kostenlos starten Demo buchen