**TITLE**: Configuring External Navigation (Fiori Elements)

**INTRODUCTION**: Short guide to configure outbound (navigation from this app) and inbound (navigation to this app) external navigation for Fiori Elements apps. Includes manifest.json fragments and runtime call examples used by code generators and automation to produce correct navigation configuration.

**TAGS**: fiori-elements-framework, navigation, cross-application-navigation, manifest.json, sap.app, outbound, inbound, sap.ushell

**STEP**: 1 — Outbound Navigation (define targets this app will call)

**DESCRIPTION**: Add outbound intents (targets) to your app manifest under sap.app -> crossNavigation -> outbounds. Each outbound defines the semanticObject/action, optional parameters (signature), a user-facing title, and a resolutionResult describing how the target should be launched (URL or SAPUI5 component). Use these entries so runtime navigation APIs (CrossApplicationNavigation) can resolve and call other apps.

File reference: navigation-from-an-app-outbound-navigation-d782acf.md

- Where to edit: manifest.json (project root)
- Key location: sap.app.crossNavigation.outbounds
- Typical use: programmatic navigation with CrossApplicationNavigation service (see next step for usage snippet)

**LANGUAGE**: JSON

**CODE**:
```json
{
  "sap.app": {
    "crossNavigation": {
      "outbounds": {
        "toOrderDisplay": {
          "semanticObject": "Order",
          "action": "display",
          "title": "Display Order",
          "signature": {
            "parameters": {
              "orderId": {}
            }
          },
          "resolutionResult": {
            "applicationType": "URL",
            "url": "#/Orders/{orderId}"
          }
        },
        "toExternalApp": {
          "semanticObject": "Invoice",
          "action": "manage",
          "title": "Manage Invoice",
          "signature": {
            "parameters": {
              "invoiceId": {}
            }
          },
          "resolutionResult": {
            "applicationType": "SAPUI5",
            "additionalInformation": "SAPUI5.Component=com.company.external.invoice",
            "url": "/resources/com/company/external/invoice"
          }
        }
      }
    }
  }
}
```

**STEP**: 2 — Call an Outbound Target at Runtime

**DESCRIPTION**: Use the CrossApplicationNavigation service to navigate to an outbound target. Provide target semanticObject/action and params. This snippet demonstrates how to call an outbound defined in manifest.json.

**LANGUAGE**: JavaScript

**CODE**:
```javascript
// Example: Navigate to the outbound "toOrderDisplay" defined in manifest
const navService = sap.ushell.Container.getService("CrossApplicationNavigation");

// target as semantic object + action, params values must be arrays
navService.toExternal({
  target: {
    semanticObject: "Order",
    action: "display"
  },
  params: {
    orderId: ["12345"]
  }
});
```

**STEP**: 3 — Inbound Navigation (declare intents this app accepts)

**DESCRIPTION**: Declare inbound intents in your manifest so other apps (or the FLP) can navigate into this app. Inbounds define the semanticObject/action this app implements, required or optional parameters, title, and resolutionResult describing this app's component (applicationType SAPUI5 with additionalInformation specifying the SAPUI5 component). This is required for intent-based navigation and for the FLP to resolve the app.

File reference: navigation-to-an-app-inbound-navigation-c337d8b.md

- Where to edit: manifest.json (project root)
- Key location: sap.app.crossNavigation.inbounds
- Typical use: ensure semanticObject/action names and required parameters match what calling apps expect

**LANGUAGE**: JSON

**CODE**:
```json
{
  "sap.app": {
    "crossNavigation": {
      "inbounds": {
        "Order-display": {
          "semanticObject": "Order",
          "action": "display",
          "title": "Order Display",
          "signature": {
            "parameters": {
              "orderId": {
                "required": true
              },
              "showEdit": {}
            }
          },
          "resolutionResult": {
            "applicationType": "SAPUI5",
            "additionalInformation": "SAPUI5.Component=com.company.app.order",
            "url": ""
          }
        },
        "Invoice-manage": {
          "semanticObject": "Invoice",
          "action": "manage",
          "title": "Manage Invoice",
          "signature": {
            "parameters": {
              "invoiceId": {
                "required": true
              }
            }
          },
          "resolutionResult": {
            "applicationType": "SAPUI5",
            "additionalInformation": "SAPUI5.Component=com.company.app.invoice",
            "url": ""
          }
        }
      }
    }
  }
}
```

**STEP**: 4 — Handle Inbound Parameters in the App

**DESCRIPTION**: Map inbound parameters (semanticObject/action parameters) to your component/app routing or startup logic. In UI5 apps you typically read the URL parameters or the startup parameters provided by the ComponentData. Use these to route to appropriate pages or to execute initialization logic.

**LANGUAGE**: JavaScript

**CODE**:
```javascript
// Example in Component.js or a controller: read startup parameters from ComponentData
sap.ui.define(["sap/ui/core/UIComponent"], function(UIComponent) {
  return UIComponent.extend("com.company.app.order.Component", {
    init: function() {
      UIComponent.prototype.init.apply(this, arguments);

      const startupParameters = this.getComponentData() && this.getComponentData().startupParameters;
      if (startupParameters && startupParameters.orderId) {
        const orderId = startupParameters.orderId[0]; // values are arrays
        // route or initialize view based on orderId
        this.getRouter().navTo("orderDetail", { orderId: orderId }, false);
      }
    }
  });
});
```

**STEP**: 5 — Validation and Best Practices

**DESCRIPTION**: Ensure:
- manifest.json entries are under sap.app.crossNavigation.inbounds and .outbounds
- semanticObject/action names are consistent across calling and called apps
- parameters defined in signatures match required usage and are typed if needed
- resolutionResult for SAPUI5 apps includes additionalInformation with SAPUI5.Component
- Use CrossApplicationNavigation.toExternal with params as arrays
- Test navigation in FLP or local sandbox to verify resolution and parameter passing

**LANGUAGE**: N/A

**CODE**:
```text
See detailed guides:
- Navigation from an App (Outbound): navigation-from-an-app-outbound-navigation-d782acf.md
- Navigation to an App (Inbound): navigation-to-an-app-inbound-navigation-c337d8b.md
```


**TITLE**: Configuring Fields in SAP Fiori elements (OData V4)

**INTRODUCTION**: Practical, code-focused guidance for configuring field behavior and presentation in SAP Fiori elements (OData V4). Covers: placeholders for input fields, date/time formatting, currency and unit-of-measure validation, and Edm.Guid validation. Use these annotations and examples directly in XML annotations, ABAP CDS, or CAP CDS where shown.

**TAGS**: fiori-elements-framework, OData V4, annotations, UI.Placeholder, DateTimeStyle, isCurrency, isUnit, Edm.Guid, XML, ABAP CDS, CAP CDS

STEP: 1 — Applicability note

DESCRIPTION: This topic applies only to SAP Fiori elements for OData V4. Use the annotations and examples below when implementing fields in OData V4-based Fiori elements apps.

LANGUAGE: Text

CODE:
```text
Note: Applicable only to SAP Fiori elements for OData V4.
```

STEP: 2 — Set placeholder text for input fields

DESCRIPTION: Use the UI.Placeholder annotation to define text shown in input fields (sap.m.Input, sap.m.ComboBox) before user entry. Add the annotation to the property target in the annotation XML file.

LANGUAGE: XML

CODE:
```xml
<Annotations Target="sap.fe.manageitems.TechnicalTestingService.LineItems/multiLineTextField">
    <Annotation Term="Common.Label" String="Test Multi Line Text Field"/>
    <Annotation Term="UI.MultiLineText" Bool="true"/>
    <Annotation Term="UI.Placeholder" String="Enter a multi line text"/>
</Annotations>
```

STEP: 3 — Format Date, Time, and DateTime fields using DateTimeStyle

DESCRIPTION: Use the UI.DateTimeStyle annotation to control display format in input and display modes. Values: short, medium, long, full (examples shown). If you need a custom format, supply an LDML pattern (e.g., "yyyy-MM-dd") via the manifest.json pattern property (follow LDML guidelines).

- short: concise date/time (e.g., 7/25/24, 1:11 PM)
- medium: more readable, includes seconds (e.g., Jul 25, 2024, 1:11:51 PM)
- long: includes time zone details (e.g., July 25, 2024 at 1:11:51 PM GMT+2)
- full: full day and time zone name (e.g., Thursday, July 25, 2024 at 1:11:51 PM Central European Summer Time)

LANGUAGE: XML

CODE:
```xml
<edmx:Reference Uri="https://sap.github.io/odata-vocabularies/vocabularies/UI.xml">
        <edmx:Include Namespace="com.sap.vocabularies.UI.v1" Alias="UI"/>
</edmx:Reference>

<Annotations Target="SAP__self.TravelType/CreatedAt">
        <Annotation Term="UI.DateTimeStyle" String="short"/>
</Annotations>
```

STEP: 4 — DateTimeStyle samples for CDS / CAP

DESCRIPTION: Use the DateTimeStyle annotation in CDS (CAP / ABAP where available). ABAP CDS: no sample provided in the source; use XML annotation instead. CAP CDS example shows DateTimeStyle set to 'short' for Date, Time, and DateTime properties.

LANGUAGE: CAP CDS

CODE:
```
DatePropertyWithStyle          : Date          @UI: {DateTimeStyle: 'short'};
TimePropertyWithStyle          : Time          @UI: {DateTimeStyle: 'short'};
DateTimePropertyWithStyle.     : DateTime      @UI: {DateTimeStyle: 'short'};
```

STEP: 5 — Use LDML patterns for custom date/time formats

DESCRIPTION: When DateTimeStyle is insufficient, define an LDML pattern to control display format for input and display text. Patterns follow Unicode LDML (e.g., "yyyy-MM-dd" produces 2023-09-24). Provide the pattern in your app's manifest.json where the framework expects field formatting settings.

LANGUAGE: Text

CODE:
```text
Example LDML pattern: "yyyy-MM-dd"  (follow LDML pattern letters per Unicode/SDk documentation)
```

STEP: 6 — Validate currency fields without a related value field (isCurrency)

DESCRIPTION: For currency properties that do not have a linked "value" property, mark them as currency with Common.isCurrency = true in annotations. Examples shown for XML, ABAP CDS, and CAP CDS.

LANGUAGE: XML

CODE:
```xml
<Annotations Target="com.c_salesordermanage_sd.SalesOrderManage/TransactionCurrency">
    <Annotation Term="Common.isCurrency" Bool="true"/>
    ...some more definition of property and/or value help...
</Annotations>
```

LANGUAGE: ABAP CDS

CODE:
```
@Semantics.currencyCode: true
TransactionCurrency
```

LANGUAGE: CAP CDS

CODE:
```
TransactionCurrency @(
        Common         : {
               IsCurrency : true
        }
  );
```

STEP: 7 — Validate unit-of-measure fields without a related value field (isUnit)

DESCRIPTION: For unit-of-measure (UoM) properties that do not have a linked "value" property, mark them as unit with Common.isUnit = true. Examples shown for XML, ABAP CDS, and CAP CDS.

LANGUAGE: XML

CODE:
```xml
<Annotations Target="com.c_salesordermanage_sd.SalesOrderManage/DocumentUnit">
    <Annotation Term="Common.isUnit" Bool="true"/>
    ...some more definition of property and/or value help...
</Annotations>
```

LANGUAGE: ABAP CDS

CODE:
```
@Semantics.unitOfMeasure: true
DocumentUnit
```

LANGUAGE: CAP CDS

CODE:
```
DocumentUnit @(
        Common         : {
               IsUnit : true
        }
);
```

STEP: 8 — Edm.Guid properties validation

