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.
Organizational dimensions
The following dimensions are delivered. Each has its own authorization object, assigned to object class ZSBF, and each uses 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 activity 03, display, is used. Write operations are unaffected, because they run through SAP business logic which performs its own checks.
Configuration
Two customizing tables control the feature.
Dimension catalogue
Table /SKYBFR/YAIODIM defines the dimensions listed above and is delivered with content. You do not normally change it.
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 3 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.
- 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 4 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.
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. |
| 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.