Dieser Artikel enthält bewährte Vorgehensweisen für die Planung und Verwaltung von Regionsverwaltungsaufgaben. Die Informationen richten sich an erfahrene Salesforce-Architekten und -Entwickler, die an Implementierungen mit komplexen Anforderungen an die Regionsverwaltung und umfangreichen Vertriebsumstrukturierungen arbeiten.
Um die neueste Version dieses Inhalts zu erhalten und sich eine Badge zu verdienen, absolvieren Sie das Trailhead-Modul "Erweiterte Regionsverwaltung".
Allgemeine Konzepte für die Regionsverwaltung finden Sie in den folgenden Artikeln.
Informationen zur Übersicht über die Enterprise-Regionsverwaltung (Salesforce-Hilfe)
Zugriff auf Datensatzebene: Ansicht im Detail
Unterschiede zwischen der ursprünglichen Regionsverwaltung und der Enterprise-Regionsverwaltung
Klarstellen der Funktionsweise von Zuweisungsregeln innerhalb der Hierarchie
Es ist wichtig zu verstehen, dass Accountzuweisungsregeln für jede Region einzeln ausgewertet werden und nicht von übergeordneten Regionen vererbt werden.
Ein Account wird nur dann einer untergeordneten Region zugewiesen (z. B. "Kalifornien"), wenn eine Regel für diese bestimmte Region mit dem Account übereinstimmt.
Dieser Account wird nicht ausschließlich aufgrund der Hierarchie automatisch der übergeordneten Region (z. B. "Westküste") zugewiesen. Wenn Sie möchten, dass der Account auch der Region "Westküste" formal zugewiesen wird, müssen Sie eine separate Zuweisungsregel für die Region "Westküste" erstellen.
Der primäre Zweck der Regionshierarchie ist nicht die Regelvererbung, sondern Folgendes:
Berichterstellung und Prognosen: Aggregieren von Daten aus untergeordneten zu übergeordneten Regionen.
Datensatzzugriff/-sichtbarkeit: Benutzern, die einer übergeordneten Region zugewiesen sind, automatisch Einblick in die Datensätze (z. B. Accounts und Opportunities) gewähren, deren Inhaber Benutzer in den untergeordneten Regionen sind.
Vereinfachen des Vertriebszweigs Ihrer Rollenhierarchie mithilfe der Regionsverwaltung
Berücksichtigen Sie beim Modellieren Ihrer Regionshierarchie, dass der von der Regionsverwaltung bereitgestellte Zugriff automatisch Ihrer Rollenhierarchie zugeordnet wird. Der Versuch, Ihre Regionsstruktur im Vertriebszweig Ihrer Rollenhierarchie zu duplizieren, ist unnötig und überflüssig.
Verwenden Sie stattdessen Ihre Rollenhierarchie, um Verwaltungsbeziehungen, Berichts-Rollups, Genehmigungen und andere hierarchisch strukturierte Workflows zu konfigurieren. Vereinfachen Sie den Vertriebszweig Ihrer Rollenhierarchie, sodass nur Rollen für diese Zwecke enthalten sind. Verwenden Sie dann die Regionsverwaltung, um den Zugriff auf Accounts und Opportunities anhand der Regionszuweisungen der Benutzer zu erweitern.
Hinzufügen von Regionen mit Prognosemanagern
Gilt für die ursprüngliche Regionsverwaltung und anpassbare Prognosen. Informationen zu Regionsprognosen in der Enterprise-Regionsverwaltung und gemeinschaftlichen Prognosen finden Sie in Trailhead.
Wenn Sie Prognosen in Salesforce erstellen, fügen Sie einer Regionshierarchie nur Regionen hinzu, wenn sie über Prognosemanager verfügen, die über Anforderungen für Zugriffs-Rollups verfügen. Wenn Sie in Salesforce Prognosen für eine Region erstellen, die keinen Prognosemanager aufweist, sind die Region und alle ihre untergeordneten Regionen nicht in Ihren Prognosen enthalten. Wenn für Ihre übergeordneten Knoten keine Prognosemanager benötigt werden, müssen Sie dennoch Platzhalter-Prognosemanager hinzufügen, um sicherzustellen, dass Ihre Prognosen ihren übergeordneten Knoten zugeordnet werden.
Hinzufügen von vererbten Accountzuweisungsregeln
Wenn Sie übergeordnete Regionen zur Regionshierarchie hinzufügen, sollten Sie diesen Regionen auch vererbte Accountzuweisungsregeln hinzufügen. Wenn Sie diese Vorgehensweise befolgen, können Sie verhindern, dass das Regelmodul ganze Zweige Ihrer Regionshierarchie auswerten muss, und Ihre gesamte Freigabeleistung verbessern. Entsprechende Informationen finden Sie in der Salesforce-Hilfe unter "Verwalten von Accountzuweisungsregeln".
Neuzuordnung von unten nach oben
Wenn Sie Ihre Regionshierarchie ändern, ordnen Sie jeden Knoten der Region von unten nach oben neu zu, um den Zugriff für dieselben Regionen nicht neu berechnen zu müssen.
Aktivieren der granularen Sperre erwägen
Bestimmte auf die Regionshierarchie bezogene Vorgänge erfordern exklusive Verwaltungssperren, die Administratoren in Ihrer Organisation vorübergehend daran hindern, Verwaltungsaktivitäten auszuführen, oder sich auf einige Vorgänge in Bezug auf die Gruppenmitgliedschaft von Endbenutzern auswirken, beispielsweise die Bereitstellung von Portalbenutzern und Änderungen der Inhaberschaft von Portalaccounts.
In einigen Szenarien können Sie die Leistung einiger Sperrvorgänge verbessern, indem Sie die granulare Sperre aktivieren. Die granulare Sperre analysiert den Vorgang und versucht, nur die geänderten Teile der Tabelle zu sperren, was die Anzahl der Sperren reduzieren kann, die sich auf andere Benutzer auswirken. Zu den Vorgängen, die eine vollständige Tabellensperre (Gruppensperre) ausführen und daher möglicherweise von einer granularen Sperre profitieren, zählen:
Hinzufügen, Löschen oder Verschieben eines Benutzers von einer Region in eine andere
Neuzuordnung einer Region
Erstellen oder Löschen einer Region innerhalb der Hierarchie, auch wenn sich ein Benutzer in der Region befindet
Hinzufügen oder Entfernen eines Prognosemanagers
Die granulare Sperre verbessert die Leistung für die folgenden Aufgaben nicht, da diese Aufgaben entweder bereits eine Sperre auf Zeilenebene vornehmen oder keine Sperre erfordern:
Ändern von Zugriffsebenen
Manuelle Zuweisung zu einem Account
Hinzufügen, Löschen oder Aktualisieren von Regeln
Anzeigen einer Vorschau von Accountzuweisungen
Zuweisen eines Objekts zu oder Entfernen eines Objekts aus einer Region
Weitere Details zur granularen Sperre finden Sie unter Entwerfen des Zugriffs auf Datensatzebene für Unternehmen.
Integration in eine externe zuverlässige Informationsquelle
Möglicherweise verfügen Sie bereits über ein bestehendes System zur Verwaltung von Regionen, die Sie als Ihre zuverlässige Informationsquelle (Single Source of Truth, SSOT) betrachten. Oder Sie verfügen über eine komplexe und große Reihe von Regionen, die sich möglicherweise sogar über mehrere Organisationen erstrecken. In diesen Szenarien sollten Sie ggf. Ihre externe SSOT in die Salesforce-Regionsverwaltung integrieren. Sie können benutzerdefinierte Felder für Regionen erstellen, bei denen es sich um externe IDs in Ihrer SSOT handelt, um diese Integration zu vereinfachen.
Wenn Sie Ihre Regionshierarchie in eine externe SSOT integrieren, können Sie Ihre Hierarchie aus der SSOT duplizieren und sie verwenden, um Ihre Regionen zu verwalten. Diese Art der Anpassung hat in der Regel nur geringe Auswirkungen auf die Leistung und Ihre duplizierten Hierarchien bleiben jederzeit mit Ihrer externen SSOT synchronisiert.
Bewährte Vorgehensweisen für die Regionszuweisung
Numerische Felder verwenden
Bei der Definition der Filterlogik für Ihre Zuweisungsregel sollten Sie Zahlenkriterien nicht als Textkriterien auswerten. Wenn die Daten in einem Feld numerisch sind, stellen Sie sicher, dass das Feld als Zahlenfeld definiert ist. Zahlenfelder, die als Textfelder definiert sind, behindern die Auswertungsleistung. Entsprechende Informationen finden Sie in der Salesforce-Hilfe unter "Ändern des benutzerdefinierten Feldtyps".
Anstatt Kriterien für Zeichenfolgenfelder zu definieren, sollten Sie Kriterien für numerische Felder definieren. Operatoren auf Zeichenfolgenfeldern unterscheiden nicht zwischen Groß- und Kleinschreibung, und die Nichtbeachtung der Groß-/Kleinschreibung kann sich auf die Leistung auswirken.
Architekt für Spitzenleistung
Verwenden Sie nach Möglichkeit vererbte Kriterien, um zu vermeiden, dass beim Zuweisen von Accounts ganze Zweige der Regionshierarchie berechnet werden müssen.
Wenn Standard-Accountzuweisungsregeln nicht flexibel genug sind, um Ihre Freigabeanforderungen zu erfüllen, sollten Sie die Verwendung von Zuweisungsregeln für Formelfelder erwägen.
Gestalten Sie Ihre direkten und vererbten Regeln so restriktiv wie möglich, um eine optimale Leistung zu erzielen.
Alternative Ansätze für Kriterienfelder erwägen
Wenn die Anzahl der Kriterieneinträge nicht Ihren Geschäftsanforderungen entspricht, können Sie mit Formelfeldern mehrere Datenfelder in einem Account kombinieren. Wenn Sie beispielsweise mehr als zehn Kriterienfelder benötigen, können Sie die Felder "BillingCountry" und "BillingState" zu einem einzigen Formelfeld zusammenfassen.
Wenn Kriterien auf den zugehörigen Datensätzen eines Accounts basieren, verwenden Sie Rollup-Zusammenfassungsfelder oder -Auslöser, um Daten in das Accountobjekt zu verschieben. Verwenden Sie dann diese Felder, um die Kriterien für Accountzuweisungsregeln festzulegen.
Keine Zuweisungsregeln zum Bereinigen von Daten verwenden
Vermeiden Sie die Verwendung von Regionszuweisungsregeln, um fehlerhafte Daten zu bereinigen, insbesondere wenn Sie festlegen, welchem Account ein Lead zugeordnet werden soll. Führen Sie eine Datenbereinigung außerhalb des Regionszuweisungsmoduls durch, um eine schlankere Regionsregelstruktur zu gewährleisten.
Hinweis zu Regionszuweisungsregeln: Wenn das Feld "Aus Regionszuweisungsregeln ausschließen" im Accountlayout aktiviert ist, wird die Zuweisungsregel nicht ausgelöst.
Korrektes Definieren von benannten Accounts
Die meisten Unternehmen, die ihre Vertriebsorganisationen nach Region verwalten, haben benannte Accounts, wobei die Hauptaccounts den Vertriebsmitarbeitern zugewiesen sind, die sie am besten verwalten können. Zu den wichtigsten Strategien zur Definition von benannten Accounts innerhalb der standardmäßigen Struktur von Accountzuweisungsregeln zählen:
Definieren von Accounts anhand des Namens in den Regelkriterien. Da Accountnamen sehr lang sein können, wird diese Strategie in der Regel für kleinere Kunden empfohlen, bei denen nur wenige benannte Accounts in einer Region definiert sind.
Definieren von Kriterien anhand von Accountnummern, die prägnanter sind als Accountnamen. Mit dieser Strategie können Organisationen mehr benannte Accounts in eine Region aufnehmen.
Entwicklung einer benutzerdefinierten Lösung, wenn keine der vorherigen Lösungen die entsprechende Skalierbarkeit bietet
Vermeiden der Verwendung von Regeln zum Zuweisen von Leads
Verwenden Sie beim Zuweisen von Leads die standardmäßigen Leadzuweisungsregeln oder einen separaten benutzerdefinierten Zuweisungsprozess. Konsolidieren Sie keine Daten in einer freigegebenen Regelstruktur. Wenn Sie eine freigegebene Regelstruktur verwenden müssen, über relativ wenige Leadzuweisungen verfügen und Ihre Leads nicht neu ausrichten müssen, sollten Sie in Erwägung ziehen, dass Ihre Leadzuweisungsregel Standard-Accountzuweisungsregeln verwendet.
Erstellen Sie zum Abrufen der Zuweisungen einen Auslöser, der:
Einen Dummy-Account mit den Daten des Leads erstellt
Den Lead für die Regionen freigibt, die dem Dummy-Account zugewiesen sind
Ein Rollback des Dummy-Accounts durchführt, sodass er nicht im System erstellt wird
Sie können diese Architektur und Standard-Accountzuweisungsregeln auch verwenden, um andere Objekte als Leads zuzuweisen.
Verwenden der Freigabe zum Bereitstellen von Overlay-Zugriff für Opportunities
Wenn Sie Ihre Regionen mit Ihren Opportunities überlagern müssen, können Sie die Regionsverwaltung entsprechend anpassen. Diese Art der Anpassung kann jedoch sehr komplex und schwierig zu verwalten sein.
Erwägen Sie stattdessen die Konfiguration von Profilen, Freigaberegeln oder manuellen Freigaben, um Overlay-Zugriff zu ermöglichen.
Verwenden von Force.com-APIs zum Automatisieren der Regelwartung
Einige Kunden weisen ihre Regionen monatlich, wöchentlich oder sogar täglich neu zu und senden häufige Aktualisierungen an eine extrem große Regelbasis. In diesen Fällen können Kunden von automatisierten Prozessen profitieren, die die Regelstruktur aktualisieren. Die Salesforce-Standardregelstruktur ist relational und bietet unserer breiten Kundenbasis ausreichend Flexibilität. Obwohl die Wartung dieser Standardregelstruktur für unsere größeren Kunden technisch machbar ist, ist die automatisierte Wartung aufgrund der relationalen Struktur sehr komplex.
Überlegen Sie, ob Sie die SOAP- oder REST-API verwenden möchten, um die Wartung der standardmäßigen Struktur von Accountzuweisungsregeln zu automatisieren. Vermeiden Sie nach Möglichkeit, die Standardregelstruktur in eine benutzerdefinierte Regelstruktur zu umwandeln.
000386766

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.