DESCRIPTION: Validation for Edm.Guid properties is automatically enabled when the property has a value help. Ensure a value help (value list / value help annotation) exists for the Edm.Guid property to enable validation.

LANGUAGE: XML

CODE:
```xml
<!-- Validation is automatically enabled for Edm.Guid properties that have a value help. -->
```

fiori-elements-framework
OData V4
annotations
UI.Placeholder
DateTimeStyle
isCurrency
isUnit
Edm.Guid
XML
ABAP CDS
CAP CDS


**TITLE**: Configuring Filter Bars (Fiori elements — List Report & Analytical List Page)

**INTRODUCTION**: Practical, code-focused reference for configuring filter bars in SAP Fiori elements list reports and analytical list pages. Includes required annotations, manifest.json settings, parameterized entity handling, filter restrictions, mandatory/non-filterable fields, tooltips, hiding the filter bar, enabling live mode, and examples for XML, ABAP CDS and CAP CDS.

**TAGS**: filter-bar, ui.selectionfields, manifest.json, liveMode, filter-restrictions, parameterized-entities, sap-fe, odata, annotations, CAP, ABAP, XML, JSON

STEP: 1 — Ensure Service Supports Filtering

DESCRIPTION: Confirm the OData service supports filtering. For V2 set sap-filterable=true; for V4 set Capabilities.Filterable=true. The filter bar is available only if the service advertises filtering capability.

LANGUAGE: Text

CODE:
```text
SAP Fiori elements for OData V2: sap-filterable=true

SAP Fiori elements for OData V4: Capabilities.Filterable=true
```

STEP: 2 — Configure UI.SelectionFields (controls fields shown in filter bar)

DESCRIPTION: Define which properties appear in the filter bar (plus mandatory fields and draft Editing Status). Use one of the annotation formats below depending on your stack.

LANGUAGE: XML

CODE:
```xml

<Annotation Term="UI.SelectionFields">
   <Collection>
     <PropertyPath>SalesOrder</PropertyPath>
     <PropertyPath>SoldToParty</PropertyPath>
     <PropertyPath>OverallSDProcessStatus</PropertyPath>
     <PropertyPath>SalesOrderDate</PropertyPath>
     <PropertyPath>_Item/Material</PropertyPath>
   </Collection>
</Annotation>
```

LANGUAGE: ABAP CDS

CODE:
```
@UI.SelectionField: [{ position: 10 }]
SALESORDER;

@UI.SelectionField: [{ position: 20 }]
SOLDTOPARTY;

@UI.SelectionField: [{ position: 30 }]
OVERALLSDPROCESSSTATUS;

@UI.SelectionField: [{ position: 40 }]
SALESORDERDATE;

@UI.SelectionField: [{ position: 50, element: '_Item.Material' }]
_Item;
```

LANGUAGE: CAP CDS

CODE:
```

annotate service.SalesOrderManage with @(
  UI.SelectionFields  : [
     SalesOrder,
     SoldToParty,
     OverallSDProcessStatus,
     SalesOrderDate,
     Item.Material
]
);
```

STEP: 3 — Configure Search Behavior: Go Button Mode vs Live Mode

DESCRIPTION: Choose whether searches run only on explicit Go click (Go button mode, default) or automatically on field change (live mode). Live mode can be enabled via manifest.json (or UI adaptation in V2) — see code examples below. CAUTION: live mode triggers automatic refreshes during initial load and on every field change; test performance for large or complex datasets.

LANGUAGE: JSON

CODE:
```text
# Example: enable live mode (V4) in manifest.json — see Step 7 for full routing context
"liveMode": true
```

STEP: 4 — V2: EntitySet with Input Parameters (displayed automatically)

DESCRIPTION: If an entity set exposes input parameters (sap:semantics="parameters"), its parameters are shown on the filter bar automatically. Mandatory parameters must be filled to trigger queries. Optional parameters (currently only Edm.String supported) default to empty string if not provided.

LANGUAGE: XML

CODE:
```

<EntityType Name="SalesShareParametersType" sap:semantics="parameters">
    <Key>
        <PropertyRef Name="P_Currency"/>
        <PropertyRef Name="P_Country"/>
        <PropertyRef Name="P_Optional"/>
    </Key>
    <Property Name="P_Currency" Type="Edm.String" Nullable="false" MaxLength="5" sap:label="Currency" sap:parameter="mandatory"/>
    <Property Name="P_Country" Type="Edm.String" Nullable="false" DefaultValue="3" MaxLength="20" sap:label="CountryCode" sap:parameter="mandatory"/>
    <Property Name="P_Optional" Type="Edm.String" Nullable="false" MaxLength="5" sap:label="Optional" sap:parameter="optional"/>
    <NavigationProperty Name="Results" Relationship="sap.smartbusinessdemo.services.SalesShareParameters_SalesShareType" FromRole="SalesShareParametersPrincipal" ToRole="SalesShareDependent"/>
</EntityType>

```

STEP: 5 — V4: Add Filter Fields Using SAP Fiori Tools (UI path)

DESCRIPTION: Use SAP Fiori Tools Page Map and Page Editor to add filter fields without editing annotations manually. Steps:
- Open Page Map (e.g., right-click project > Show Page Map).
- Open Page Editor for List Report (click pencil icon).
- Expand Filter Fields node, click Arrow icon.
- Click Add (+) next to Filter Fields > Add Filter Fields.
- Select fields from dropdown > Click Add.
- Preview using Fiori Tools preview.

LANGUAGE: Text

CODE:
```text
Reference docs:
- Define Application Structure: https://help.sap.com/docs/SAP_FIORI_tools/17d50220bcd848aa854c9c182d65b699/bae38e6216754a76896b926a3d6ac3a9.html
- Filter Fields: https://help.sap.com/docs/SAP_FIORI_tools/17d50220bcd848aa854c9c182d65b699/0b8428645243486680ffa22c0b541039.html
- Previewing an Application: https://help.sap.com/docs/SAP_FIORI_tools/17d50220bcd848aa854c9c182d65b699/b962685bdf9246f6bced1d1cc1d9ba1c.html
```

STEP: 6 — Hide the Filter Bar via manifest.json

DESCRIPTION: Force the filter bar to be hidden at app startup (content area loads regardless of initialLoad). Note: ignored if mandatory filter fields or parameter fields without defaults exist.

LANGUAGE: JSON

CODE:
```json

{
     "sap.ui5": {
          "routing": {
               "targets": {
                    "SalesOrderManageList": {
                         "options": {
                              "settings": {
                                   "hideFilterBar": true
                              }
                         }
                    }
               }
          }
     }
}
```

STEP: 7 — Enable Live Mode via manifest.json (V4 example)

DESCRIPTION: Set liveMode true for the ListReport target in manifest.json to enable automatic searches on filter changes. Evaluate performance impact before enabling.

LANGUAGE: JSON

CODE:
```

"routing": {
	"targets": {
	    "MyEntitiesList": {
            "type": "Component",
            "name": "sap.fe.templates.ListReport",
            "id": "MyEntitiesList",
            "options": {
                "settings": {
                "liveMode": true,
                ...
                }
            }
        }
    }
}
```

STEP: 8 — Configure Mandatory Filter Fields (Capabilities.RequiredProperties)

DESCRIPTION: Mark filter properties as mandatory so a value is required before a search can be executed. Use FilterRestrictions.RequiredProperties.

LANGUAGE: XML

CODE:
```
<Annotations Target="SAP__self.Container/SalesOrder">
   <Annotation Term="SAP__capabilities.FilterRestrictions">
      <Record>
         <PropertyValue Property="RequiredProperties">
            <Collection>
               <PropertyPath>OrderType</PropertyPath>
            </Collection>
         </PropertyValue>
      </Record>
   </Annotation>
</Annotations>
```

LANGUAGE: ABAP CDS

CODE:
```
@Consumption.filter.mandatory: true
OrderType;
```

LANGUAGE: CAP CDS

CODE:
```
annotate service.SalesOrder with @Capabilities : {
    FilterRestrictions : {
        $Type : 'Capabilities.FilterRestrictionsType',
        RequiredProperties : [
            OrderType
        ],
    },
};
```

STEP: 9 — Add Tooltips to Filter Fields (@Common.QuickInfo)

DESCRIPTION: Provide user-facing quick info tooltip for a filter field using Common.QuickInfo annotation.

LANGUAGE: XML

CODE:
```
<Annotations Target="SAP__self.Container/SalesOrder/OrderNumber>
   <Annotation Term="Common.QuickInfo" String="Unique identifier for the sales order"/>
</Annotations>
```

LANGUAGE: ABAP CDS

CODE:
```
@Common.QuickInfo: 'Unique identifier for the sales order'
OrderNumber;
```

LANGUAGE: CAP CDS

CODE:
```
entity SalesOrder {
   key ID : UUID;
   OrderNumber : String(20) @Common.QuickInfo: 'Unique identifier for the sales order';
   ...
}
```

STEP: 10 — Keep Fields Hidden in Filter Bar and Adapt Filters (NonFilterableProperties)

DESCRIPTION: Use Capabilities.NonFilterableProperties to prevent a property from appearing in the filter bar and the Adapt Filters dialog. Note: UI.Hidden and UI.HiddenFilter also hide properties.

LANGUAGE: XML

CODE:
```

<Annotations Target="SAP__self.Container/SalesOrder">
   <Annotation Term="SAP__capabilities.FilterRestrictions">
      <Record>
         <PropertyValue Property="NonFilterableProperties">
            <Collection>
               <PropertyPath>DeliveryChannel</PropertyPath>
            </Collection>
         </PropertyValue>
      </Record>
   </Annotation>
</Annotations>
```

LANGUAGE: ABAP CDS

CODE:
```
@ObjectModel.filter.enabled: false
DeliveryChannel;
```

LANGUAGE: CAP CDS

CODE:
```

annotate service.SalesOrder with @Capabilities : {
    FilterRestrictions : {
        $Type : 'Capabilities.FilterRestrictionsType',
        NonFilterableProperties : [
            DeliveryChannel
        ],
    },
};
```

STEP: 11 — Parameterized Entities: setup and manifest contextPath

DESCRIPTION: For parameterized main entities, the filter bar includes required parameter fields. Ensure manifest contextPath targets the parameter entity set with the "/Set" suffix. Call main entity results by passing parameters through the parameter entity set and then calling the containment navigation (e.g., /Customer(P_DisplayCurrency='JPY')/Set?$count=true).

LANGUAGE: XML

CODE:
```

<EntityType Name="CustomerType">
    <Key>
        <PropertyRef Name="Customer"/>
        <PropertyRef Name="CompanyCode"/>
        ...
    </Key>
    <Property Name="Customer" Type="Edm.String" Nullable="false" MaxLength="10"/>
    <Property Name="CompanyCode" Type="Edm.String" Nullable="false" MaxLength="4"/>
    <Property Name="SalesOrganization" Type="Edm.String" Nullable="false" MaxLength="4"/>
    ...
    <NavigationProperty Name="Parameters" Type="com.sap.gateway.srvd.zrc_arcustomer_definition.v0001.CustomerParameters" Nullable="false"/>
    ...
</EntityType>
```

LANGUAGE: XML

CODE:
```
<Annotations Target="SAP__self.CustomerParameters">
    <Annotation Term="SAP__common.ResultContext"/>
    ...
</Annotations>
```

LANGUAGE: XML

