Die folgenden Beispiele stellen Genehmigungs-Policys auf Anwendungs-, Dimensions-, Knotentyp- und Hierarchiesetebene dar und zeigen auf, wie die Genehmigungen mit verschiedenen Policy-Einstellungen verarbeitet werden.
Beispiel 1: Genehmigungs-Policys auf Anwendungsebene
Sehen wir uns zunächst ein einfaches Beispiel dazu an, wie Genehmigungen auf Basisebene funktionieren. In diesem Beispiel gibt es eine Genehmigungs-Policy auf Anwendungsebene, die besagt, dass mindestens zwei Personen aus der Gruppe "GL Govern" alle Änderungen an den Kontenplänen genehmigen müssen.
Tabelle 29-1 Beispiel 1: Policy-Einstellungen auf Anwendungsebene
Fusion GL-Anwendung | Dimension | Knotentyp | Hierarchieset |
---|---|---|---|
Policy A
|
Dimension des Kontos | Knotentyp des Kontos | Hierarchieset des Kontos |
Die Gruppe "GL Govern" besteht aus Barry, Julie und Jane. Tom ist Eigentümer der Fusion GL-Anwendung.
Genehmigungsworkflow.
Beispiel 2: Deadlock-Eskalation
Sehen wir uns das Beispiel erneut an. Dieses Mal wurden Barry und Jane jedoch aus der Gruppe "GL Govern" entfernt.
Tabelle 29-2 Beispiel 2: Policy-Einstellungen für Deadlock-Eskalation
Fusion GL-Anwendung | Dimension | Knotentyp | Hierarchieset |
---|---|---|---|
Policy A
|
Dimension des Kontos | Knotentyp des Kontos | Hierarchieset des Kontos |
Die Gruppe "GL Govern" besteht nur aus Julie. Tom ist Eigentümer der Fusion GL-Anwendung.
Genehmigungsworkflow.
Obwohl für die Policy zwei Genehmiger aus der Gruppe "GL Govern" erforderlich sind, ist in dieser Gruppe nur Julie enthalten. Da es zum Erfüllen der Policy-Anforderungen keine weiteren Genehmiger gibt, kommt es zu einem Deadlock. Die Anforderung wird daher an Benutzer eskaliert, die in der Anwendung über die Berechtigung Datenmanager verfügen. Da Tom Eigentümer der Anwendung ist, enthält seine Berechtigung Eigentümer die Berechtigung Datenmanager.
Beispiel 3: Genehmigungs-Policy auf Dimensionsebene - Seriell
Sehen wir uns als Nächstes eine Policy des Typs "Seriell" auf Dimensionsebene an. In diesem Beispiel muss Josh die Anforderung als Erstes, gefolgt von Frank und einer weiteren Person aus der Gruppe "Accounting" genehmigen.
Tabelle 29-3 Beispiel 3: Policy-Einstellungen auf Dimensionsebene - Seriell
Anwendung | Dimension | Knotentyp | Hierarchieset |
---|---|---|---|
Planning-Anwendung |
Dimension des Kontos Policy A
|
Knotentyp des Kontos | Hierarchieset des Kontos |
Die Gruppe "Accounting" besteht aus James und Heather.
Genehmigungsworkflow.
Beispiel 4: Genehmigungs-Policy für Knotentyp- und Hierarchiesetebene
Während Genehmigungs-Policys auf Anwendungs- und Dimensionsebene für alle Anforderungsaktionen angewendet werden, werden Policys auf Knotentyp- und Hierarchiesetebene nur auf bestimmte Anforderungsaktionen angewendet. Policys für einen Knotentyp werden nur für Anforderungen angewendet, die Knoten hinzufügen oder löschen oder Knoteneigenschaften aktualisieren. Policys für ein Hierarchieset werden nur für Anforderungen angewendet, die Knoten in einem Hierarchieset einfügen, entfernen, verschieben, die Reihenfolge ändern oder Knotenbeziehungseigenschaften aktualisieren.
Sehen wir uns zur Verdeutlichung zwei Anforderungen für ein Beispiel an, in dem Policys für den Knotentyp und das Hierarchieset vorhanden sind. Die erste Anforderung aktualisiert eine Knoteneigenschaft. Es wird also nur die Policy im Knotenset angewendet. Die zweite Anforderung fügt Konten hinzu. Dies hat Auswirkungen auf den Knotentyp und das Hierarchieset. Daher werden beide Policys angewendet.
Tabelle 29-4 Beispiel 4: Policy-Einstellungen für Knotentyp- und Hierarchiesetebene
Anwendung | Dimension | Knotentyp | Hierarchieset |
---|---|---|---|
Planning-Anwendung |
Dimension des Kontos |
Knotentyp des Kontos Policy A
|
Hierarchieset des Kontos Policy B
|
Weitere Hintergrundinformationen zu den Anforderungen:
Sehen wir uns zunächst eine Anforderung zum Aktualisieren von Knoteneigenschaften an. Aktualisierungen von Knoteneigenschaften sind nur von Policys für den Knotentyp betroffen.
Genehmigungsworkflow für Anforderung 1:
Hinweis:
Da eine Aktualisierung der Knoteneigenschaft keine Auswirkungen auf das Hierarchieset hat, erhält die Gruppe "EssAdmins" keine Genehmigungsanforderung.Sehen wir uns als Nächstes eine zweite Anforderung an, dieses Mal zum Hinzufügen von Knoten. Wie zuvor wird die Policy im Knotentyp angewendet, da die Anforderungsaktion Knoten hinzufügt. Bei dieser Anforderung wird jedoch auch die Policy im Hierarchieset angewendet, da Aktionen zum Hinzufügen Aktionen zum Einfügen in hierarchiebasierten Ansichtspunkten erstellen.
Genehmigungsworkflow für Anforderung 2:
Hinweis:
Da James über die implizite Berechtigung Teilnehmer (lesen) für den Knotentyp, jedoch nicht für das Hierarchieset verfügt, muss er die Anforderung im Anforderungsinspektor genehmigen. Informationen hierzu finden Sie unter Policys und Berechtigungen.Hinweis:
Da Rachel über die implizite Berechtigung Teilnehmer (lesen) für den Knotentyp, jedoch nicht für das Hierarchieset verfügt, muss sie die Anforderung im Anforderungsinspektor genehmigen. Informationen hierzu finden Sie unter Policys und Berechtigungen.Hinweis:
Da die Gruppe "EssAdmins" über die implizite Berechtigung Teilnehmer (lesen) für das Hierarchieset verfügt, verfügt sie auch über die implizite Berechtigung Teilnehmer (lesen) für den Knotentyp. Die Gruppe kann eine Ansicht öffnen und das Hierarchieset durchsuchen, um die Anforderung zu genehmigen. Informationen hierzu finden Sie unter Policys und Berechtigungen.Beispiel 5: Genehmigung mit aktivierter Anreicherung
Wenn die Anreicherung in einer Genehmigungs-Policy aktiviert wird, können Genehmiger mit dem Zugriff Teilnehmer (schreiben) auf ein beliebiges Datenobjekt in der Ansicht für die Anforderung vor der Genehmigung ändern.
In diesem Beispiel wird eine Anforderung in einer Verwaltungssicht mit Ansichtspunkten für drei Anwendungen gestellt: General Ledger, Planning und Consolidation. Jede Anwendung hat eine Genehmigungs-Policy auf Anwendungsebene, und für die GL- und Planning-Policys ist die Anreicherung aktiviert.
Tabelle 29-5 Beispiel 5: Genehmigung mit Anreicherung
General Ledger-Anwendung | Planning-Anwendung | Consolidation-Anwendung |
---|---|---|
HB-Genehmigungs-Policy
|
Planning-Genehmigungs-Policy
|
Consolidation-Genehmigungs-Policy
|
Genehmigungsworkflow: