SAP CDS View Validation: Common Activation Errors and How to Fix Them

A CDS view fails activation in ADT for a small, repeatable set of reasons. Once you recognize the pattern, most of these take seconds to fix instead of minutes of guessing.

"Element ... Is Unknown"

Element "MATNR" is unknown. Check for spelling errors and inconsistent aliasing.

This almost always means one of two things: a typo in the field name, or the field belongs to a JOIN partner or association target, not the base table, and you forgot to qualify it.

" Wrong — MATNR belongs to _Mara, not the base MARC alias
select from marc as marc
  association [1..1] to mara as _Mara on $projection.MaterialNumber = _Mara.Matnr
{
  key marc.matnr as MaterialNumber,
  MATNR " <- unqualified, ambiguous/wrong
}

" Right — go through the association
{
  key marc.matnr as MaterialNumber,
  _Mara.Matnr as MaterialNumberCheck
}

Association / Composition Cardinality Errors

The cardinality of association "_Items" does not match the cardinality used in ON condition

Cardinality ([0..1], [1..1], [0..*], [1..*]) is a declared contract, not something the compiler infers from your ON condition — if you declare [0..1] but the ON condition could actually match multiple rows on the target side (e.g. joining on a non-unique field), activation fails.

" Wrong — VBAP is not unique per VBELN alone (multiple items per order)
association [0..1] to vbap as _Item on $projection.SalesOrder = _Item.Vbeln

" Right — cardinality reflects reality
association [0..*] to vbap as _Items on $projection.SalesOrder = _Items.Vbeln

If you genuinely need a single related row, add the full key to the ON condition (e.g. also match Posnr) rather than lying about the cardinality.

Missing or Ambiguous Key Fields

A CDS view (root) requires at least one key element

Root views (define root view entity) — the kind you'd expose via RAP — must declare at least one key field explicitly. This is easy to miss when converting a plain define view into a root entity for RAP without revisiting the key declarations.

" Wrong — no key declared on a root entity
define root view entity ZI_Travel as select from ztravel
{
  travel_id as TravelId,
  description as Description
}

" Right
define root view entity ZI_Travel as select from ztravel
{
  key travel_id as TravelId,
  description as Description
}

Annotation Warnings That Silently Break the UI

Not every activation problem is a hard error — some are warnings that still break the Fiori Elements preview:

• @UI.lineItem on a field with no position when other fields do have one — mixing positioned and unpositioned annotations produces an unpredictable column order, not an error.
• @UI.selectionField on a field that isn't also exposed via @UI.lineItem or @UI.identification — it compiles, but the filter appears with no way to see the value in the results.
• Duplicate position values across two @UI.lineItem annotations — no error, but one column silently wins and the ordering looks wrong until you check the raw annotations.

Where to Actually Look

The ADT Problems view (Window → Show View → Problems) lists every activation error and warning with a line number — check it before re-reading the whole view top to bottom. For CDS views already active but behaving oddly in Fiori Elements, the annotation warnings above won't show as "errors," so check the Problems view's warning severity too, not just errors.

Use the CDS View Generator to scaffold syntactically valid joins, associations, and key declarations from the start, and the CDS Annotation Reference to check the exact syntax expected for @UI annotations before they turn into one of the silent warnings above.