A department transfer can change who should see an employee’s data. A permission test that passed yesterday may therefore be insufficient today. This SuccessFactors exercise follows one fictional employee through a transfer and tests whether two HR users exchange access as the business requirement intends.
For the terminology behind the exercise, read the existing role-based permissions guide. The focus here is a repeatable before-and-after test with controlled evidence, rather than configuring a broad new role.
Define one precise access requirement
Assume fictional employee E-701 moves from Operations to Finance on 1 October. Test user H-OPS supports Operations employees; H-FIN supports Finance employees. The approved training requirement permits each HR user to view a selected department field for employees in their own assigned department and excludes compensation editing for both users.
The exercise assumes department-based target populations for the applicable employee-data permissions. Check the specific permission’s target-population behaviour in your tenant; the same restriction does not automatically govern every administrative feature. The requirement also excludes self-access exceptions and any other role that deliberately grants cross-department access.
Use only fictional records in an authorised sandbox. Record the tenant, module, permission, assigned role, target definition and date of the test. These details make a later result comparable.
Build the expected before-and-after matrix
| Test account | Operations membership | Finance membership | Compensation edit |
|---|---|---|---|
| H-OPS | Selected department field visible | Selected department field denied | Denied in both states |
| H-FIN | Selected department field denied | Selected department field visible | Denied in both states |
“Operations membership” and “Finance membership” describe the population state evaluated by the configured permission. They are not promises about exactly when a future-dated transfer will change access. Effective dating, group criteria, relationship settings and recalculation behaviour can affect that timing. Establish the intended behaviour for the tenant before writing the expected result.
Keep identities and test paths separate
Begin with the pre-transfer population state. Use separate authorised sessions for H-OPS and H-FIN, and verify the logged-in identity before each case. An administrator’s record view cannot substitute for either business user’s experience. If approved proxy testing is used, document both the operator and the effective test identity.
Test the selected field through the normal employee-search flow. Then attempt the same record through its supported direct navigation path. A hidden search result does not by itself prove the underlying data is protected. Capture whether the field is visible, masked, denied or unavailable; those observations can have different causes.
Check compensation editing separately using a safe, supported path without submitting any real pay change. Record the missing action or denial message. General profile visibility is not evidence of permission to edit a sensitive field.
Change one business fact and retest
- Save the pre-change role and population evidence. Confirm E-701’s current department and the future-dated transfer record.
- At the agreed test point, verify the department data and actual population membership evaluated by the permission. Do not infer membership solely from a job-history screenshot.
- Repeat the same view and sensitive-action cases with both accounts, using equivalent sessions and navigation paths.
- If reporting is in scope, rerun a saved report with the same filters and date. Reporting access requires its own check; it cannot be inferred from profile access. Record the report definition, supported population controls and the effective test identity.
- Compare each observation with the approved matrix and record the difference without widening permissions to make a test pass.
Investigate an unexpected retained permission
If H-OPS still sees the selected field after E-701 has entered the Finance population, inspect every relevant role assignment. Another role may grant the access independently. Also verify target membership, permission applicability and the tenant’s documented recalculation or session behaviour. Refresh or sign in again only as the approved test procedure specifies, and record that step so the retest remains reproducible.
If H-FIN cannot see the employee, check granted membership as well as target membership. Being responsible for Finance does not prove the test account received the intended role.
Acceptance evidence to retain
The exercise is complete when both users match the matrix for both evaluated population states, compensation editing remains denied, and each unexpected result has a documented explanation. Keep the eight planned user/state/action checks, their actual outcomes and the role evidence. Label unexecuted cases as planned; this article does not report completed tenant tests.
Use this brief when discussing practical coverage in Softenant’s SAP SuccessFactors course in Vizag. Confirm which modules, test permissions and practice access are available before building the exercise.