In einem Zugriffsergebnis stecken drei Fragen.
«Sie können es nicht sehen» ist ein Symptom. Role-Based Permissions lassen sich leichter durchdenken, wenn das Symptom in die Person, die Aktion und die Zielpopulation zerlegt wird.
Welche berechtigte Nutzerin bzw. welcher berechtigte Nutzer?
Identifizieren Sie die genaue Nutzerin bzw. den genauen Nutzer und die Berechtigungsrolle oder -rollen, die dieser Person zugewiesen sind. Ein Stellentitel allein belegt die aktive Rollenzuordnung nicht.
Welche Berechtigung?
Benennen Sie die erwartete Seite, das Feld, die Aktion oder die administrative Fähigkeit. «Zugriff auf Employee Central» ist zu allgemein, um es zu testen.
Welche Zielpopulation?
Fragen Sie, für welche Mitarbeitenden oder Gruppen die Berechtigung gelten soll. Eine Nutzerin bzw. ein Nutzer kann eine Berechtigung besitzen, während die betroffene Person ausserhalb der Zielpopulation bleibt.
Sammeln Sie die eng umrissenen Fakten, bevor Sie Rollen vergleichen.
Die untenstehende Reihenfolge verringert die Gefahr, eine Abweichung bei Geschäftsregeln, eine Grenze der Zielpopulation oder einen Unterschied auf Feldebene als generisches «Berechtigungsproblem» zu behandeln.
- 01Die genaue Nutzerin bzw. der genaue Nutzer und die erwartete fachliche VerantwortungErfassen Sie, wer betroffen ist und wer die Erwartung autorisiert hat.
- 02Die genaue Person, das Objekt, das Feld oder die AktionBeschreiben Sie, was fehlt, ohne unnötige Personendaten aufzunehmen.
- 03Eine datenschutzkonforme ReproduktionNotieren Sie den Navigationspfad und das erwartete Ergebnis in einem autorisierten Testkontext.
- 04Die Rollenzuordnung, die Populationen und die spezifische BerechtigungPrüfen Sie, wie die Nutzerin bzw. der Nutzer in die berechtigte Population gelangt, wie das Ziel definiert ist, und erst dann die relevante Berechtigungskategorie oder den Feldzugriff.
Zuerst prüfen. Nur mit Befugnis ändern.
Diese Prüfungen helfen, eine nützliche Problemeingrenzung zu erstellen. Sie sind keine Anweisung, einen Produktivmandanten zu verändern.
Sichere erste Prüfungen
- Bestätigen Sie die genaue erwartete Massnahme mit der fachlich verantwortlichen Person.
- Reproduzieren Sie die Differenz über einen autorisierten Testpfad.
- Trennen Sie berechtigte Population, Berechtigung und Zielpopulation.
- Prüfen Sie, ob der stichtagsbezogene oder der Workflow-Kontext ändert, was sichtbar sein sollte.
- Dokumentieren Sie die kleinste Abweichung, die Sie tatsächlich belegen können.
Vorher stoppen
- Als Abkürzung eine breite Rolle von einer anderen Nutzerin bzw. einem anderen Nutzer kopieren.
- Zugriff nur gewähren, um zu beweisen, dass der Zugriff das Ergebnis verändert.
- Eine Zielpopulation ohne fachliche und sicherheitsseitige Freigabe erweitern.
- Screenshots oder Exporte mit unnötigen Mitarbeiterdaten teilen.
- Das Problem als «behoben» bezeichnen, ohne die beabsichtigte Grenze erneut zu testen.
Die rechenschaftspflichtige fachliche genehmigende Person definiert den berechtigten Bedarf. Die autorisierte SuccessFactors-Sicherheitsverantwortliche prüft und implementiert jede Änderung an Rolle, Gruppe, Zielpopulation oder Berechtigung.
Wählen Sie die nächste nützliche Frage.
Dies ist eine Argumentationsprüfung, keine Prüfungsfrage. Wählen Sie den besten ersten Schritt für die bereitgestellten Informationen.
Was sollte zuerst geschehen?
Eine Führungskraft sieht eine direkt unterstellte Person im Organigramm, kann aber ein Feld der Job Information nicht einsehen. Ein Administrator kann das. Was sollte zuerst geschehen?
Wählen Sie eine Antwort, um den Gedankengang aufzudecken.
Mit den aktuellen SAP-Vorgaben fortfahren.
Die untenstehenden Links sind die öffentlichen Quellen für diesen KBA; die SAP-Dokumentation und die autorisierte Mandantenverantwortliche bleiben massgebend.
- SAP Help · Role-Based Permissions
Konzept- und Implementierungsdokumentation für das rollenbasierte Berechtigungsmodell.
- SAP Help · Latest Role-Based Permissions experience
Aktuelle öffentliche Anleitung für Administratoren, die die neuere RBP-Oberfläche nutzen.
Dieser KBA ist eigenständiges AMi-Wissensmaterial. Er ist nicht von SAP verfasst oder freigegeben, gibt kein Mandantenverfahren wieder und kann Überarbeitung erfordern, wenn sich SAP-Releases und -Dokumentation ändern.