Erstellen einer Zugriffskonfiguration für Verantwortlichkeiten

Erstellen Sie Zugriffskonfigurationen für Verantwortlichkeiten, um mithilfe verschiedener Zuordnungstypen Zugriff für verschiedene Anwenderbeziehungen hinzuzufügen oder zu ändern.

Administratoren können diese Konfigurationen verwenden, um die Rollen zu definieren, die für den Zugriff auf bestimmte Tabellendatensätze erforderlich sind, einschließlich der Zugriffsebene. Mit neuen Filtern und Tabellenzuordnungen können Sie granulare Beziehungen modellieren, die eine Vielzahl von Verantwortlichkeiten in Ihrer Organisation darstellen.

Beispiel: Beginnend mit Zurich Release: Die Konfiguration des Zugriffs für die Verantwortlichkeit des Account-Managers wird aus dem Basissystem eingeführt. Mit dieser Zuständigkeit können Sie die Verantwortung des Account Managers einem bestimmten Account zuweisen. Diese Konfiguration gewährt Zugriff auf Accountinformationen zusammen mit zugehörigen Entitäten wie Fällen, verkauften Produkten und mehr.

Zuordnungstypen

Als Administrator können Sie dieses flexible Framework verwenden, um entweder eine Verantwortlichkeit mit anwenderdefinierten Zugriffsregeln zu erstellen oder vorhandene Konfigurationen nach Bedarf zu ändern. Mit den entsprechenden Zuordnungstypen können Sie Zugriffskonfigurationen für Verantwortlichkeiten für verschiedene Beziehungsmuster erstellen.

• Einfache Zuordnung
• Abhängige Zuordnung
• Erweiterte Zuordnung

Einfache Zuordnung

Sie können diese Zuordnung verwenden, wenn eine direkte Beziehung zwischen dem Anwender und dem Zieldatensatz besteht. Dieser Zuordnungstyp verwendet den direkten Feldabgleich und erfordert keine Zwischentabellen oder anwenderdefinierte Logik.

Abbildung : 1. Einfacher Zuordnungs-Workflow

Einfacher Zuordnungs-Workflow

In diesem Szenario wird erläutert, wie der Zugriff auf Falldatensätze basierend auf der direkten Beziehung eines Anwenders zum zugehörigen Account gewährt wird. Beispielsweise ist Anna eine Account-Manager für den Kundenaccount XYZ-Unternehmen. Sie benötigen Zugriff auf Falldatensätze, die direkt mit dem Unternehmen XYZ verknüpft sind. Da der Falldatensatz ein Feld für den zugehörigen Account enthält, kann das System den Zugriff von Anna einfach basierend auf der Rolle und der Account-ID validieren.

Das System bestimmt den Zugriff von Alex anhand der folgenden Logik:

• Anna öffnet einen Falldatensatz.
• Das System identifiziert den Account, der dem Fall zugeordnet ist.
• Überprüft die Tabelle der Account-Teammitglieder, um einen Datensatz zu finden, bei dem:
  • Der Anwender ist Anna
  • Die Verantwortung ist der Account Manager
  • Der Account stimmt mit dem im Fall aufgeführten Account überein
• Wenn ein übereinstimmender Datensatz gefunden wird, wird automatisch Zugriff auf den Fall gewährt.

Dieser Ansatz bestätigt, dass der Zugriff effizient gewährt wird, wenn eine klare 1-zu-1-Beziehung zwischen dem Anwender und dem Account besteht, der dem Fall zugeordnet ist.

Abhängige Zuordnung

Sie können diese Zuordnung verwenden, wenn der Zugriff über eine Zwischenbeziehung bestimmt werden muss, die häufig eine viele-zu-viele-Tabelle (M2M) umfasst. Dieses Setup ist häufig, wenn die Verbindung einer anfordernden Person zu einem Datensatz indirekt über zugehörige Elemente hergestellt wird.

