Lesson 3 of 5
Filters and authorizations
9 min
Two things decide which data a report shows: the filters the user or the report applies, and the data the user is allowed to see. Both must be tested. A filter that does not work shows the wrong data to the right person. An authorization that does not work shows the right data to the wrong person.
Testing filters and variants
Analytical apps and list reports offer filter bars, default values, saved variants and drill-down. Test each filter that a business user relies on, using data where you know what should appear and what should not.
- Positive: filter on plant 1710 and confirm only plant 1710 data appears, with the right total.
- Negative: confirm plant 1720 data is excluded, by checking a known 1720 document is absent.
- Multiple values and ranges: plants 1710 and 1720 together equal the sum of each separately.
- Empty: a selection with no data shows nothing, not an error or another selection's data.
- Defaults and variants: a delivered or saved default does not silently restrict or widen the result; check the variant's filters after an upgrade.
- Drill-down and navigation: filters are carried over when you jump to line items or another app.
How restricted access works
In SAP S/4HANA, user access is granted through business roles that carry authorizations. For embedded analytics, CDS views can carry access controls (defined in DCL, the data control language) that link the view to authorization objects. When a user runs a query, the system filters the rows to those the user's roles allow, for example only company codes or sales organizations in the user's authorization. Delivered views usually come with access controls; custom views need them defined by the developer.
The important consequence for testers: a missing row authorization usually produces no error. The user simply sees fewer rows, or more rows than they should. In classic SAP GUI, a failed authorization check often shows a message, and transaction SU53 shows the last failed check. With row-level filtering in analytical apps, there is often nothing to see except the numbers themselves.
- Does the user see the app or tile at all?Yes → check data · No → business role or catalog missing; expected if the user should not have it
- Do the totals match the expected total for the user's own scope?Yes → check exclusions · No → fewer rows: authorization too narrow; more rows: restriction missing
- Is a known out-of-scope document absent?Yes → restriction works · No → over-exposure defect, high severity
- Do drill-down and export respect the same restriction?Yes → pass · No → defect: the restriction is applied in one path only
Designing authorization tests for reports
Use test users with the real production roles, never a tester's broad user. For each sensitive report, pick at least one user who should see everything, one with a restricted scope and one who should not see the report. At Contoso, sales reps are restricted to their sales office, plant controllers to their plant, and only finance sees margins.
| Test user | Role | Expected in margin report |
|---|---|---|
| Dan's test user | Finance process owner | All of company code 1710, both plants, margins visible |
| Plant controller Chicago | Plant controller | Plant 1720 only; Detroit absent |
| Sales rep Detroit | Sales representative | App not available, or no margin measures |
| Maria's test user | Order-to-cash key user | Sales volumes for sales area 1710 / 10 / 00; no cost or margin |
Authorization test matrix for one report.
Keep two questions apart when you test. Can the user open the app? That is decided by the business roles and launchpad catalogs assigned to the user. Which data does the app show? That is decided by the authorization values in those roles and the access controls on the views. A user can have the app and no data, or the app and too much data. In SAP S/4HANA Cloud Public Edition, business roles are maintained with SAP-delivered apps and carry restrictions such as read and write access by organizational value; the test principle is the same.
| Question | Decided by | Failure looks like | Test |
|---|---|---|---|
| Can the user open the app? | Business roles and launchpad catalogs | Tile missing, or present for someone who should not have it | Log on as each test user and look for the tile |
| Which rows does the app show? | Authorization values in roles and access controls on views | Totals too low (too narrow) or too high (over-exposed) | Compare totals with each user's expected scope; check a known out-of-scope document |
| Which measures are visible? | Query design and role-specific apps | Margins or costs shown to sales users | Check columns and drill-down for each role |
What would you do?
During UAT, a Chicago plant controller tells Priya that a stock value report looks "a bit high". Priya's tester ran the same report with a broad test user and found it correct. What should Priya do next?
- Test filters positively, negatively, with ranges, empty selections, defaults and drill-down.
- CDS access controls filter rows by the user's authorizations, usually without an error message.
- Use test users with real production roles; check both too few and too many rows.
- Check that a known out-of-scope document is absent.
- Exports, scheduled reports and dashboards must respect the same restrictions.
Check your understanding · not graded
Lesson check
1. What usually happens when a CDS access control filters out rows a user may not see?
2. Which test shows that a plant filter actually excludes the other plant?
3. Why test with users holding real production roles?
4. A restriction works on screen but not in the spreadsheet export. How do you rate it?