CODE:
```
<EntityType Name="CustomerParameters">
    <Key>
        <PropertyRef Name="P_DisplayCurrency"/>
    </Key>
    <Property Name="P_DisplayCurrency" Type="Edm.String" Nullable="false" MaxLength="3"/>
    <NavigationProperty Name="Set" Type="Collection(com.sap.gateway.srvd.zrc_arcustomer_definition.v0001.CustomerType)" Partner="Parameters" ContainsTarget="true"/>
</EntityType>
```

LANGUAGE: JSON

CODE:
```

"targets": {
    "CustomerList": {
        "type": "Component",
        "id": "CustomerList",
        "name": "sap.fe.templates.ListReport",
        "options": {
            "settings": {
                "contextPath": "/Customer/Set",
            }
        }
    }
},
```

LANGUAGE: XML

CODE:
```

<EntityContainer Name="Container">
    <EntitySet Name="Customer" EntityType="com.sap.gateway.srvd.zrc_arcustomer_definition.v0001.CustomerParameters">
        <NavigationPropertyBinding Path="Set/Parameters" Target="Customer"/>
        ...
    </EntitySet>
    ...
</EntityContainer>
```

LANGUAGE: Text

CODE:
```
Example OData call to fetch main entity results through parameter entity set:
http://<path>/Customer(P_DisplayCurrency='JPY')/Set?$count=true
```

LANGUAGE: CAP CDS

CODE:
```

@Common.ResultContext #$parameters
  entity RootElement(P_CurrencyUnit : String not null @(---));
```

STEP: 12 — Filter Restrictions for Parameterized Entities (two approaches)

DESCRIPTION: Two supported approaches to specify filter restrictions when main entity set is parameterized:
- Define FilterExpressionRestrictions at the main entity using PropertyPath that points through containment (Set/Property).
- Define NavigationRestrictions at the parameter entity (navigation property path pointing to containment) and add FilterRestrictions there. NavigationRestrictions take priority over direct restrictions on the main entity.

LANGUAGE: XML

CODE:
```

<Annotation Term="SAP__capabilities.FilterRestrictions">
    <Record>
        <PropertyValue Property="FilterExpressionRestrictions">
            <Collection>
                <Record>
                    <PropertyValue Property="Property" PropertyPath="Set/SalesOrganization" />
                    <PropertyValue Property="AllowedExpressions" String="MultiValue" />
                </Record>
            </Collection>
        </PropertyValue>
    </Record>
</Annotation>
```

LANGUAGE: CAP CDS

CODE:
```

entity Customer   @(
    Capabilities : {
        FilterRestrictions:{
            $Type: 'Capabilities.FilterRestrictionsType',
            FilterExpressionRestrictions: [{
                Property: 'Set/SalesOrganization',
                AllowedExpressions: 'MultiValue'
            }]
    }
}
```

LANGUAGE: XML

CODE:
```

<Annotations Target="SAP__self.Container/Customer">
   <Annotation Term="SAP__capabilities.NavigationRestrictions">
      <Record>
         <PropertyValue Property="RestrictedProperties">
            <Collection>
               <Record>
                  <PropertyValue Property="NavigationProperty" NavigationPropertyPath="Set" />
                     <PropertyValue Property="FilterRestrictions">
                        <Record>
                           ....
                           ....
                           <PropertyValue Property="FilterExpressionRestrictions">
                              <Collection>
                                 <Record>
                                    <PropertyValue Property="Property" PropertyPath="SalesOrganization" />
                                    <PropertyValue Property="AllowedExpressions" String="MultiValue" />
                                 </Record>
                              </Collection>
                           </PropertyValue>
                        </Record>
                     </PropertyValue>
                  </PropertyValue>
               </Record>
            </Collection>
         </PropertyValue>
      </Record>
   </Annotation>
</Annotations>
```

LANGUAGE: CAP CDS

CODE:
```

service MyService {
    @Capabilities.NavigationRestrictions.RestrictedProperties : [{
        $Type              : 'Capabilities.NavigationPropertyRestriction',
        NavigationProperty : 'Set',
        FilterRestrictions : {
            $Type                        : 'Capabilities.FilterRestrictionsType',
            FilterExpressionRestrictions : [{
                $Type              : 'Capabilities.FilterExpressionRestrictionType',
                Property           : 'Set.SalesOrganization',
                AllowedExpressions : 'MultiValue'
            }]
        }
    }]
}
```

STEP: 13 — Constraints, Notes and Restrictions

DESCRIPTION: Keep these constraints in mind when designing filter bars:
- Parameter support only for read-only services (editable services not supported).
- Parameters not supported with multiple view mode unless single-table mode is used.
- Navigation entity sets associated with the main entity cannot be parameterized.
- Sort restrictions not supported for first-level navigation entity sets in parameterized scenarios.
- Filtering on measure properties is not supported.
- NavigationRestriction-based filter restrictions override direct main-entity restrictions.

LANGUAGE: Text

CODE:
```text
Refer to "Live Mode" performance caution: live mode triggers initial load and refresh on every field change — test thoroughly for large or complex datasets.
```

STEP: 14 — References and Further Reading

DESCRIPTION: Links to related topics for adapting the filter bar, initial data loading behavior, and adding custom filter fields.

LANGUAGE: Text

CODE:
```text
- Adapting the Filter Bar: adapting-the-filter-bar-609c39a.md
- Loading Behavior of Data on Initial Launch of the Application: loading-behavior-of-data-on-initial-launch-of-the-application-9f4e119.md
- Adding Custom Fields to the Filter Bar (extension APIs): adding-custom-fields-to-the-filter-bar-5fb9f57.md
```

filter-bar ui.selectionfields manifest.json liveMode filter-restrictions parameterized-entities sap-fe odata annotations CAP ABAP XML JSON


**TITLE**: Configuring Filter Fields (SAP Fiori Elements — FilterRestrictions)

**INTRODUCTION**: This guide shows how to configure filter fields in SAP Fiori Elements so they accept single values, multiple values, or ranges. It covers OData V2 and V4 annotations (XML, ABAP CDS, CAP CDS), navigation/entity scenarios (association, parent, child), prioritization rules, strict Unit-of-Measure (UoM) filtering, and copy/paste behavior. Use these examples directly in your annotation files (EDMX XML, CDS, manifest.json) to control filter entry behavior in filter bars and value helps.

**TAGS**: fiori-elements-framework, filter-restrictions, ODataV2, ODataV4, CDS, CAP, ABAP, manifest, UoM, visual-filters

STEP: 1 — Copying and Pasting Multiple Values in the Filter Bar

DESCRIPTION: End users can copy/paste multiple values into filter fields if the source and target fields share the same data type. This works across filter fields, value help dialogs (paste into equal-to field), and spreadsheets. Note performance considerations and the need for custom event handlers for custom filters.

LANGUAGE: Plain text

CODE:
```text
Use cases:
- From one filter field to another filter field of the same data type.
- From one filter field to the value help dialog of another field of the same data type.
- From a spreadsheet to a filter field of the same data type.

Example: Copy values from "Sales Order No." filter and paste into another filter or into the value help dialog's "equal to" field.

Restriction:
- Copying/pasting a large number of values can cause performance issues.
- For apps with custom filters, developers must define copy and paste events for the custom filters.
Image reference: images/copy-paste-filter-bar_e343435.png
```

STEP: 2 — OData V2: sap:filter-restriction (control single vs multi value)

DESCRIPTION: Use the sap:filter-restriction attribute on property definitions in the EDMX to force single-value filtering. If no filter-restriction is provided, fields default to multi-valued.

LANGUAGE: XML

CODE:
```xml
<Property Name="StartDate" Type="Edm.DateTime" sap:display-format="Date"
sap:aggregation-role="dimension" sap:label="Date" sap:filter-restriction="single-value"/>

<Property Name="StartDate" Type="Edm.String" sap:semantics="yearmonthday"
sap:aggregation-role="dimension" sap:label="Date" sap:filter-restriction="single-value"/>
```

STEP: 3 — OData V4: XML FilterRestrictions (FilterExpressionRestrictions example)

DESCRIPTION: Use Capabilities.FilterRestrictions in service annotations to set AllowedExpressions per property (SingleValue, MultiValue, SingleRange, MultiRange). If not provided, fields are multi-valued by default.

LANGUAGE: XML

CODE:
```xml
<AnnotationsTarget="com.c_salesordermanage_sd.EntityContainer/SalesOrderManage">
    <AnnotationTerm="Capabilities.FilterRestrictions">
        <RecordType="Capabilities.FilterRestrictionsType">
            <PropertyValueProperty="FilterExpressionRestrictions">
                <Collection>
                    <RecordType="Capabilities.FilterExpressionRestrictionType">
                        <PropertyValueProperty="Property" PropertyPath="SoldToParty"/>
                        <PropertyValueProperty="AllowedExpressions" String="SingleValue"/>
                    </Record>
                    <RecordType="Capabilities.FilterExpressionRestrictionType">
                        <PropertyValueProperty="Property" PropertyPath="SalesOrderDate"/>
                        <PropertyValueProperty="AllowedExpressions" String="SingleRange"/>
                    </Record>
                </Collection>
            </PropertyValue>
        </Record>
    </Annotation>
    ….
    ….
</Annotations>
```

STEP: 4 — Equivalent ABAP CDS: AllowedExpressions mapping to @Consumption annotations

DESCRIPTION: Use these ABAP CDS annotation mappings to produce equivalent AllowedExpressions behavior in OData V4. Map AllowedExpressions to @Consumption.filter.multipleSelections and @Consumption.filter.selectionType.

LANGUAGE: ABAP CDS

CODE:
```
FilterExpressionRestriction.AllowedExpressions = "SingleValue"
       @Consumption.filter.multipleSelections: false
       @Consumption.filter.selectionType: #SINGLE

FilterExpressionRestriction.AllowedExpressions = "MultiValue"
       @Consumption.filter.multipleSelections: true
       @Consumption.filter.selectionType: #SINGLE

FilterExpressionRestriction.AllowedExpressions = "SingleRange"
       @Consumption.filter.multipleSelections: false
       @Consumption.filter.selectionType: #INTERVAL

FilterExpressionRestriction.AllowedExpressions = "MultiRange"
       @Consumption.filter.multipleSelections: true
       @Consumption.filter.selectionType: #INTERVAL
```

STEP: 5 — CAP CDS: Define FilterRestrictions on entity

DESCRIPTION: Add Capabilities.FilterRestrictions to your CAP CDS entity definition to restrict properties. Example shows single-value and single-range restrictions for properties.

LANGUAGE: CAP CDS

CODE:
```cds
entity SalesOrderManage @(
    title        : 'Manage Sales Order',
    Capabilities : {
        FilterRestrictions     : {FilterExpressionRestrictions : [
        {
            Property           : 'SoldToParty',
            AllowedExpressions : 'SingleValue'
        },
        {
            Property           : 'SalesOrderDate',
            AllowedExpressions : 'SingleRange'
        }
        ]}
    },
```

STEP: 6 — Make a filter field required (CAP CDS)

DESCRIPTION: Use Capabilities.FilterRestrictions.RequiredProperties to mark filter fields as required in CAP CDS (manifest or service annotations will reflect this).

LANGUAGE: CAP CDS

CODE:
```cds
entity SalesOrderManage @(
    title        : 'Manage Sales Order',
    Capabilities : {
      FilterRestrictions         : {
              $Type              : 'Capabilities.FilterRestrictionsType',
              RequiredProperties : [
                  SalesOrderDate,
              ],
      }
    },
```

STEP: 7 — Navigation Entity: FilterRestrictions at Association Entity (non-containment)

DESCRIPTION: Annotate the association (navigation property) target to set filter restrictions for the navigation property. This approach has highest priority and wins over lower-priority approaches.

LANGUAGE: XML

