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 reads the values of the relevant organizational unit that the user has actually been granted, from the user’s own authorization data.
Those values are added to the selection as an additional condition, so the database returns only authorized rows.
Before the answer is prepared, a sample of the values the query will return is checked against the standard SAP authorization check. If the check disagrees with the condition on even one value, the request is refused rather than answered.
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

Nine dimensions are delivered.

Dimension	Field
Company code	BUKRS
Controlling area	KOKRS
Plant	WERKS
Sales organization	VKORG
Purchasing organization	EKORG
Business area	GSBER
Profit center	PRCTR
Cost center	KOSTL
Personnel area	PERSA

Each dimension is granted through one or more authorization sources. A source is simply an authorization object that says something about that dimension.

Delivered sources. Each dimension has its own Skybuffer object, assigned to object class ZSBF, using the standard SAP authorization field so that PFCG provides the usual value help: /SKYBFR/OB for company code, /SKYBFR/OK for controlling area, /SKYBFR/OW for plant, /SKYBFR/OV for sales organization, /SKYBFR/OE for purchasing organization, /SKYBFR/OG for business area, /SKYBFR/OP for profit center, /SKYBFR/OC for cost center and /SKYBFR/OA for personnel area.

Only activity 03, display, is used. Write operations are unaffected, because they run through SAP business logic which performs its own checks.

Your own sources. Most customers already grant these units through standard SAP objects and would rather not maintain a second set of roles. You can therefore register any authorization object as a source for a dimension — K_CCA for cost center, F_BKPF_BUK for company code, V_VBAK_VKO for sales organization, or a customer object of your own.

A dimension can have several sources at once. They are alternatives: a user authorized through any one of them is authorized. This is what lets you migrate gradually, or run standard and Skybuffer objects side by side.

Value sources and group sources

A source grants a dimension in one of two ways.

A value source grants individual values. /SKYBFR/OC-KOSTL granting cost center 4711 is a value source.

A group source grants a node of a standard hierarchy, and every value beneath that node follows. K_CCA-RESPAREA granting the cost center group SB205020 is a group source: the user becomes authorized for every cost center in that group and in every group below it.

Group sources are usually the better fit where your organization already maintains standard hierarchies, because a reorganization changes the hierarchy rather than every role. One object can be registered twice, once as each kind, where a field can hold either form — K_CCA-RESPAREA accepts both an individual cost center and a hierarchy node.

Group sources are available only on systems with the classic Set framework. Where it is absent, a group source contributes nothing and the other sources of the dimension still answer.

Configuration

Four customizing tables control the feature. The first two describe how your organization grants authorizations; the last two describe your data.

Table	Maintained in	Purpose
/SKYBFR/YAIODIM	SM30	The nine dimensions. Delivered with content
/SKYBFR/YAIOSRC	SM30	Which authorization objects grant which dimension
/SKYBFR/YAIOAUT	SM30	How each object is checked: which field carries which value
/SKYBFR/YAIOMAP	SM30	Which data sources are restricted, and on which column

Dimension catalogue — /SKYBFR/YAIODIM

Delivered with content. You do not normally change it. It records, per dimension, the dictionary check table and domain used to recognize the dimension in a data source, and — for cost center and profit center — the dimension that qualifies their hierarchies, which is the controlling area.

Authorization sources — /SKYBFR/YAIOSRC

Field	Meaning
Dimension	Which dimension this source grants
Object	The authorization object
Kind	Value or Group
Active	The source is consulted only when this is set

Check specification — /SKYBFR/YAIOAUT

One row per field of the object, telling the framework how to build the check.

Mode	Meaning
Value	This field carries the organizational value or hierarchy node. Exactly one per object
Literal	This field is checked against a fixed value, normally activity 03
Ignore	This field is not checked

The Group form column on the Value row says how the object expects a hierarchy node to be identified: as a bare group name, or as an encoded reference. K_CCA and K_ORDER use the encoded form, where the controlling area and the node name are concatenated after the letters HI.

