Organizational Authorization for Data Sources
Restricting Skybuffer AI data source reads to the organizational units each user is authorized for.
Skybuffer AI answers questions by reading data from your SAP system. This feature restricts what each user’s questions can return, so that a user only ever sees rows belonging to the organizational units they are authorized for.
It is configured per data source and is switched off on delivery. Installing the add-on changes nothing until you configure it.
Why you need it
When Skybuffer AI reads a table or a view, the read is performed by the framework rather than by a business transaction. Business transactions apply their own authorization checks; a direct read does not. Without this feature, a user who can reach a nominated data source receives every row it contains, including data for company codes, plants and sales organizations outside their responsibility.
Two restrictions already exist and are unaffected by this feature:
- Which data sources a user can read at all, controlled by data source nomination.
- Which columns are returned, controlled by the field list on the nomination record.
This feature adds the third restriction: which rows.
How it works
Authorization is maintained in PFCG, exactly like any other SAP authorization. You grant users the organizational units they may see, and the framework filters every read accordingly.
- A user asks a question. The framework prepares a read against a nominated data source.
- If that data source has an active organizational mapping, the framework determines which values of the relevant organizational unit the user is authorized for.
- Those values are added to the selection as an additional condition, so the database returns only authorized rows.
- If the user is authorized for nothing relevant, the request is refused rather than answered with an empty result.
The authorization check itself is the standard SAP check. Nothing in this feature grants access that a user’s roles do not already provide.
What the user sees
| Situation | Result |
|---|---|
| Authorized for everything relevant | Normal answer, no indication of filtering |
| Authorized for part of the data | Answer plus a note that results are limited by their authorizations and further records may exist |
| Authorized for nothing relevant | A message explaining they are not authorized, rather than an empty answer |
The distinction in the last row matters. An empty answer would invite the conclusion that no such records exist, which is not the same statement.
The note never lists the organizational units a user is authorized for, so the organizational structure is not disclosed through the conversation.
Where authorization comes from
Each dimension draws its authorization from one or more sources. A source is an authorization object the framework is told to read.
Sources within a dimension are alternatives. A user is authorized for a company code if any active source grants it. Adding a source can therefore only widen what a user sees, never narrow it.
Different dimensions are combined with and. A user reading sales documents needs both an authorized company code and an authorized sales organization.
Two kinds of source
Skybuffer objects, delivered and active out of the box. These answer a question no application object answers: may this user see this organizational unit through Skybuffer AI? Because they exist for that purpose alone, AI visibility can be reviewed, widened and narrowed as a decision in its own right, independently of any application.
Your own existing objects, configured by you. If your roles already grant company codes on a financial object or cost centre groups on the standard CO object, the framework can read those instead, and you maintain nothing new.
You can use either or both. Because sources are alternatives, activating one of your objects alongside a Skybuffer object cannot take access away from anyone.
One caution before reusing a standard object
A standard authorization object is application-scoped. An object granting financial documents in company code 1000 does not mean “may see company code 1000” — it means “may see financial documents in company code 1000”. A user may hold it and be deliberately excluded from personnel data in the same company code.
Configure it as the company code source and it governs every data source mapped to company code, personnel records included. Nothing fails; the user simply sees more than whoever designed the role intended.
So this is a decision to take per dimension: does this object legitimately mean “may see this organizational unit” for all the data you expose, or only for its own application?
Organizational dimensions
The following dimensions are delivered, each with a Skybuffer authorization object assigned to object class ZSBF and using the standard SAP authorization field, so PFCG provides the usual value help.
| Dimension | Authorization object | Field |
|---|---|---|
| Company code | /SKYBFR/OB | BUKRS |
| Controlling area | /SKYBFR/OK | KOKRS |
| Plant | /SKYBFR/OW | WERKS |
| Sales organization | /SKYBFR/OV | VKORG |
| Purchasing organization | /SKYBFR/OE | EKORG |
| Business area | /SKYBFR/OG | GSBER |
| Profit center | /SKYBFR/OP | PRCTR |
| Cost center | /SKYBFR/OC | KOSTL |
| Personnel area | /SKYBFR/OA | PERSA |
Only display access is used. Write operations are unaffected, because they run through SAP business logic which performs its own checks.
The activity value is configuration, not a fixed part of the product. If your own object is granted with a different activity, that is a configuration entry rather than a change request.
Authorization by group
A source can grant groups instead of individual values. This is how cost centre authorization by standard hierarchy works.
A user is authorized for a cost centre if either it was granted individually or it belongs to a group they are authorized for. The two are alternatives: a user authorized purely by group needs no individual grants at all, and a user with both keeps the sum of the two.
Groups are expanded through the hierarchy at every level, so authorizing a node also authorizes everything beneath it. Add a cost centre to a group, or add a subordinate group, and the authorization follows automatically with no change to roles or configuration.
Two limitations, both reported in the application log rather than hidden:
- Groups defined by a rule rather than a fixed list of members cannot be expanded reliably and are skipped.
- Formula lines inside a group carry no usable value range and are skipped.
Two worked examples
Cost centre authorization is the case customers most often already maintain, and there are two common shapes. Both are configuration only.
Example 1: cost centre groups on K_CSKS_SET
This is the object dedicated to cost centre group authorization.
Granted in the role:
| Field | Granted |
| ACTVT | 03 |
| KOKRS | 1000 |
| KSTGR | SALES |
Configure the check — one row per field of the object:
| Object | Field | Seq | Mode | Value | From dimension |
| K_CSKS_SET | ACTVT | 010 | L | 03 | |
| K_CSKS_SET | KOKRS | 020 | D | Controlling area | |
| K_CSKS_SET | KSTGR | 030 | V |
Then make it a source for the cost centre dimension:
| Dimension | Object | Grants | Active |
| Cost center | K_CSKS_SET | groups | X |
KOKRS is marked from dimension, because a cost centre group is defined within a controlling area. The framework supplies the controlling areas the user is authorized for, so the group check is qualified correctly without you maintaining anything twice.
Example 2: responsibility areas on K_CCA
Many CO installations authorize cost centres through K_CCA instead. It looks quite different, and it is still configuration only.
Granted in the role:
| Field | Granted |
| RESPAREA | a node of the standard hierarchy |
| CO_ACTION | one or more CO action codes |
| KSTAR | * |
Configure the check:
| Object | Field | Seq | Mode | Value | From dimension |
| K_CCA | CO_ACTION | 010 | L | display action code | |
| K_CCA | RESPAREA | 020 | V | ||
| K_CCA | KSTAR | 030 | X |
| Dimension | Object | Grants | Active |
| Cost center | K_CCA | groups | X |
Three points are worth understanding, because each is a decision rather than a mechanical entry.
The activity field is not ACTVT. K_CCA uses CO_ACTION, and its values are CO action codes rather than the usual activity numbers. Enter the code that means display. A wrong value here refuses a user who is in fact authorized, so confirm it rather than assume it.
RESPAREA grants groups, not values. A responsibility area is a node of the standard hierarchy. Configuring it as granting values would compare an individual cost centre against the granted node and deny it, even for a cost centre inside that node. Marking it as granting groups is what makes the hierarchy expand correctly.
KSTAR is disregarded. Cost element is not a dimension Skybuffer AI filters on, so the field is marked as ignored. As always, a disregarded field widens access — here harmlessly, since the roles grant *.
K_CCA has no controlling area field, so nothing is marked from dimension and no qualification takes place.
If both shapes appear in your roles
RESPAREA can hold either a hierarchy node or an individual cost centre. Where your roles use both, configure K_CCA twice for the cost centre dimension — once as granting groups and once as granting values. Sources are alternatives, so a user is authorized if either matches.
A difference worth verifying once
The standard CO check works upward: given a cost centre, it looks for an authorized node above it. Skybuffer AI works downward: given an authorized node, it expands to the cost centres beneath it.
For a granted node the two agree, and expansion covers subordinate nodes and directly assigned cost centres alike. It is still worth comparing one user’s filtered result against what a CO reporting transaction shows the same user, once, before you widen the rollout.
Configuration
Four customizing tables control the feature. Two are delivered and two are yours to maintain.
Dimension catalogue
Table /SKYBFR/YAIODIM defines the dimensions listed above and is delivered with content. You do not normally change it.
Authorization sources
Table /SKYBFR/YAIOSRC says which objects grant which dimension, and whether each grants values or groups. Delivered with one row per dimension pointing at the Skybuffer object. Add a row here to bring one of your own objects in.
Authorization check specification
Table /SKYBFR/YAIOAUT describes how each object is checked: one row per field of the object, saying whether the field carries a fixed value such as the activity, the organizational unit being tested, a value taken from another dimension, or is to be disregarded.
Delivered for the Skybuffer objects. You add rows here for any object of your own, once per object.
A field marked as disregarded widens access. If your object qualifies a sales organization with a distribution channel and you disregard the channel, a user restricted to one channel will see the whole sales organization through Skybuffer AI. The maintenance dialog will not let you set this by accident.
Data source mapping
Table /SKYBFR/YAIOMAP, maintained in SM30, is where you decide which data sources are restricted and how. It is delivered empty.
| Field | Meaning |
|---|---|
| Data source | The nominated table or view to restrict |
| Dimension | Which organizational dimension applies |
| Field name | The column on that data source holding the value |
| Strategy | How the column relates to the dimension: Direct or Derive |
| Lookup table, lookup fields | Used by Derive only |
| Active | The mapping is enforced only when this is set |
One data source can have several mappings, one per dimension. A user then needs authorization for all of them: the conditions are combined, not alternatives.
A data source with no mapping, or with no active mapping, is returned unfiltered.
Direct and Derive
Direct applies where the data source contains the organizational field itself. A sales order header carries the sales organization, so the authorized sales organizations are used as the filter directly. Prefer Direct wherever the field exists.
Derive applies where the data source does not contain the organizational field but contains something that leads to it. Plant data carries the plant but not the company code. You still authorize users by company code in PFCG; the framework translates those company codes into the corresponding plants through a lookup table and filters on plant.
Derive depends on the lookup being complete. If an organizational assignment is missing in your master data — a plant with no company code assignment, for example — rows for it will not be returned, and the reason is recorded in the application log. Direct cannot fail this way.
Getting the mapping right
The column holding an organizational value is not always named after it. Two examples from standard SAP:
- VBAK holds the company code in a field called `BUKRS_VF`, not BUKRS.
- PA0001 has a field called `WERKS` which is the personnel area, not the plant.
Mapping by field name will therefore both miss fields and mis-assign them. Use the *Propose Organizational Mappings* report, which matches on the dictionary check table instead and is described in its own topic.
Setting it up
Follow this order. Step 4 is the one that causes incidents when skipped.
- Identify the data sources to restrict. Run the proposal report and review what it finds. Complete any Derive mappings by hand.
- Save the mappings as inactive. Nothing is filtered yet.
- Decide the sources for each dimension. If you are reusing your own objects, add them to /SKYBFR/YAIOSRC and describe them in /SKYBFR/YAIOAUT now. A dimension with no active source cannot be resolved, and a mapping on it will refuse every user once activated. The proposal report marks such dimensions, so this is visible before you go further.
- Grant the authorization objects in the roles that need them. Do this *before* activating anything. A user who holds no authorization for a mapped dimension is refused outright once that mapping becomes active — not shown fewer rows, but refused. If you activate before maintaining roles, every affected request fails.
- Activate one data source for one user group. Confirm the results are both correct and complete. “Complete” is the part worth checking: a user should still see everything they are entitled to.
- Widen gradually. There is no simulation mode. A mapping either filters or it does not, so no setting can be mistaken for protection that is not actually in force. This also means the effect of a mapping is not visible until you activate it, which is why step 5 recommends a single data source and a single group.
Performance
Determining a user’s authorized values costs one read of a small configuration table plus a set of in-memory authorization checks. For company code, sales organization and similar dimensions this is negligible.
Two dimensions are different, because their master data is large: cost center and profit center. For these, the framework instead examines only the values actually present in the answer being prepared, which is normally a handful. This is preconfigured and needs no attention unless you see slow responses on data sources mapped to those dimensions.
Group authorization is usually cheaper than individual authorization, not more expensive: a group covering several thousand cost centres is expressed as a handful of value ranges rather than a list of several thousand values.
Expanding a hierarchy is a read that cannot be avoided, and it happens per request. In practice it is small. If you see slow responses on a busy data source whose dimension has a group source, tell Skybuffer support before changing configuration yourself.
Data protection note
For cost center and profit center, the framework reads the distinct values of that one column from the data source in order to decide which values to check. This read can touch rows the user is not authorized for.
Those values never leave the framework. Unauthorized values are discarded before the answer is prepared, and no row or field value from that read is returned to the user, passed to the language model, or written to the log. The authorization decision itself is always the standard SAP check.
If your data protection policy does not permit this read at all, the dimension can be reconfigured to examine only its master data table instead. This is a supported setting and requires no code change. Contact Skybuffer support to have it adjusted.
Monitoring and troubleshooting
Diagnostic messages are written to the application log and viewed in SLG1.
| Symptom | Likely cause |
|---|---|
| A user is refused entirely on a data source that used to work | The mapping was activated before the authorization object was granted in their role. Check the role, then retry. |
| A user sees fewer rows than expected and the answer says results are limited | Working as designed. Compare their authorized values against the data they expect. |
| Rows are missing with no note about limitation, on a Derive mapping | An organizational assignment is missing in master data. SLG1 records this separately from a lack of authorization. |
| Every user is refused on one data source | Configuration error: the mapped column no longer exists, or the mapping references something unavailable. SLG1 identifies which. |
| Nothing is filtered at all | No active mapping exists for that data source. |
| Every user is refused on one dimension, right after go-live | The dimension has no active source. Check /SKYBFR/YAIOSRC. |
| A user authorized only by group is refused | Confirm the group object is an active source for that dimension and is described in /SKYBFR/YAIOAUT. |
| A group’s cost centres are missing | The group may be rule-based, or the line may be a formula. Both are skipped and recorded in SLG1. |
| A user sees more than their role allows within an organizational unit | A field is configured as disregarded on a reused object. See Authorization check specification. |
| Slow responses on cost center or profit center data | See Performance. |
When reporting an issue to support, include the SLG1 entry. It records which dimensions were applied and the verdict reached, which is usually enough to identify the cause without reproducing the problem.
Scope
Covered. Read access to nominated tables and views, both for direct questions and for the filtering of replicated data snapshots.
Not covered, and not needed. Create, change and post operations. These run through SAP business logic, which applies its own authorization checks independently of this feature.
Not covered by design. Column-level restriction, which is configured separately on the data source nomination record.