CODE:
```xml
<Annotations Target="com.c_salesordermanage_sd.SalesOrderManage/_Material">
    <Annotation Term="Capabilities.FilterRestrictions">
        <Record Type="Capabilities.FilterRestrictionsType">
            <PropertyValue Property="FilterExpressionRestrictions">
                <Collection>
                    <Record Type="Capabilities.FilterExpressionRestrictionType">
                        <PropertyValue Property="Property" PropertyPath="Material"/>
                        <PropertyValue Property="AllowedExpressions" String="SingleValue"/>
                    </Record>
                </Collection>
            </PropertyValue>
        </Record>
    </Annotation>
```

STEP: 8 — Navigation Entity: CAP CDS association-level FilterRestrictions (non-containment)

DESCRIPTION: Add FilterRestrictions to the navigation property definition in CAP CDS to annotate the association entity directly (non-containment).

LANGUAGE: CAP CDS

CODE:
```cds
entity SalesOrderManage    @( // add annotations
    ...
    SemanticKey : [ID],
    ...
) {
    SalesOrder :      SalesOrderId not null; // Add properties
    ...
    // Add restrictions where navigation property is defined
    _Material  :      Association to Material on _Material.Material = Material;
                      @(Capabilities: {
                          FilterRestrictions: {
                              FilterExpressionRestrictions: [
                                  {
                                      Property   : 'Material',
                                      AllowedExpressions: 'SingleRange'
                                  }
                              ]
                          }
                      });
}
```

STEP: 9 — Navigation Entity: XML containment example for FilterRestrictions

DESCRIPTION: For containment scenarios, annotate the containment navigation target in XML to set AllowedExpressions (MultiValue example).

LANGUAGE: XML

CODE:
```xml
<Annotations Target="sap.fe.test.MyService.MainEntityType/_ItemPartners">
   <Annotation Term="SAP__capabilities.FilterRestrictions">
      <Record>
         ....
         ....
         <PropertyValue Property="FilterExpressionRestrictions">
            <Collection>
               <Record>
                  <PropertyValue Property="Property" PropertyPath="CityName" />
                  <PropertyValue Property="AllowedExpressions" String="MultiValue" />
               </Record>
            </Collection>
         </PropertyValue>
      </Record>
   </Annotation>
</Annotations>
```

STEP: 10 — Navigation Entity: CAP CDS containment example

DESCRIPTION: Annotate composition/containment entities with FilterRestrictions directly at the child entity (example for CityName multi-value).

LANGUAGE: CAP CDS

CODE:
```cds
entity CustomerType {
    key ID            : UUID;
        @Capabilities.FilterRestrictions : {
          FilterExpressionRestrictions : [{
            $Type              : 'Capabilities.FilterExpressionRestrictionType',
            Property           : FullName,
            AllowedExpressions : 'MultiValue'
          }]
        }
        _PartnerItems : Composition of many PartnerType;
  };
```

STEP: 11 — Parent Entity: NavigationRestrictions with FilterRestrictions (parent-level)

DESCRIPTION: Annotate the parent entity's NavigationRestrictions.RestrictedProperties to set FilterRestrictions for navigation properties (non-containment example).

LANGUAGE: XML

CODE:
```xml
<Annotations Target="com.c_salesordermanage_sd.EntityContainer/SalesOrderManage">
  <Annotation Term="Capabilities.NavigationRestrictions">
    <Record>
        <PropertyValue Property="RestrictedProperties">
          <Collection>
            <Record>
               <PropertyValue Property="NavigationProperty" NavigationPropertyPath="_Material"/>
               <PropertyValue Property="FilterRestrictions">
                  <Record>
                     .....
                     .....
                     <PropertyValue Property="FilterExpressionRestrictions">
                        <Collection>
                           <Record>
                              <PropertyValue Property="Property" PropertyPath="Material" />
                              <PropertyValue Property="AllowedExpressions" String="SingleValue" />
                           </Record>
                        </Collection>
                     </PropertyValue>
                  </Record>
               </PropertyValue>
           </Record>
          </Collection>
        </PropertyValue>
    </Record>
  </Annotation>
</Annotations>
```

STEP: 12 — Parent Entity: CAP CDS NavigationRestrictions (non-containment)

DESCRIPTION: Use Capabilities.NavigationRestrictions at parent entity level in CAP CDS to assign filter restrictions for a navigation property.

LANGUAGE: CAP CDS

CODE:
```cds
entity SalesOrderManage  @(
   title: 'Manage Sales Order',
   Capabilities: {
      NavigationRestrictions: {
         RestrictedProperties: [{
            NavigationProperty: _Material,
            FilterRestrictions: {
               FilterExpressionRestrictions: [{
                  Property: 'Material',
                  AllowedExpressions : 'SingleValue'
               }]
            }
         }]
      }
   }
)
```

STEP: 13 — Parent Entity: FilterRestrictions with PropertyPath pointing to child property

DESCRIPTION: Annotate FilterRestrictions at parent entity but use PropertyPath to point to child fields (non-containment). Not supported for containment scenarios.

LANGUAGE: XML

CODE:
```xml
<Annotations Target="com.c_salesordermanage_sd.EntityContainer/SalesOrderManage">
    <Annotation Term="Capabilities.FilterRestrictions">
        <Record Type="Capabilities.FilterRestrictionsType">
            <PropertyValue Property="FilterExpressionRestrictions">
                <Collection>
                    <Record Type="Capabilities.FilterExpressionRestrictionType">
                        <PropertyValue Property="Property" PropertyPath="_Material/Material"/>
                        <PropertyValue Property="AllowedExpressions" String="SingleValue"/>
                    </Record>
                </Collection>
            </PropertyValue>
        </Record>
    </Annotation>
```

STEP: 14 — Parent Entity: CAP CDS property-path pointing to child property

DESCRIPTION: Example CAP CDS showing FilterRestrictions with PropertyPath pointing to association child property.

LANGUAGE: CAP CDS

CODE:
```cds
entity SalesOrderManage   @(
    Capabilities: {
        FilterRestrictions    : {FilterExpressionRestrictions: [
        {
            Property           : _Material.Material,
            AllowedExpressions : 'SingleValue'
        }
        ]}
    }
)
```

STEP: 15 — Child Entity: FilterRestrictions directly on child entity

DESCRIPTION: Annotate the child entity directly to set AllowedExpressions for properties in the child entity. This is lower priority than association-level annotations.

LANGUAGE: XML

CODE:
```xml
<Annotations Target="com.c_salesordermanage_sd.SalesOrderManage/MaterialEntity">
    <Annotation Term="Capabilities.FilterRestrictions">
        <Record Type="Capabilities.FilterRestrictionsType">
            <PropertyValue Property="FilterExpressionRestrictions">
                <Collection>
                    <Record Type="Capabilities.FilterExpressionRestrictionType">
                        <PropertyValue Property="Property" PropertyPath="Material"/>
                        <PropertyValue Property="AllowedExpressions" String="SingleValue"/>
                    </Record>
                </Collection>
            </PropertyValue>
        </Record>
    </Annotation>
```

STEP: 16 — Child Entity: CAP CDS direct child example (non-containment)

DESCRIPTION: CAP CDS example to annotate child entity with FilterRestriction for Material property.

LANGUAGE: CAP CDS

CODE:
```cds
entity MaterialEntity @(
   title: 'Material',
   Capabilities: {
      FilterRestrictions: {
         FilterExpressionRestrictions: [{
            Property: 'Material',
            AllowedExpressions: 'SingleValue'
         }]
      }
  }
)
```

STEP: 17 — Child Entity: containment example XML and CAP CDS

DESCRIPTION: For containment scenarios, annotate child entities similarly. Example XML and CAP CDS show CityName MultiValue.

LANGUAGE: XML

CODE:
```xml
<Annotations Target="SAP__self.Container/ItemPartner">
   <Annotation Term="SAP__capabilities.FilterRestrictions">
      <Record>
         ....
         ....
         <PropertyValue Property="FilterExpressionRestrictions">
            <Collection>
               <Record>
                  <PropertyValue Property="Property" PropertyPath="CityName" />
                  <PropertyValue Property="AllowedExpressions" String="MultiValue" />
               </Record>
            </Collection>
         </PropertyValue>
      </Record>
   </Annotation>
</Annotations>
```

LANGUAGE: CAP CDS

CODE:
```cds
entity _ItemPartner  @(
    Capabilities: {
        FilterRestrictions: {
            FilterExpressionRestrictions: [{
                Property: 'CityName',
                AllowedExpressions: 'MultiValue'
            }]
    }
}
```

STEP: 18 — ABAP CDS equivalent mapping for AllowedExpressions (repeated reference)

DESCRIPTION: ABAP CDS mapping for AllowedExpressions (same as STEP 4). Use @Consumption.filter.* annotations in ABAP CDS to control multipleSelections and selectionType.

LANGUAGE: ABAP CDS

CODE:
```
FilterExpressionRestriction.AllowedExpressions = "SingleValue"
       @Consumption.filter.multipleSelections: false
       @Consumption.filter.selectionType: #SINGLE

FilterExpressionRestriction.AllowedExpressions = "MultiValue"
       @Consumption.filter.multipleSelections: true
       @Consumption.filter.selectionType: #SINGLE

FilterExpressionRestriction.AllowedExpressions = "SingleRange"
       @Consumption.filter.multipleSelections: false
       @Consumption.filter.selectionType: #INTERVAL

FilterExpressionRestriction.AllowedExpressions = "MultiRange"
       @Consumption.filter.multipleSelections: true
       @Consumption.filter.selectionType: #INTERVAL
```

STEP: 19 — Prioritization of FilterRestrictions (merge + override rules)

DESCRIPTION: When multiple annotations exist for the same field, they are merged and higher-priority annotations override lower-priority ones. Priority order (highest to lowest):
1. Filter Restrictions at Association Entity
2. Navigation Restrictions at Parent Entity
3. Filter Restrictions at Parent Entity with PropertyPath pointing to Child Entity (not supported for containment)
4. Filter Restrictions Directly at Child Entity

Example: If Child.CityName is SingleValue at child level but MultiValue at association level, final behavior = MultiValue (association-level overrides).

LANGUAGE: Plain text

CODE:
```text
Prioritization:
1. Filter Restrictions at Association Entity
2. Navigation Restrictions at Parent Entity
3. Filter Restrictions at Parent Entity with PropertyPath (not for containment)
4. Filter Restrictions Directly at Child Entity
```

STEP: 20 — Strict Filtering of Unit of Measure (UoM)

DESCRIPTION: Strict UoM filtering enforces single-value entry for unit fields when filtering measure fields (Amount, Quantity). It is enabled by default. Disable globally via sap.fe.disableStrictUomFiltering in manifest.json.

LANGUAGE: JSON

CODE:
```json
"sap.fe": {
    "app": {
        "disableStrictUomFiltering": true
    }
}
```

STEP: 21 — Visual Filters and Field Help references

DESCRIPTION: Use visual filter bar configuration to select values based on measure values. For field help configuration see Field Help documentation. Links kept from original docs for deeper integration.

LANGUAGE: Plain text

CODE:
```text
See also:
- Configuring the Visual Filter Bar: configuring-the-visual-filter-bar-33f3d80.md
- Field Help configuration: field-help-a5608ea.md
```

fiori-elements-framework filter-restrictions ODataV2 ODataV4 CDS CAP ABAP manifest UoM visual-filters


**TITLE**: Configuring Status Colors and Navigation via Annotations for List Report and Object Page

