CDS Access Controls and DCL Explained

DCL is the language behind CDS access controls: a separate repository object (a role, in the DCL sense) that defines a where-clause style filter applied automatically to a CDS entity's result set. The CDS entity itself only carries an annotation, typically something like authorizationCheck set to CHECK, NOT_REQUIRED or PRIVILEGED, pointing at the DCL source by name. The single structural fact that explains most confusion: the annotation and the DCL source are two separate objects joined only by a name reference, activated independently. If the DCL source is missing, inactive, or the reference is misspelled, the framework does not throw an authorization error — it treats the entity as fully restricted and returns an empty result. This looks exactly like a broken join, a missing association, or bad test data, and gets debugged as such for hours before anyone checks whether the DCL source even exists or is active.

Use CDS access controls whenever the same business data must be filtered consistently across every consumption path: a Fiori app, a RAP business object, an ad hoc CDS-based query, and a custom report all reading the same view entity. This is the right tool when the restriction is a genuine authorization concern tied to an existing or new PFCG authorization object, such as restricting by sales organization, plant, or company code. It is the wrong tool for purely technical filtering that has nothing to do with user authorization, such as excluding test records or limiting a dataset for performance — use a normal selection parameter or filter for that. It is also the wrong tool for field-level masking or for write authorization; DCL restricts which rows come back on read, not which fields are visible or which operations a user may execute.

In the read path, the CDS view or view entity sits above the DCL source and carries the annotation that activates it. The DCL source itself sits above the classic PFCG authorization object and role infrastructure, since its where-clause typically resolves fields against an authorization object's activity and organizational fields rather than reinventing authorization logic. Above the CDS entity sit all its consumers: RAP business objects, OData services and their Fiori elements apps, analytical queries, and plain ABAP SELECT statements against the entity with authorization checks enabled. DCL supersedes the pattern of embedding authority-check statements inside every individual report or function module that touches the same table; instead the check is centralized once at the data-access layer and inherited by every consumer that reads through that entity.

A sales order header view entity is exposed through a RAP business object and consumed by a Fiori elements list report. The requirement is that users only see orders belonging to sales organizations they are authorized for, using an existing authorization object that already controls sales organization access elsewhere in the system. The view entity's authorizationCheck annotation is set to CHECK and pointed at a new DCL source. The DCL source's where-clause maps the entity's sales organization field against the authorization object's organizational field and activity, using the aspect pfcg_auth construct rather than hardcoding values. After activation, a user with only one sales organization in their role sees a correctly filtered list. A second issue then surfaces: the business partner data reachable through an association on the same entity was left with authorizationCheck set to NOT_REQUIRED on its own view entity, so partner details for orders the user should not see are still visible through drilldown. The fix is aligning the check level on every entity reachable through the composition, not just the top-level one.

On S/4HANA, CDS access controls are the standard mechanism for read authorization on custom CDS entities and RAP business objects, and they fit cleanly within clean core principles because both the DCL source and the authorization object it maps to live in customer namespace using released interfaces. Embedding ad hoc authority-check logic inside custom reports is discouraged wherever a released CDS entity with a proper access control already exists for the same data; extensions built for longevity should expose data only through entities that carry an explicit authorization check rather than leaving NOT_REQUIRED as a default. No specific release dependency is assumed here beyond this general direction.

The developer writes the DCL source and sets the annotation on the CDS entity. The architect decides the overall strategy: shared versus dedicated roles, and consistent check levels across composed and associated entities. The functional or security team owns the underlying authorization object and its field values in PFCG. Handover should include the DCL source, the mapped authorization object, and a test matrix of role versus expected visible rows.

Read the page on CDS view entities versus classic DDIC views to see exactly where the authorization annotation is placed and why it does not exist on the older view type. Read the RAP behaviour definition and implementation page to see how write-side authorization is handled separately from DCL. Read the CDS annotations page for where the authorization annotation sits relative to other annotation categories, and the composition and association page since check-level gaps most often surface at association boundaries between entities.