Aleksandra Milic

KBA 01 · Access and security

Access: Who, What, Whose Data

A practical way to describe an apparent access gap before anyone grants, copies, or broadens a permission.

Read time
About 6 minutes
Source
Public SAP Help
Level
Foundation
Reviewed
15 July 2026
By the end

You can name the access pattern, the evidence to collect, and the right owner in one sentence.

01 · Model

An access result has three questions inside it.

“They cannot see it” is a symptom. Role-Based Permissions become easier to reason about when the symptom is separated into the person, the action, and the target population.

Who

Which granted user?

Identify the exact user and the permission role or roles assigned to that user. A job title alone does not establish the active role assignment.

What

Which permission?

Name the page, field, action, or administrative capability expected. “Access to Employee Central” is too broad to test.

Whose data

Which target population?

Ask which employees or groups the permission should apply to. A user may hold a permission while the affected employee remains outside its target population.

02 · Evidence

Collect the narrow facts before comparing roles.

The order below reduces the chance of treating a business-rule mismatch, target-population boundary, or field-level difference as a generic “permission issue.”

  1. 01
    The exact user and expected business responsibilityRecord who is affected and who authorized the expectation.
  2. 02
    The exact employee, object, field, or actionDescribe what is missing without including unnecessary personal data.
  3. 03
    A privacy-safe reproductionNote the navigation path and expected result in an authorized test context.
  4. 04
    The role assignment, populations, and specific permissionInspect how the user enters the granted population, how the target is defined, and only then the relevant permission category or field access.
03 · First checks

Inspect first. Change only with authority.

These checks help produce a useful issue frame. They are not instructions to alter a live tenant.

Safe first checks

  • Confirm the exact expected action with the business owner.
  • Reproduce the difference through an authorized test path.
  • Separate granted population, permission, and target population.
  • Check whether effective-dated or workflow context changes what should be visible.
  • Document the smallest mismatch you can actually evidence.

Stop before

  • Copying a broad role from another user as a shortcut.
  • Granting access merely to prove that access changes the result.
  • Expanding a target population without business and security approval.
  • Sharing screenshots or exports containing unnecessary employee data.
  • Calling the issue “fixed” without retesting the intended boundary.
Owner boundary

The accountable business approver defines the legitimate need. The authorized SuccessFactors security owner reviews and implements any role, group, target-population, or permission change.

04 · Reason

Choose the next useful question.

This is a reasoning check, not an exam question. Select the best first move for the information provided.

Fictional scenario

What should happen first?

A manager sees a direct report in the organization chart but cannot view one job-information field. An administrator can. What should happen first?

Select an answer to reveal the reasoning.

05 · Source

Continue with current SAP guidance.

The links below are the public sources for this KBA; SAP documentation and the authorized tenant owner remain authoritative.

Independent summary

This KBA is original AMi knowledge material. It is not SAP-authored or SAP-approved, does not reproduce a tenant procedure, and may need revision as SAP releases and documentation change.