**INTRODUCTION**: This guide explains how to configure common features used by both the List Report and Object Page in Fiori elements — specifically: (1) semantic status colors (via DataPoint/Criticality) and (2) intent-based navigation. Add these annotations to your service annotation files so the framework renders colored status indicators and navigation actions automatically.

**TAGS**: fiori-elements-framework, annotations, status, criticality, navigation, data-point, intent-based-navigation, list-report, object-page

**STEP**: 1 — Add a DataPoint with Criticality and expose it in the LineItem to render semantic status colors

**DESCRIPTION**: Create or update your OData annotation file (XML) and:
- Define a DataPoint annotation that maps an entity property to Value and Criticality.
- Reference that DataPoint from the UI.LineItem (table/list) so the UI renders a status visualization (colored badge) based on Criticality.

File path (example): app/annotations/<YourService>.annotations.xml

**LANGUAGE**: XML

**CODE**:
```xml
<?xml version="1.0" encoding="utf-8"?>
<edmx:Edmx xmlns:edmx="http://docs.oasis-open.org/odata/ns/edmx" Version="4.0">
  <edmx:DataServices>
    <Schema xmlns="http://docs.oasis-open.org/odata/ns/edm" Namespace="Your.Service.Namespace">

      <!-- DataPoint annotation: maps a property to a value and a criticality (semantic color) -->
      <Annotations Target="Your.Service.Namespace.YourEntityType">
        <!-- Define a DataPoint (qualifier 'StatusPoint') -->
        <Annotation Term="com.sap.vocabularies.UI.v1.DataPoint" Qualifier="StatusPoint">
          <Record>
            <!-- Value: the property holding the text/number to display -->
            <PropertyValue Property="Value" Path="StatusText" />
            <!-- Criticality: maps to semantic colors, can be EnumMember with dynamic/path-based mapping -->
            <!-- Example: static criticality -->
            <PropertyValue Property="Criticality" EnumMember="com.sap.vocabularies.UI.v1.CriticalityType/Neutral" />
            <!-- Example: dynamic criticality based on a Path (uncomment and use instead of static above)
            <PropertyValue Property="Criticality">
              <Path>StatusCriticality</Path>
            </PropertyValue>
            -->
          </Record>
        </Annotation>

        <!-- Reference the DataPoint from the LineItem so list tables show the status visualization -->
        <Annotation Term="com.sap.vocabularies.UI.v1.LineItem">
          <Collection>
            <Record Type="com.sap.vocabularies.UI.v1.DataFieldForAnnotation">
              <PropertyValue Property="Label" String="Status" />
              <!-- Reference the DataPoint via AnnotationPath including qualifier -->
              <PropertyValue Property="Target">
                <AnnotationPath>com.sap.vocabularies.UI.v1.DataPoint#StatusPoint</AnnotationPath>
              </PropertyValue>
            </Record>

            <!-- Keep other LineItem entries here (e.g., other columns) -->
          </Collection>
        </Annotation>
      </Annotations>

    </Schema>
  </edmx:DataServices>
</edmx:Edmx>
```

**STEP**: 2 — Configure intent-based navigation (List -> Object or cross-app navigation)

**DESCRIPTION**: Add a DataFieldForIntentBasedNavigation annotation in the LineItem (or Action area) to enable navigation using Semantic Object and Action. The framework generates the navigation control; replace SemanticObject and Action with your app’s intent mapping. Place this annotation where list rows or action items are defined.

File path (example): app/annotations/<YourService>.annotations.xml

**LANGUAGE**: XML

**CODE**:
```xml
<?xml version="1.0" encoding="utf-8"?>
<edmx:Edmx xmlns:edmx="http://docs.oasis-open.org/odata/ns/edmx" Version="4.0">
  <edmx:DataServices>
    <Schema xmlns="http://docs.oasis-open.org/odata/ns/edm" Namespace="Your.Service.Namespace">

      <Annotations Target="Your.Service.Namespace.YourEntityType">
        <Annotation Term="com.sap.vocabularies.UI.v1.LineItem">
          <Collection>
            <!-- Intent-based navigation column/action on a line item -->
            <Record Type="com.sap.vocabularies.UI.v1.DataFieldForIntentBasedNavigation">
              <PropertyValue Property="Label" String="Open Details" />
              <!-- Semantic Object that maps to the target application -->
              <PropertyValue Property="SemanticObject" String="SalesOrder" />
              <!-- Action like 'displayFactSheet' or 'manage' depending on your intent -->
              <PropertyValue Property="Action" String="display" />
              <!-- Optional: target parameters passed to the target intent -->
              <!-- Use a Target with a Path if you need to pass entity keys/fields -->
              <!-- Example: pass SalesOrderID as parameter (framework resolves automatically) -->
              <PropertyValue Property="Parameters">
                <Collection>
                  <Record>
                    <PropertyValue Property="LocalProperty" PropertyPath="SalesOrderID" />
                    <PropertyValue Property="SemanticObjectProperty" String="SalesOrderID" />
                  </Record>
                </Collection>
              </PropertyValue>
            </Record>

            <!-- Other LineItem columns -->
          </Collection>
        </Annotation>
      </Annotations>

    </Schema>
  </edmx:DataServices>
</edmx:Edmx>
```

**STEP**: 3 — Apply annotations to Object Page header/actions where appropriate

**DESCRIPTION**: Use the same DataPoint or DataFieldForIntentBasedNavigation annotations in the Object Page context. For example, reference the DataPoint in UI.HeaderInfo or place intent-based navigation actions in UI.Facets or UI.HeaderAction. Ensure the Target in annotations refers to the Object Page entity type.

**LANGUAGE**: XML

**CODE**:
```xml
<!-- Example: reference DataPoint in HeaderInfo for object page header -->
<Annotation Term="com.sap.vocabularies.UI.v1.HeaderInfo" Target="Your.Service.Namespace.YourEntityType">
  <Record>
    <PropertyValue Property="TypeName" String="Sales Order" />
    <PropertyValue Property="TypeNamePlural" String="Sales Orders" />
    <PropertyValue Property="Title">
      <Record Type="com.sap.vocabularies.UI.v1.DataFieldForAnnotation">
        <PropertyValue Property="Target">
          <AnnotationPath>com.sap.vocabularies.UI.v1.DataPoint#StatusPoint</AnnotationPath>
        </PropertyValue>
      </Record>
    </PropertyValue>
  </Record>
</Annotation>

<!-- Example: add an intent-based header action -->
<Annotation Term="com.sap.vocabularies.UI.v1.HeaderFacets" Target="Your.Service.Namespace.YourEntityType">
  <Collection>
    <Record Type="com.sap.vocabularies.UI.v1.CollectionFacet">
      <PropertyValue Property="Label" String="Actions" />
      <PropertyValue Property="Target">
        <AnnotationPath>com.sap.vocabularies.UI.v1.FieldGroup#HeaderActions</AnnotationPath>
      </PropertyValue>
    </Record>
  </Collection>
</Annotation>

<!-- Define the header action FieldGroup#HeaderActions and include DataFieldForIntentBasedNavigation as needed -->
```

**STEP**: 4 — Verify and test in the Fiori elements app

**DESCRIPTION**: After adding/updating annotations:
- Rebuild and serve the Fiori app.
- Open the List Report to confirm the status column displays colored badges according to Criticality and that row or action navigation triggers the expected intent.
- Open an Object Page to confirm header/status render and header actions work as configured.

**LANGUAGE**: JSON (optional — annotation manifest mapping)

**CODE**:
```json
{
  "sap.app": {
    "id": "your.app.id",
    "dataSources": {
      "mainService": {
        "uri": "/sap/opu/odata/sap/YOUR_SERVICE_SRV/",
        "type": "OData",
        "settings": {
          "annotations": [
            {
              "uri": "annotations/YourService.annotations.xml"
            }
          ]
        }
      }
    }
  }
}
```

fiori-elements-framework annotations status criticality navigation data-point intent-based-navigation list-report object-page


**TITLE**: Configuring Internal Navigation for SAP Fiori Elements (OData V2 & V4)

**INTRODUCTION**: Practical, code-focused guidance for configuring internal navigation in SAP Fiori Elements apps. Covers enabling/disabling navigation after actions, configuring page hierarchies for OData V2, routing/navigation targets for OData V4, availability-based navigation, mapping child entities to list reports, linking entities via DataFieldWithNavigationPath (XML / ABAP CDS / CAP CDS), and the navigateToInstance setting for action behavior.

**TAGS**: fiori-elements-framework, navigation, manifest.json, OData V2, OData V4, DataFieldForAction, DataFieldWithNavigationPath, annotations

STEP: 1 — Default behavior: navigation after executing an action
DESCRIPTION: Understand the default navigation behavior when executing UI.DataFieldForAction annotations. Navigation occurs automatically only if a single instance is returned that is different from the triggering instance, the action succeeded, and manifest navigation exists for the returned context. Multiple selected contexts in toolbar actions will not trigger navigation.
LANGUAGE: Text
CODE:
```text
By default, when executing an action defined using the `UI.DataFieldForAction` annotation, navigation is automatically triggered after the action is executed. This happens if a single instance is returned by the action and if the returned instance is not the same as the instance used when the action was triggered. The navigation is only triggered if the action was executed successfully and if the manifest has navigation defined for the context that is returned. In addition, when a user selects multiple contexts for a table or chart toolbar action, the navigation is not triggered, even if the action returns the context.
```

STEP: 2 — OData V2: Configure page hierarchy and enable/disable chevron navigation
DESCRIPTION: Configure pages and subpages in manifest.json to enable navigation (chevrons). Keep predefined page definitions to allow navigation; remove those blocks to disable navigation to that level. Recommend specifying navigationProperty for subpages.
LANGUAGE: JSON
CODE:
```json
"sap.ui.generic.app": {
  "pages": {
    "MyListReport": {
      "entitySet": "MyEntitySet",
      "component": {
        "name": "sap.suite.ui.generic.template.ListReport",
        "list": true
      },
      // Navigation to detail page: eliminate this block if no navigation is needed
      "pages": {
        "MyObjectPageOnFirstLevel":          {
          "entitySet": "MyEntitySet",
          "component": {
            "name": "sap.suite.ui.generic.template.ObjectPage"
          },
          "pages": {
                                   "MyFirstObjectPageOnSecondLevel": {
              "navigationProperty": "to_MyFirstEntitySet",
              "entitySet": "MyFirstEntitySet",
              "component": {
                "name": "sap.suite.ui.generic.template.ObjectPage"
              },
            },
                                               "MySecondObjectPageOnSecondLevel": {
              "navigationProperty": "to_MySecondEntitySetNavigation",
              "entitySet": "MMySecondEntitySet",
              "component": {
                "name": "sap.suite.ui.generic.template.ObjectPage"
              },
            },
                                               "MyThirdObjectPageOnSecondLevel": {
              "navigationProperty": "to_MyThirdEntitySet",
              "entitySet": "MyThirdEntitySet",
              "component": {
                "name": "sap.suite.ui.generic.template.ObjectPage"
              }
            }
          }
        }
      }
    }
  }
}
```

STEP: 3 — OData V2: Disable navigation after executing DataFieldForAction in object page tables
DESCRIPTION: For DataFieldForAction annotations in object page tables, disable automatic navigation after action execution using navigateToInstance under annotatedActions in manifest.json.
LANGUAGE: JSON
CODE:
```json
"to_Item::com.sap.vocabularies.UI.v1.LineItem": {
    "tableSettings": {
        ...,
        ...
    },
    "annotatedActions": {
        "C_STTA_SalesOrderItem_WD_20Setopportunityid": {
            "afterExecution": {
                "navigateToInstance": false
            }
        }
    }
}
```