Abbildung : 2. Abhängiger Zuordnungs-Workflow

Abhängiger Zuordnungs-Workflow

In diesem Szenario wird erläutert, wie der Zugriff auf Falldatensätze basierend auf der Beziehung einer anfordernden Person zu Installationsbasiselementen gewährt wird, die über eine Zwischentabelle zugeordnet sind. Beispielsweise ist Alex ein Teammitglied mit autorisierter Account-Verantwortung und erfordert Zugriff auf bestimmte Falldatensätze, die an Installationsbasiselemente gebunden sind. Der Zugriff von Alex hängt davon ab, ob diese Falldatensätze als autorisierte Partei für eines dieser Elemente aufgeführt sind. Die Beziehung zwischen dem Fall und dem Installationsbasiselement ist jedoch nicht direkt, sondern wird über eine separate betroffene Installationsbasistabelle verwaltet.

Das System bestimmt den Zugriff von Alex anhand der folgenden Logik:

• Alex öffnet einen Falldatensatz.
• Das System überprüft, ob der Fall mithilfe der Tabelle „Betroffene Installationsbasis“ mit Installationsbasiselementen verknüpft ist.
• Ruft die Installationsbasiselemente ab, die dem Fall zugeordnet sind.
• Das System überprüft, ob Alex mit der autorisierten Account-Rolle für eines der Installationsbasiselemente in der Tabelle „zugehörige Partei“ aufgeführt ist.
• Wenn Alex die erforderliche Rolle für ein übereinstimmendes Element innehat, wird automatisch Zugriff auf den Falldatensatz gewährt.

Dieser Ansatz bestätigt, dass der Zugriff nur gewährt wird, wenn eine gültige Beziehung zwischen der anfordernden Person und den Installationsbasiselementen besteht, wodurch ein sicherer Zugriff auch durch indirekte Zuordnungen erzwungen wird.

Erweiterte Zuordnung

Sie können diese Zuordnung in komplexen Szenarien verwenden, in denen der einfache beziehungsbasierte Zugriff unzureichend ist. Dieser Zuordnungstyp basiert auf anwenderdefinierter Skriptlogik, um den Zugriff der anfordernden Person über mehrere zugehörige Datensätze hinweg zu validieren.

Abbildung : 3. Erweiterter Zuordnungs-Workflow

Erweiterter Zuordnungs-Workflow

In diesem Szenario wird erläutert, wie der Zugriff auf Eskalationsdatensätze basierend auf der Beziehung der anfordernden Person zum zugehörigen Account bestimmt wird.

Beispielsweise ist Anna eine Account-Manager, die Zugriff auf bestimmte Eskalationsdatensätze benötigt. Einige dieser Eskalationsdatensätze sind an Fälle gebunden, die wiederum den von Anna verwalteten Accounts zugeordnet sind. Ein anwenderdefiniertes Skript identifiziert die zugehörigen Accounts und überprüft die Rolle von Anna, bevor Zugriff auf die Eskalationsdatensätze gewährt wird.

Das System bestimmt den Zugriff von Alex anhand der folgenden Logik:

1. Anna öffnet einen Eskalationsdatensatz.
2. Das System überprüft die Quelle der Eskalation:
   • Wenn die Eskalation mit einem Kundenfall verknüpft ist, identifiziert das System den Account, der diesem Fall zugeordnet ist.
   • Wenn die Eskalation direkt mit einem Account verknüpft ist, verwendet das System den Account-Datensatz.
3. Das System überprüft, ob Anna als Account-Manager für den identifizierten Account zugewiesen ist.
4. Wenn Anna dem Account zugewiesen ist, wird automatisch Zugriff auf den Eskalationsdatensatz gewährt.

Dieser Ansatz bestätigt, dass der Zugriff nur gewährt wird, wenn eine eindeutige Beziehung zwischen dem Anwender und dem Account besteht, unabhängig davon, ob der Link direkt oder über einen zugehörigen Fall erfolgt.