As delivered, K_CCA is specified with RESPAREA as the value field in encoded form, and CO_ACTION and KSTAR ignored.

Data source mapping — /SKYBFR/YAIOMAP

Delivered empty. This is where you decide which data sources are restricted.

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. Where such a data source carries a column that the framework recognizes as an organizational unit, a warning is written to the application log on every read, so an omission is visible rather than silent.

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.

Derive cannot be combined with a group source, because a hierarchy node expands to intervals of values rather than to a list that can be translated.

Cost centers and profit centers across controlling areas

Cost center and profit center numbers are only unique within a controlling area. The same number 5020 can exist in two controlling areas and mean two different things.

Where these dimensions are granted by group, the framework records which controlling area each hierarchy node came from and pairs it with the data source’s own controlling area column. A user granted node 5020 in controlling area SB20 therefore sees SB20‘s cost center 5020 and not another area’s.

This requires the data source to carry a controlling area column and that column to be mapped as well. Where it does not, the intervals are applied without the qualification and a warning is written to the application log. If your data sources span several controlling areas, map the controlling area dimension alongside the cost center or profit center one.

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 and domain instead and is described in its own topic.

Setting it up

Follow this order. Step 4 is the one that causes incidents when skipped.

Decide how your organization grants these units. If you already grant cost centers through K_CCA or company codes through F_BKPF_BUK, register those objects in /SKYBFR/YAIOSRC and specify them in /SKYBFR/YAIOAUT. Otherwise use the delivered Skybuffer objects.
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 5 recommends a single data source and a single group.

Authorizations that leave the value field empty

An authorization can hold an object while leaving its organizational field empty — an incomplete role, a template that was never finished, a field left unmaintained after an object was extended. Such an authorization grants nothing, which is standard SAP behaviour and correct.

It is worth knowing about because the symptom is confusing. In SU53 the user appears to hold the object, so the natural conclusion is that the authorization should be working. The framework therefore reports these separately: the application log records how many of the user’s authorizations for an object leave the field empty, so this case is distinguishable from not holding the object at all.

If a user who “has K_CCA” sees nothing, this is the first thing to check.

Performance

Determining a user’s authorized values costs one read of the user’s own authorization data per authorization object, plus a small number of in-memory authorization checks. The cost is proportional to what the user has been granted, not to the size of your system: a user granted three cost center groups costs the same whether the system holds four hundred cost centers or four hundred thousand.

Two additional reads of the data source can occur:

Verification. A sample of up to 200 distinct values of the mapped column, restricted by the question’s own selection, is checked against the standard authorization check before the answer is prepared. This runs on every filtered read.
Wildcard resolution. Where a role grants a value with a wildcard, such as a cost center value of 47*, the framework reads the matching values and checks each one individually rather than interpreting the pattern itself. This runs only where such a value is granted.

Neither read is affected by the size of the master data.

Data protection note

The two reads described above read the mapped column from the data source, restricted by the question’s own selection. They can therefore 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.

The verification read cannot be switched off, because it is what guarantees that the filter the framework applies agrees with the standard check. Earlier versions offered a master data alternative; it has been withdrawn, because it could not provide that guarantee.

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 holds the object but is refused, and SU53 shows nothing wrong	The authorization leaves the organizational field empty and grants nothing. SLG1 counts these explicitly.
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.
A user sees far more than expected on a data source restricted by hierarchy	Check how high the granted node sits. A node near the top of a standard hierarchy legitimately expands to almost everything.
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 source object is not specified correctly. SLG1 identifies which.
A user is refused with a message that the filter could not be verified	The filter disagreed with the standard check on at least one value. Report this to Skybuffer support with the SLG1 entry.
Nothing is filtered at all	No active mapping exists for that data source. If the data source carries an organizational column, SLG1 says so on every read.
A user is refused with a message that the filter is too long to apply	The granted hierarchy expands to more intervals than can be expressed in one selection. Grant lower nodes, or contact support.

When reporting an issue to support, include the SLG1 entry. It records which dimensions were applied, which sources answered, 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.

Organizational Authorization for Data Sources