STEP: 4 — OData V2: Show item list in list report while displaying parent object with child entities on object page
DESCRIPTION: Map a child entity to a list report page and direct Create action in the list report to the parent/main entity by setting creationEntitySet in the ListReport component settings.
LANGUAGE: JSON
CODE:
```json
  "component": {
    "name": "sap.suite.ui.generic.template.ListReport",
    "list": true,
    "settings": {
      // Create of parent entity: Provide the parent entity set name.
      "creationEntitySet": "C_MPPurchasingSource"
    }
  }
```

STEP: 5 — OData V4: Configure routing and enable/disable navigation per target
DESCRIPTION: Define navigation under each target in manifest.json (sap.ui5.routing.targets options.settings.navigation). Remove navigation sections to disable chevrons for that target. Use navigation property paths (not entity set names) as keys under navigation.
LANGUAGE: JSON
CODE:
```json
The pages structure of the app should always be a tree, with the root as either a list report or an analytical list page. All the{
…
…
"sap.ui5": {
    ....
    ....
    ....
    "routing": {
…
…
        "routes": [{
            "pattern": ":?query:",
            "name": "ArtistList",
            "target": "ArtistList"
        }, {
            "pattern": "Artists({key}):?query:",
            "name": "ArtistDetail",
            "target": "ArtistObjectPage"
        }],
        "targets":{
            "ArtistList": {
                "type": "Component",
                "id": "ArtistList",
                "name": "sap.fe.templates.ListReport",
                "options": {
                    "settings" :{
                        "contextPath": "/Artists",
                        "navigation": {                              // Navigation Section to detail page: Eliminate if no navigation is required.
                            "Artists": {
                                "detail": {
                                    "route": "ArtistObjectPage" // This triggers the regular internal navigation to OP from LR table record
                                }
                            }
                        }
                    }
                }
            }, // End of ArtistList
            "ArtistObjectPage": {
                "type": "Component",
                "id":  "ArtistDetail",
                "name": "sap.fe.templates.ObjectPage",
               "options": {
                 "setting": {
                  …..
                  …..
                  "navigation": {               // Navigation Section to SubOP detail page: Eliminate if no navigation is required.
                            "_Records": {       // NOTE: This should refer to navigation path and NOT navigation entity name
                                "detail": {
                                    "route": "RecordSubObjectPage" // This triggers the regular internal navigation from OP "Records" table record to SubOP
                                }
                            },
                            "_Publishers": {    // NOTE: This should refer to navigation path and NOT navigation entity name
                                "detail": {
                                    "route": "PublisherSubObjectPage" // This triggers the regular internal navigation from OP "Publisher" table record to SubOP
                                }
                            }
                        }
                    }
                  }
                 ...
                 ...
            } // End of ArtistObjectPage
        } // End of Targets
     }, // End of routing
    .....
    .....
    .....
  } // End of sap.ui
…
…
}
```

STEP: 6 — OData V4: Disable navigation per route using availability expression or formatter
DESCRIPTION: Use the availability property in navigation detail to conditionally disable navigation. Provide either an expression binding or a formatter that returns boolean.
LANGUAGE: JSON / JavaScript
CODE:
```json
"Travel": {
    "detail": {
        "route": "objectPage",
	    "availability": "{= ${TravelStatus_code} === 'O'}"
    }
}
```

```json
"Travel": {
	"detail": {
		"route": "objectPage",
		"availability": "{path: 'TravelStatus_code', formatter: '.extension.sap.fe.core.fpmExplorer.customHeaderListReport.LRExtend.isNavigable'}"
	}
}
...
isNavigable: function(travelStatus, context) {
	return travelStatus !== "O"
}
```

STEP: 7 — Navigation between entities: map UI.DataFieldWithNavigationPath to routing target parameters
DESCRIPTION: Use the manifest navigation section to map a navigation path (Target in DataFieldWithNavigationPath) to a UI5 route and resolve route pattern parameters via relative binding paths.
LANGUAGE: JSON
CODE:
```json
"routing": {
"routes": [
        {
            "pattern": "SalesOrderManage({key}):?query:",
            "name": "SalesOrderManageObjectPage",
            "target": "SalesOrderManageObjectPage"
        }
    ],
"targets": {
    "SalesOrderManageObjectPage":
        {
            "type": "Component",
            "id": "SalesOrderManageObjectPage",
            "name": "sap.fe.templates.ObjectPage",
            "options": {
                "settings": {
                    "contextPath":    "/SalesOrderManage",
                    "navigation": {
                        "to_SalesOrder": {  // 'Target' of UI.DataFieldWithNavigationPath annotation
                            "detail": {
                                "route": "SalesOrderManageObjectPage",
                                "parameters": {
                                    "key":  "{_ReferencedSalesOrder/ID}"
                                }
                           }
                      }
                 }
            }
    }
}
        }
    }
}
```

STEP: 8 — DataFieldWithNavigationPath annotations: XML, ABAP CDS, CAP CDS examples
DESCRIPTION: Implement UI.DataFieldWithNavigationPath in your metadata/annotations to create in-app links. The Target property must match the manifest navigation key (navigation property path).
LANGUAGE: XML
CODE:
```xml
<Annotation Term="UI.FieldGroup" Qualifier="NavExample">
    <Record>
        <PropertyValue Property="Data">
            <Collection>
                <Record Type="UI.DataFieldWithNavigationPath">
                    <PropertyValue Property="Label" String="Ref. Sales Order" />
                    <PropertyValue Property="Value" Path="RefSalesOrderID" />
                    <PropertyValue Property="Target" NavigationPropertyPath="to_SalesOrder" />
                </Record>
            </Collection>
        </PropertyValue>
    </Record>
</Annotation>
```

LANGUAGE: ABAP CDS
CODE:
```
@UI.fieldGroup: [
  {
    targetelement: 'TO_SALESORDER',
    label: 'Ref. Sales Order',
    value: 'REFSALESORDERID',
    type: #WITH_NAVIGATION_PATH,
    position: 1 ,
    qualifier: 'NavExample'
  }
]
REFSALESORDERID;
```

LANGUAGE: CAP CDS
CODE:
```
UI.FieldGroup #NavExample : {
    Data : [
        {
            $Type : 'UI.DataFieldWithNavigationPath',
            Label : 'Ref. Sales Order',
            Value : RefSalesOrderID,
            Target : to_SalesOrder
        }
    ]
}
```

STEP: 9 — OData V4: Disable navigation after executing actions (navigateToInstance)
DESCRIPTION: Disable automatic navigation after action execution by setting navigateToInstance: false for action keys. For bound actions, use actions section; for inline actions define this under columns. Keys must start with DataFieldForAction::<ActionName>.
LANGUAGE: JSON
CODE:
```json
"com.sap.vocabularies.UI.v1.LineItem": {
    "tableSettings": {
        ...,
        ...
    },
    "actions": {
        "DataFieldForAction::com.c_salesordermanage_sd.AddRandomItem": {
            "afterExecution": {
                "navigateToInstance": false
            }
        },
        "DataFieldForAction::com.c_salesordermanage_sd.DummyBoundAction": {
            "afterExecution": {
                "navigateToInstance": false
            }
        }
    }
}
```

```json
"com.sap.vocabularies.UI.v1.LineItem": {
    "tableSettings": {
        ...,
        ...
    },
    "columns": {
        "DataFieldForAction::com.c_salesordermanage_sd.AddRandomItem": {
            "afterExecution": {
                "navigateToInstance": false
            }
        },
        "DataFieldForAction::com.c_salesordermanage_sd.DummyBoundAction": {
            "afterExecution": {
                "navigateToInstance": false
                }
            }
        }
     }
}
```

STEP: 10 — Rules: when navigation after action works and does not work
DESCRIPTION: Use this checklist when enabling navigateToInstance or troubleshooting navigation behavior.
LANGUAGE: Text
CODE:
```text
Navigation after executing an action works in the following cases:
- If the returned context belongs to the same entity as the context that triggered the action. For example, navigation is not triggered if the table action (with the table pointing to a navigation entity) returns an object that belongs to the header entity.
- For bound actions in the table toolbar, inline actions, header and footer actions, and form actions.
- For annotation-based custom actions.
- For navigation to the next level, as defined through routing.

Navigation after executing an action doesn't work in the following cases:
- For the chart toolbar.
- For subobject pages, the control associated with the action is refreshed, since navigation isn't possible.
- For standard actions in SAP Fiori elements, such as Save, Edit, or Create.
- For manifest-based actions.
- For external navigation.
```

STEP: 11 — In-page navigation for header facets
DESCRIPTION: Header facets support in-page navigation. Reference the Navigation from Header Facet Title guide for details and examples.
LANGUAGE: Text
CODE:
```text
Header facets supports in-page navigation. For more information, see Navigation from Header Facet Title (navigation-from-header-facet-title-fa0ca22.md)
```

fiori-elements-framework
navigation
manifest.json
OData V2
OData V4
DataFieldForAction
DataFieldWithNavigationPath
annotations


**TITLE**: Configuring List Report Features for SAP Fiori Elements

**INTRODUCTION**: This document describes actionable steps and code examples to configure List Report features in SAP Fiori Elements applications. It shows how to set the table type, define the filter bar (selection fields), and define table columns (line items) using manifest configuration, annotation XML/JSON, and CDS annotations. Use the exact snippets in your project files (manifest.json, annotations.xml, or CDS model) and adapt entity and property names to your data model.

**TAGS**: fiori-elements-framework, list-report, annotations, filter-bar, table-type, manifest.json, annotations.xml, CDS

**STEP**: 1 — Set the List Report table type in the application manifest

**DESCRIPTION**: Configure the List Report page in manifest.json to set the table rendering mode. Replace pageId, entitySet, and component name as needed. Common table types: ResponsiveTable, GridTable, AnalyticalTable, TreeTable.

**LANGUAGE**: JSON

**CODE**:
```json
{
  "sap.ui5": {
    "models": {
      "": {
        "dataSource": "mainService"
      }
    }
  },
  "sap.ui.generic.app": {
    "pages": [
      {
        "entitySet": "SalesOrders",
        "component": {
          "name": "sap.suite.ui.generic.template.ListReport",
          "settings": {
            "tableType": "ResponsiveTable"
          }
        }
      }
    ]
  }
}
```

**STEP**: 2 — Define selection (filter) fields using annotations.xml (OData V2/V4)

**DESCRIPTION**: Add com.sap.vocabularies.UI.v1.SelectionFields annotation to expose properties in the List Report filter bar. Replace Target with your entity full name and PropertyPath values with entity properties.

**LANGUAGE**: XML

**CODE**:
```xml
<Annotations Target="MyService.SalesOrder">
  <Annotation Term="com.sap.vocabularies.UI.v1.SelectionFields">
    <Collection>
      <PropertyPath>SalesOrderID</PropertyPath>
      <PropertyPath>CustomerName</PropertyPath>
      <PropertyPath>OrderDate</PropertyPath>
    </Collection>
  </Annotation>
</Annotations>
```

**STEP**: 3 — Define table columns (LineItem) using annotations.xml

**DESCRIPTION**: Use UI.LineItem annotation to declare which properties appear as columns in the List Report table and control labels, value formats, and positions.

**LANGUAGE**: XML

