Lesson 3 of 5
Restrictions
10 min
Listen to this lesson
Catalogs decide which apps a user can open. Restrictions decide which data the user can see and change inside those apps. Contoso's AP clerk Ana needs the supplier invoice apps, but only for company code 1710; the same apps in the hands of a clerk at Contoso Parts Distribution should work only for company code 1810. That difference is a restriction, not a different catalog.
Public Edition: restriction types and access categories
In Public Edition, each business catalog declares the restriction types it supports; you can see them on the catalog's Restriction Types tab in the Business Catalogs app, or by opening the catalog from a role in Maintain Business Roles. A restriction type groups restriction fields such as company code, plant, purchasing organization or sales organization. For each field you choose values for an access category:
- Write (shown together with read and value help): what the user may create or change.
- Read (with value help): what the user may display.
- Value Help: what the user sees in drop-down and search help lists.
Each access category can be set to Unrestricted, Restricted (you then pick values) or No Access. SAP's learning material notes that write access starts without any authorization, so a new role is display-only until you deliberately grant write values. It also warns against Unrestricted unless it is truly necessary. A leading restriction lets you set a field once, say company code 1710, and have the value flow to every restriction type in the role that uses the same field.
- Does the job need to change this data?Yes → set Write to Restricted with the job's values · No → leave Write at No Access
- Does the job need to see other units' data?Yes → Read restricted to those units only · No → Read equal to the write values
- Is the same field used across many restriction types?Yes → make it a leading restriction so values stay consistent · No → maintain it per type
- Tempted to choose Unrestricted?Yes → document the business reason and get the owner's approval · No → keep explicit values
Private Edition: organizational levels and derived roles
Private Edition has no restriction types. The same outcome comes from the classic authorization concept: organizational level fields (company code, plant, sales organization, purchasing organization) are set once per role in PFCG, and every authorization object that contains them picks up the values. To give the same job to different organizations, you build a master role with all the functional values and create derived roles that differ only in their organizational values.
For Contoso, Nadia builds one master AP role and derives two roles from it: one with company code 1710 for Contoso Motor Co., one with 1810 for Contoso Parts Distribution. When Wave 2 adds Alternadores del Norte, a third derived role with company code 1910 is all that is needed. Read-wider-than-write is handled with a separate display role (for example, display for 1710 and 1810) because a single authorization grants its activities for all its organizational values.
| Need | Public Edition | Private Edition |
|---|---|---|
| Limit Ana to company code 1710 | Write and Read restricted to 1710 | Organizational level company code = 1710 in the derived role |
| Same job for 1810 | A second role with different restriction values | Another derived role from the same master |
| Display other units | Read access wider than Write access | A separate display role for the extra units |
| Keep a value consistent | Leading restriction | Organizational level field |
Restrictions are where most role defects hide, because they are invisible until the user looks at data. A tile works, the app opens, and the list is simply shorter than it should be, or a user posts happily into a company code they should never touch. Both outcomes look normal on screen. That is why the next lessons treat restrictions as a test design problem, not only a build task.
What would you do?
A Contoso subsidiary in a what-if Public Edition rollout needs a buyer who can create purchase orders for purchasing organization 1710 and display orders for all purchasing organizations. A colleague suggests setting the purchasing organization to Unrestricted for both Read and Write to save time. What should Nadia do?
- Catalogs control which apps; restrictions control which data inside them.
- Public Edition uses restriction types, fields and access categories: Write, Read and Value Help.
- Write starts with no access; avoid Unrestricted unless the business reason is documented.
- Private Edition achieves the same with organizational levels and derived roles.
Check your understanding · not graded
Lesson check
1. What does a restriction type group together in Public Edition?
2. What is the effect of marking company code as a leading restriction in a role?
3. How does Private Edition give the same job to two company codes with the least maintenance?
4. Why are restriction defects hard to spot in functional testing?