**CODE**:
```xml
<Annotations Target="MyService.SalesOrderType">
  <Annotation Term="com.sap.vocabularies.UI.v1.LineItem">
    <Collection>
      <Record Type="com.sap.vocabularies.UI.v1.DataField">
        <PropertyPath>SalesOrderID</PropertyPath>
      </Record>
      <Record Type="com.sap.vocabularies.UI.v1.DataField">
        <PropertyPath>CustomerName</PropertyPath>
      </Record>
      <Record Type="com.sap.vocabularies.UI.v1.DataField">
        <PropertyPath>TotalAmount</PropertyPath>
      </Record>
      <Record Type="com.sap.vocabularies.UI.v1.DataFieldWithIntentBasedNavigation">
        <PropertyPath>SalesOrderID</PropertyPath>
        <Label>Open Details</Label>
      </Record>
    </Collection>
  </Annotation>
</Annotations>
```

**STEP**: 4 — Equivalent JSON annotations for services that consume JSON annotation files

**DESCRIPTION**: If your annotation format is JSON, provide the corresponding structures for SelectionFields and LineItem. Adjust Target and property names.

**LANGUAGE**: JSON

**CODE**:
```json
{
  "Annotations": [
    {
      "Target": "MyService.SalesOrder",
      "Annotation": {
        "Term": "com.sap.vocabularies.UI.v1.SelectionFields",
        "Collection": [
          { "PropertyPath": "SalesOrderID" },
          { "PropertyPath": "CustomerName" },
          { "PropertyPath": "OrderDate" }
        ]
      }
    },
    {
      "Target": "MyService.SalesOrderType",
      "Annotation": {
        "Term": "com.sap.vocabularies.UI.v1.LineItem",
        "Collection": [
          { "Record": { "Type": "com.sap.vocabularies.UI.v1.DataField", "PropertyPath": "SalesOrderID" } },
          { "Record": { "Type": "com.sap.vocabularies.UI.v1.DataField", "PropertyPath": "CustomerName" } },
          { "Record": { "Type": "com.sap.vocabularies.UI.v1.DataField", "PropertyPath": "TotalAmount" } }
        ]
      }
    }
  ]
}
```

**STEP**: 5 — Configure filters and line items using CDS annotations (CAP / ABAP CDS)

**DESCRIPTION**: For CDS-based models, use @UI annotations directly in the CDS entity definition. Replace entity and field names as appropriate.

**LANGUAGE**: CDS

**CODE**:
```cds
namespace my.bookshop;

entity SalesOrder {
  key SalesOrderID : String(32);
  CustomerName : String(100);
  OrderDate : Date;
  TotalAmount : Decimal(15,2);

  @UI.hidden : false
  @UI.selectionField : [{ position: 10 }]
  SalesOrderID;

  @UI.selectionField : [{ position: 20 }]
  CustomerName;

  @UI.lineItem : [
    { position: 10 },
    { value: SalesOrderID },
    { value: CustomerName },
    { value: TotalAmount, position: 30 }
  ];
}
```

**STEP**: 6 — Combine manifest and annotations: deployment checklist

**DESCRIPTION**: Ensure the following:
- manifest.json pages entry points to the correct entitySet.
- Annotations file (annotations.xml or annotations.json) is referenced in manifest (if not using service metadata).
- Annotation Target values match entity/complex type names exposed by your OData service.
- For CAP/CDS, register the generated annotations or expose the service metadata so Fiori Elements consumes them.

**LANGUAGE**: JSON

**CODE**:
```json
{
  "sap.app": {
    "id": "com.mycompany.app"
  },
  "sap.ui5": {
    "models": {
      "annotationModel": {
        "dataSource": "annotations"
      }
    }
  },
  "sap.ui": {
    "resources": {}
  },
  "sap.ui.generic.app": {
    "pages": [
      {
        "entitySet": "SalesOrders",
        "component": {
          "name": "sap.suite.ui.generic.template.ListReport",
          "settings": {
            "tableType": "GridTable"
          }
        }
      }
    ]
  },
  "sap.app": {
    "dataSources": {
      "annotations": {
        "uri": "annotations/annotations.xml"
      }
    }
  }
}
```

fiori-elements-framework list-report annotations filter-bar table-type manifest.json annotations.xml CDS


**TITLE**: Configuring Navigation for SAP Fiori elements

**INTRODUCTION**: This document summarizes the navigation configuration options available in SAP Fiori elements apps. It covers internal (in-app) navigation and external navigation (outbound and inbound), and points to detailed configuration documents for each scenario. Use these steps as a quick reference for generating or updating app navigation logic and manifest references.

**TAGS**: fiori-elements-framework, navigation, internal-navigation, external-navigation, semantic-object, outbound, inbound, overview-page

**STEP**: 1 — Overview and design guidance

**DESCRIPTION**: Review general navigation concepts and how SAP Fiori elements approaches navigation. Use the SAP Fiori Design Guidelines for overall navigation principles and then apply Fiori elements-specific options listed below.

**LANGUAGE**: Markdown

**CODE**:
```markdown
<!-- loioa42427550b72436a8bdf53045b06effb -->

Fiori Design Guidelines — Navigation:
https://experience.sap.com/fiori-design/concept/navigation/

Available navigation options in SAP Fiori elements:
- Internal navigation (standard navigation within an app)
- External navigation
  - Outbound navigation (app triggers navigation)
    - Using a URL
    - Using a semantic object (intent-based navigation)
  - Inbound navigation (app is the navigation target)
```

**STEP**: 2 — Configure Internal Navigation

**DESCRIPTION**: Internal navigation refers to standard navigation within the app (pages, lists, object pages, etc.). For implementation details, code patterns, and manifest/settings to enable internal navigation flows, consult the dedicated internal navigation configuration guide.

**LANGUAGE**: Markdown

**CODE**:
```markdown
See detailed internal navigation configuration:
./configuring-internal-navigation-2c65f07.md
```

**STEP**: 3 — Configure External Navigation (Outbound and Inbound)

**DESCRIPTION**: External navigation covers scenarios where your Fiori elements app either initiates navigation to another app (outbound) or acts as a target for navigation (inbound). Outbound navigation can be implemented using direct URLs or intent-based navigation via semantic objects. Use the external navigation guide for manifest examples, semantic object mapping, and intent handling.

**LANGUAGE**: Markdown

**CODE**:
```markdown
External navigation options:
- Outbound:
  - Using a URL
  - Using a semantic object (intent-based navigation)
- Inbound:
  - Configure the app to be a navigation target (intent handling)

See detailed external navigation configuration:
./configuring-external-navigation-1d4a0f9.md
```

**STEP**: 4 — Configure Card (Overview Page) Navigation

**DESCRIPTION**: For overview pages that use cards, navigation behavior for cards (target URLs, semantic objects, or internal navigation targets) is configured separately. Refer to the card navigation guide for card manifest settings and examples.

**LANGUAGE**: Markdown

**CODE**:
```markdown
See card navigation configuration for overview pages:
./configuring-card-navigation-530f9e6.md
```

fiori-elements-framework navigation internal-navigation external-navigation semantic-object outbound inbound overview-page


**TITLE**: Configuring Object Page Features with UI Annotations

**INTRODUCTION**: Use UI annotations to configure an Object Page's header, identification area, and page sections (facets). This guide provides ready-to-use XML annotation templates and concise instructions for common Object Page scenarios: header info, identification fields, field groups, and facets (reference/collection). Replace placeholder names (Namespace.Service.MyEntityType, property names, qualifiers, labels) with your service/entity and properties.

**TAGS**: fiori-elements-framework, annotations, object-page, UI, odata, header, facets

**STEP**: 1 — Configure Header (Title and TypeName)

**DESCRIPTION**: Define the header title and type name shown on the Object Page. Use com.sap.vocabularies.UI.v1.HeaderInfo and set Title via Path to an entity property, and TypeName as a static label.

**LANGUAGE**: XML

**CODE**:
```xml
<Annotations Target="Namespace.Service.MyEntityType">
  <Annotation Term="com.sap.vocabularies.UI.v1.HeaderInfo">
    <Record>
      <!-- Static type label -->
      <PropertyValue Property="TypeName" String="My Entity"/>

      <!-- Title uses an entity property -->
      <PropertyValue Property="Title" Path="Name"/>
    </Record>
  </Annotation>
</Annotations>
```

**STEP**: 2 — Add Identification Fields (header details)

**DESCRIPTION**: Specify the individual properties displayed in the header’s identification area. Use com.sap.vocabularies.UI.v1.Identification with a collection of PropertyPath entries in the order you want them to appear.

**LANGUAGE**: XML

**CODE**:
```xml
<Annotations Target="Namespace.Service.MyEntityType">
  <Annotation Term="com.sap.vocabularies.UI.v1.Identification">
    <Collection>
      <PropertyPath>ProductID</PropertyPath>
      <PropertyPath>Name</PropertyPath>
      <PropertyPath>Status</PropertyPath>
    </Collection>
  </Annotation>
</Annotations>
```

**STEP**: 3 — Define Field Groups (reusable group of fields)

**DESCRIPTION**: Create FieldGroups (qualifier-based) to group properties for reuse in facets or header targets. Typical usage: reference a FieldGroup from a ReferenceFacet to render a form-like section on the Object Page.

**LANGUAGE**: XML

**CODE**:
```xml
<!-- FieldGroup with qualifier "General" -->
<Annotations Target="Namespace.Service.MyEntityType">
  <Annotation Term="com.sap.vocabularies.UI.v1.FieldGroup" Qualifier="General">
    <Record>
      <PropertyValue Property="Label" String="General Info"/>
      <PropertyValue Property="Data">
        <Collection>
          <!-- Use PropertyPath entries or DataField records as required -->
          <PropertyPath>Name</PropertyPath>
          <PropertyPath>Description</PropertyPath>
          <PropertyPath>Category</PropertyPath>
        </Collection>
      </PropertyValue>
    </Record>
  </Annotation>
</Annotations>
```

**STEP**: 4 — Configure Facets (sections and subsections)

**DESCRIPTION**: Use com.sap.vocabularies.UI.v1.Facets to define Object Page sections. Use ReferenceFacet to reference a FieldGroup (via AnnotationPath and qualifier) and CollectionFacet to show lists/tables (e.g., LineItem or custom qualifiers). Order facets in the Collection as they should appear.

**LANGUAGE**: XML

**CODE**:
```xml
<Annotations Target="Namespace.Service.MyEntityType">
  <Annotation Term="com.sap.vocabularies.UI.v1.Facets">
    <Collection>

      <!-- ReferenceFacet referencing a FieldGroup qualifier -->
      <Record Type="com.sap.vocabularies.UI.v1.ReferenceFacet">
        <PropertyValue Property="Label" String="General Information"/>
        <PropertyValue Property="Target">
          <Record Type="com.sap.vocabularies.UI.v1.Target">
            <!-- Reference the FieldGroup qualifier created above -->
            <PropertyValue Property="AnnotationPath" String="@com.sap.vocabularies.UI.v1.FieldGroup#General"/>
          </Record>
        </PropertyValue>
      </Record>

      <!-- CollectionFacet referencing a LineItem (list/table) qualifier -->
      <Record Type="com.sap.vocabularies.UI.v1.CollectionFacet">
        <PropertyValue Property="Label" String="Items"/>
        <PropertyValue Property="Target">
          <Record Type="com.sap.vocabularies.UI.v1.Target">
            <!-- Reference a LineItem annotation (could be default or qualifier-based) -->
            <PropertyValue Property="AnnotationPath" String="@com.sap.vocabularies.UI.v1.LineItem#Items"/>
          </Record>
        </PropertyValue>
      </Record>

    </Collection>
  </Annotation>
</Annotations>
```

**STEP**: 5 — Use Qualifiers and AnnotationPath consistently

**DESCRIPTION**: Qualifiers allow multiple annotations of the same term (e.g., multiple FieldGroups or LineItem views). When referencing them (e.g., from Facets or HeaderInfo), use the AnnotationPath format: @com.sap.vocabularies.UI.v1.<Term>#<Qualifier>. Ensure qualifiers match exactly between definition and reference.

**LANGUAGE**: XML

**CODE**:
```xml
<!-- Example: FieldGroup definition with qualifier "General" -->
<Annotation Term="com.sap.vocabularies.UI.v1.FieldGroup" Qualifier="General">
  ...
</Annotation>

<!-- Reference from a Facet using AnnotationPath -->
<PropertyValue Property="AnnotationPath" String="@com.sap.vocabularies.UI.v1.FieldGroup#General"/>
```

**STEP**: 6 — Related reference for prefilled/default values

**DESCRIPTION**: When creating entities or prefilling action parameters, you may also want to set default values. See the related documentation file for DefaultValuesFunction usage.

**LANGUAGE**: Markdown / Reference

**CODE**:
```text
Related information:
Prefilling Fields Using the DefaultValuesFunction
File: prefilling-fields-using-the-defaultvaluesfunction-5ada91c.md
```

fiori-elements-framework annotations object-page UI odata header facets


**TITLE**: Configuring Overview Page App Extensions (Fiori elements)

**INTRODUCTION**: This guide shows how to extend and customize the Overview Page (OVP) card and filter areas in a Fiori elements application. It includes concrete file locations, sample fragments, controller code and example manifest snippets you can copy and adapt. Use these steps to inject UI5 fragments/controllers into the OVP filter and card areas and to register custom card definitions in the manifest.

**TAGS**: fiori-elements, ovp, sapui5, manifest, extension, card, filter, fragment, controller

**STEP**: 1 — Create a fragment for the filter area

**DESCRIPTION**: Add a UI5 fragment that will be injected into the OVP filter area. Save under webapp/extension/Filter.fragment.xml. The fragment contains controls and IDs that your extension controller will use.

**LANGUAGE**: XML

**CODE**:
```xml
<!-- File: webapp/extension/Filter.fragment.xml -->
<core:FragmentDefinition
  xmlns:core="sap.ui.core"
  xmlns:m="sap.m">
  <m.VBox id="extFilterVBox" renderType="Bare">
    <m.Label text="Custom Filter" />
    <m.Input id="extFilterInput" placeholder="Enter value" />
    <m.Button text="Apply" press=".onApplyFilter" />
  </m.VBox>
</core:FragmentDefinition>
```

**STEP**: 2 — Create a fragment for the card area (optional)

**DESCRIPTION**: Add a fragment that will be injected into the OVP card area or used inside a custom card. Save under webapp/extension/Card.fragment.xml.

**LANGUAGE**: XML

**CODE**:
```xml
<!-- File: webapp/extension/Card.fragment.xml -->
<core:FragmentDefinition
  xmlns:core="sap.ui.core"
  xmlns:m="sap.m">
  <m.VBox id="extCardVBox" renderType="Bare">
    <m.Text text="Custom Card content" />
    <!-- Add your layout and binding controls here -->
  </m.VBox>
</core:FragmentDefinition>
```

**STEP**: 3 — Add a controller for your extension logic

**DESCRIPTION**: Implement the controller referenced by your fragment to handle UI events and to apply filters or interact with models. Save under webapp/extension/Filter.controller.js.

**LANGUAGE**: JavaScript

**CODE**:
```javascript
// File: webapp/extension/Filter.controller.js
sap.ui.define([
  "sap/ui/core/mvc/Controller",
  "sap/ui/model/Filter",
  "sap/ui/model/FilterOperator"
], function(Controller, Filter, FilterOperator) {
  "use strict";
  return Controller.extend("my.namespace.extension.Filter", {
    onInit: function() {
      // Initialization logic if needed
    },

    onApplyFilter: function() {
      var sValue = this.byId("extFilterInput").getValue();
      // Example: create filter and apply to a list/table in the OVP card via model binding
      // Adapt the target path and control lookup per your app structure
      var oFilter = new Filter("MyProperty", FilterOperator.EQ, sValue);

      // Example of dispatching an event, setting a model property, or finding a control and applying a filter
      // Option A: publish to an event bus (recommended if multiple components need it)
      var oEventBus = sap.ui.getCore().getEventBus();
      oEventBus.publish("my.namespace", "customFilterApplied", { filter: oFilter });

      // Option B: directly set parameters on a model or target control
      // var oList = sap.ui.getCore().byId("idOfTargetList");
      // if (oList && oList.getBinding("items")) {
      //   oList.getBinding("items").filter([oFilter]);
      // }
    }
  });
});
```

**STEP**: 4 — Register your fragments as view extensions in manifest.json

**DESCRIPTION**: Register the fragments under sap.ui5.viewExtensions in the application's manifest to inject them into the OVP. Confirm the correct view name / extension point keys for your OVP template (the examples below use common placeholders — update them to match your template's views/extension points).

**LANGUAGE**: JSON

**CODE**:
```json
{
  "sap.ui5": {
    "viewExtensions": {
      "sap.ovp.app.Main": {
        "ovpFilterArea": {
          "className": "sap.ui.core.Fragment",
          "fragment": "extension.Filter"
        },
        "ovpCardsArea": {
          "className": "sap.ui.core.Fragment",
          "fragment": "extension.Card"
        }
      }
    }
  }
}
```

**STEP**: 5 — Define custom card(s) in the manifest (sap.ovp)

**DESCRIPTION**: Configure custom cards in the "sap.ovp" section of manifest.json. Use "template" for built-in OVP card templates or attach a custom component under "component". Adjust "entitySet", "settings", and model names as required by your app.

**LANGUAGE**: JSON

**CODE**:
```json
{
  "sap.ovp": {
    "cards": {
      "MyCustomCard": {
        "template": "sap.ovp.cards.list",
        "settings": {
          "title": "My Custom Card",
          "subTitle": "",
          "entitySet": "MyEntitySet",
          "selectionAnnotationPath": ""
        },
        "model": "mainModel",
        "component": {
          "name": "my.namespace.custom.card",
          "settings": {
            // custom component settings
          }
        }
      }
    },
    "globalFilter": {
      "filters": [
        {
          "label": "Custom Filter",
          "path": "MyProperty"
        }
      ]
    }
  }
}
```

**STEP**: 6 — Implement the custom card component (optional)

**DESCRIPTION**: If you registered a custom component for a card, implement it under webapp/card (or the namespace you used). Provide Component.js, view(s), and controller(s) for the custom card. Example file paths:
- webapp/card/Component.js
- webapp/card/view/CardView.view.xml
- webapp/card/controller/CardView.controller.js

**LANGUAGE**: JavaScript / XML

**CODE**:
```javascript
// Example: webapp/card/Component.js (skeleton)
sap.ui.define(["sap/ui/core/UIComponent"], function(UIComponent) {
  "use strict";
  return UIComponent.extend("my.namespace.custom.card.Component", {
    metadata: {
      manifest: "json"
    },
    init: function() {
      UIComponent.prototype.init.apply(this, arguments);
    }
  });
});
```

**STEP**: 7 — Build, deploy and test

**DESCRIPTION**: After adding fragments, controllers and updating manifest.json:
- Rebuild or reload the app (ui5 tooling / Grunt / local server).
- Open the Overview Page and confirm:
  - The filter fragment is visible in the filter area and events call your controller.
  - The card fragment/component renders in the card area.
- Debug via browser console and network to verify models and bindings.

**NOTE**: Verify exact view names and extension point keys used by your OVP template (the manifest viewExtension keys vary by Fiori elements version). Replace placeholder view names (e.g., "sap.ovp.app.Main", "ovpFilterArea", "ovpCardsArea") with the values used in your project template.

fiori-elements ovp sapui5 manifest extension card filter fragment controller


**TITLE**: Configuring Overview Pages Using Runtime Capabilities (Rearrange, Hide, Resize, Filter Cards)

**INTRODUCTION**: Configure runtime behavior of Fiori overview pages so end users can rearrange, hide/show, resize, and filter cards. Includes end-user actions and developer manifest.json settings to enable card resizing and default sizing.

**TAGS**: fiori-elements-framework, overview-page, cards, manifest.json, personalization, runtime-capabilities, resize, filters

**STEP**: 1 — Rearranging Cards (End user)
**DESCRIPTION**: Allow end users to rearrange cards on an overview page via drag-and-drop or keyboard. Provide guidance for using ClickLock (Windows) to enable click-and-drag without holding the mouse button. Note constraints and behaviors:
- Interaction: drag-and-drop with mouse; or press Ctrl + Arrow keys to move focus and re-order.
- ClickLock (optional): enable in Windows to single-click, move, then second-click to commit.
  - Open Settings → Bluetooth and Devices → Touchpad
  - Click "More touchpad settings" → "Mouse Properties" dialog
  - Check "Turn on ClickLock"
- Limitations and best practices:
  - Personalization only retained for cards with same screen resolution and size.
  - Browser zoom must be 100% (default).
  - When moving a card, only the moved card’s target location is guaranteed to be saved; other cards auto-fit. To pin specific locations for all cards, move each card at least once.
**LANGUAGE**: text
CODE:
```text
(No code required — end-user interaction and OS settings)
```

**STEP**: 2 — Control Visibility of Cards (End user)
**DESCRIPTION**: Steps for end users to hide or show cards on the overview page and to reset to default view:
1. In the header bar, click/tap the Options icon → Manage Cards.
2. Use checkboxes to hide or show the relevant cards.
3. Click OK to save.
4. To reset to default, open Manage Cards and click Reset.
**LANGUAGE**: text
CODE:
```text
(No code required — UI steps)
```

**STEP**: 3 — Resize Cards (Developer + End user)
**DESCRIPTION**: End users can resize cards horizontally and vertically at runtime when the application enables resizable container layout. Developers must set containerLayout: "resizable" in manifest.json for the card(s). Optionally provide a default size via defaultSpan in manifest.json to load a card with specific default rows/cols.
- Prerequisite (developer): Set containerLayout: "resizable" for the relevant card(s) in manifest.json.
- End-user capability: Once enabled, users can drag resize handles to change a card’s width/height in the overview.
- Limitations: Resizing of stack cards is not supported.
- File: manifest.json — update card settings section for the specific card ID.
**LANGUAGE**: JSON
CODE:
```json
{
  "sap.ovp": {
    "cards": {
      "myCardId": {
        "component": {
          "name": "sap.ovp.cards.list"
        },
        "settings": {
          "containerLayout": "resizable",
          "defaultSpan": {
            "rows": 7,
            "cols": 2
          }
        }
      }
    }
  }
}
```

**STEP**: 4 — Preserve Original defaultSpan Example (Developer)
**DESCRIPTION**: Keep the original sample snippet for quick copy/paste into manifest.json when setting default card span.
**LANGUAGE**: JSON
CODE:
```json
"defaultSpan": {
  "rows": 7,
  "cols": 2
}
```

**STEP**: 5 — Filter Information Displayed in Cards (End user / Developer guidance)
**DESCRIPTION**: End users can apply filters on the overview page; filters affect all relevant cards showing that field. Example use case: filter to display only orders where supply date has passed. Implementation notes:
- End users: use the page’s filter controls (filter bar or filter panel) to define values or ranges for fields; changes propagate to all cards that consume the filtered field.
- Developers: ensure cards expose and bind the relevant OData properties/parameters so the overview page filter context is applied to each card’s data requests.
**LANGUAGE**: text
CODE:
```text
(No single code snippet provided — ensure cards are bound to OData model properties and support filter propagation from the overview page)
```

fiori-elements-framework overview-page cards manifest.json personalization runtime-capabilities resize filters