Introduction

Since the early announcement of the UI Integration Cards paradigm (as described in this article), we have been busy expanding the functionality of Cards, resulting in an ever-growing adoption across almost all SAP products.

Today, Cards are utilized in a range of solutions and scenarios, from the SAP S/4HANA home page with “To-Do” and Insights Cards, to SAP Build Work Zone, where Cards from any SAP product can be easily assembled together, to Joule, and also on mobile-native screens. 

The fundamental principles that underpin this technology, as detailed on our Card Explorer landing page, are that it is designed to be Declarative, Easy to consume, and Consistent.

Declarative: configured by a manifest.json                              ==> Low to No-code skills required (AI-gen@UI5 MCP server)Easy to consume: product and UI-technology agnostic      ==> Mobile-ready / Integration-ready via configurationConsistent: predefined card types in Fiori/Horizon design ==> Thoughtfully designed / Product Standards covered

Key Concepts and Capabilities

In this article, we’ll detail the key qualities and advantages of the Declarative Integration Cards. Declarative Card types offer a range of display options and minimalist interactions, including List Card, Table Card, Timeline, Calendar, Analytical, and Object Card with input elements.

Declarative Card types enable the fast and easy creation of “Home page” and “Overview” pages, where Card developers can integrate data from various sources to display relevant business data for any SAP or non-SAP product.

Declarative and Consistent

Integration Cards are straightforwardly defined using a single JSON descriptor file called manifest.json. This file is all you need to get a fully functional and nicely rendered representation of business data in the form of a Card. Once you have this descriptive manifest.json file, our Card Runtime can process it and render the card in a web browser or any mobile-native device, regardless of the UI framework. Hence – declarative!  

Anatomy of Declarative UI Integration Cards

Examining the Card’s structure, we can identify three separate parts:

The Card Header provides the card’s identity, typically represented by a title, subtitle, and icon or avatar/image attributes. It can also display more dynamic or complex data, such as the special Numeric Header, which prominently features a key numeric indicator, or an extended Header.

The Content / Data is the main part of the card that displays relevant business data in a selected type of view. These data types can be List, Table, Object, Analytical, Timeline, or Calendar.The Footer area is usually designated for intended Card interaction elements, such as action buttons or links for navigation.

The general structure of a declarative manifest.json looks like this: 

{
“sap.app”: {
“id”: “my.card.id”,
“type”: “card”,
“applicationVersion”: {
“version”: “1.0.0”
}
},
“sap.card”: {
“type”: “List”, // Card type: List, Table, Object, Analytical, Timeline, Calendar
“header”: {
// Header configuration
},
“content”: {
// Content configuration specific to card type
},
“footer”: {
// Optional footer with actions
}
}
}

The Card Header

The card header displays essential information about the card by grouping a set of card attributes and presenting them at the top of the card. The “sap.card”/header section is mandatory. Providing it together with the title is essential for proper screen reader support and other functionalities.

Integration Cards support three header configurations:

Default Header – Standard header with title, subtitle, icon, statusNumeric Header – KPI-focused header with prominent numeric indicatorsExtended Header with Info Section – flexible layout within either kind of header, capable of accommodating various components

All headers support actions, data timestamps, visibility control, and text wrapping options. 

Default Header

The standard header displays general information about the card. 

“header”: {
“title”: “An example title”,
“subtitle”: “Some subtitle”,
“icon”: {
“src”: “sap-icon://business-objects-experience”,
“visible”: true
},
“status”: {
“text”: “5 of 20”
}
}

Numeric Header

The Numeric Header is optimized for displaying KPIs, metrics, and quantitative data with prominent visualization. 

“header”: {
“type”: “Numeric”,
“title”: “Project Cloud Transformation”,
“subtitle”: “Revenue”,
“unitOfMeasurement”: “EUR”,
“mainIndicator”: {
“number”: “44”,
“unit”: “%”,
“trend”: “Down”,
“state”: “Critical”
},
“details”: “Some details”,
“sideIndicators”: [
{
“title”: “Target”,
“number”: “17”,
“unit”: “%”
},
{
“title”: “Deviation”,
“number”: “5”,
“unit”: “%”
}
]
}

Extended Header with Info Section

Both header types can be extended with an info section for additional grouped information.

Currently, only items of type “Status” are available.

“header”: {
“title”: “Project Cloud Transformation”,
“subtitle”: “Revenue”,
“infoSection”: {
“rows”: [
{
“items”: [
{
“type”: “Status”,
“value”: “On Track”,
“state”: “Success”,
“inverted”: true,
“showStateIcon”: true
},
{
“type”: “Status”,
“value”: “OKR Relevant”,
“state”: “None”,
“inverted”: true,
“showStateIcon”: true
},
…
]
}
]
}
}

The Card Content Area

The Card content area defines how data is rendered by selecting a declarative card type, each offering predefined structures and configuration options to visualize business information in a consistent and self-contained way.

List Card – Displays multiple items in a vertical list with flexible layouts to present titles, descriptions, and multiple attributes per item.Table Card – Visualizes structured data in rows and columns with configurable formatting, alignment, grouping, and item count to support clear data comparison and summarization.Object Card – Presents information about a single object in configurable groups, supporting rich attribute types, visibility control, and consistent usage across SAP products.Analytical Card – Displays analytical business data using chart visualizations with defined dimensions to ensure accurate and meaningful insight representation.Timeline Card – Shows time-related information as a sequence of events arranged chronologically with clear visual flow and contextual details.Calendar Card – Displays agenda or timetable data for an entity with interactive date selection, semantic legends, and dynamic data updates.

Stay tuned for future articles with details for every Card type. 

The Card Footer

The card footer, located at the bottom of the card, is used for important or routine actions that directly impact the card functionality, such as “Approve” or “Submit” actions. It serves as the designated area where users can interact with or respond to the card’s content through an Actions Strip—a flexible toolbar that accommodates a variety of interactive elements.

The Actions Strip supports diverse interaction patterns through three primary element types: Buttons for actionable operations, Links for navigation purposes, and Labels for displaying contextual information. Additionally, ToolbarSpacer elements provide precise control over the visual arrangement of actions, enabling left-aligned, right-aligned, or centered positioning within the footer.

Each action element can be extensively configured to match specific use cases. Buttons offer multiple visual styles (Accept, Reject, Transparent, Emphasized) and can display either text, icons, or both—with the ability to prefer icon-only display in space-constrained layouts. All elements support standard properties including tooltips, visibility conditions, accessibility attributes, and overflow behavior through overflowPriority settings (High, Low, NeverOverflow, AlwaysOverflow), which determine how actions adapt to different screen sizes.

Actions themselves can be of various types: Navigation actions for opening URLs or triggering deep links, Submit actions for posting data to backend services, Custom actions that invoke extension methods. Each action can be configured with parameters and enabled/disabled states, often bound to dynamic data for context-sensitive behavior.

Here’s an example demonstrating the versatility of footer configurations:

“footer”: {
“actionsStrip”: [
{
“type”: “Link”,
“text”: “View Details”,
“icon”: “sap-icon://detail-view”,
“actions”: [
{
“type”: “Navigation”,
“parameters”: {
“url”: “{detailsUrl}”
}
}
]
},
{
“type”: “ToolbarSpacer”
},
{
“text”: “Approve”,
“buttonType”: “Accept”,
“overflowPriority”: “High”,
“actions”: [
{
“type”: “Submit”,
“url”: “/api/approve”,
“method”: “POST”
}
]
},
{
“buttonType”: “Transparent”,
“icon”: “sap-icon://email”,
“preferIcon”: true,
“text”: “Contact”,
“tooltip”: “Send an email”,
“actions”: [
{
“type”: “Navigation”,
“parameters”: {
“url”: “mailto:{company/email}?subject={company/emailSubject}”
}
}
]
}
]
}

Beyond the Actions Strip, the footer supports additional built-in features that enhance usability. It provides built-in pagination/scrolling support through the “Show More” button, which elegantly handles content overflow by opening cards in an resizable Dialog view. When cards are displayed within dialogs, the footer automatically manages a “Close” button, streamlining the user experience without requiring explicit configuration. This is achieved by defining paginator element in the footer declaration. 

“footer”: {
“paginator”: {
“totalCount”: “{/itemsCount}”,
“pageSize”: 5
}
}

The footer’s visibility can be controlled dynamically through binding expressions, allowing it to appear only when specific conditions are met: 

“footer”: {
“visible”: “{= ${/itemsCount} > 0}”,
“actionsStrip”: [ /* actions configuration */ ]
}

Final Thoughts

You can use Declarative UI Integration Cards as an entry point to an app or if you want the user to focus on a single object, topic, or group of objects.

Avoid building complex, small apps within the card that require navigation flows. Instead of being complex or multifunctional, each card is designed to serve a specific role or display business data in a clear manner.

Clarity and simplicity are prioritized in Declarative UI Integration Cards, enabling users to easily understand and integrate the cards without unnecessary complexity or ambiguity.

The architecture’s three-part structure—header, content, and footer—establishes a predictable framework that accelerates development while ensuring consistency across diverse use cases. This structured approach not only simplifies the creation process but also enhances the end-user experience through familiar, intuitive patterns that work seamlessly across all SAP solutions.

By embracing the declarative paradigm, developers can rapidly compose powerful, data-driven cards without deep technical expertise, while maintaining the enterprise-grade quality and accessibility standards that users expect. The result is a flexible, scalable solution that transforms how business information is surfaced and acted upon across the digital workplace.

​ IntroductionSince the early announcement of the UI Integration Cards paradigm (as described in this article), we have been busy expanding the functionality of Cards, resulting in an ever-growing adoption across almost all SAP products.Today, Cards are utilized in a range of solutions and scenarios, from the SAP S/4HANA home page with “To-Do” and Insights Cards, to SAP Build Work Zone, where Cards from any SAP product can be easily assembled together, to Joule, and also on mobile-native screens.         The fundamental principles that underpin this technology, as detailed on our Card Explorer landing page, are that it is designed to be Declarative, Easy to consume, and Consistent.Declarative: configured by a manifest.json                              ==> Low to No-code skills required (AI-gen@UI5 MCP server)Easy to consume: product and UI-technology agnostic      ==> Mobile-ready / Integration-ready via configurationConsistent: predefined card types in Fiori/Horizon design ==> Thoughtfully designed / Product Standards coveredKey Concepts and CapabilitiesIn this article, we’ll detail the key qualities and advantages of the Declarative Integration Cards. Declarative Card types offer a range of display options and minimalist interactions, including List Card, Table Card, Timeline, Calendar, Analytical, and Object Card with input elements.Declarative Card types enable the fast and easy creation of “Home page” and “Overview” pages, where Card developers can integrate data from various sources to display relevant business data for any SAP or non-SAP product.Declarative and ConsistentIntegration Cards are straightforwardly defined using a single JSON descriptor file called manifest.json. This file is all you need to get a fully functional and nicely rendered representation of business data in the form of a Card. Once you have this descriptive manifest.json file, our Card Runtime can process it and render the card in a web browser or any mobile-native device, regardless of the UI framework. Hence – declarative!  Anatomy of Declarative UI Integration CardsExamining the Card’s structure, we can identify three separate parts:The Card Header provides the card’s identity, typically represented by a title, subtitle, and icon or avatar/image attributes. It can also display more dynamic or complex data, such as the special Numeric Header, which prominently features a key numeric indicator, or an extended Header.The Content / Data is the main part of the card that displays relevant business data in a selected type of view. These data types can be List, Table, Object, Analytical, Timeline, or Calendar.The Footer area is usually designated for intended Card interaction elements, such as action buttons or links for navigation.The general structure of a declarative manifest.json looks like this:  {
“sap.app”: {
“id”: “my.card.id”,
“type”: “card”,
“applicationVersion”: {
“version”: “1.0.0”
}
},
“sap.card”: {
“type”: “List”, // Card type: List, Table, Object, Analytical, Timeline, Calendar
“header”: {
// Header configuration
},
“content”: {
// Content configuration specific to card type
},
“footer”: {
// Optional footer with actions
}
}
} The Card HeaderThe card header displays essential information about the card by grouping a set of card attributes and presenting them at the top of the card. The “sap.card”/header section is mandatory. Providing it together with the title is essential for proper screen reader support and other functionalities.Integration Cards support three header configurations:Default Header – Standard header with title, subtitle, icon, statusNumeric Header – KPI-focused header with prominent numeric indicatorsExtended Header with Info Section – flexible layout within either kind of header, capable of accommodating various componentsAll headers support actions, data timestamps, visibility control, and text wrapping options. Default HeaderThe standard header displays general information about the card.  “header”: {
“title”: “An example title”,
“subtitle”: “Some subtitle”,
“icon”: {
“src”: “sap-icon://business-objects-experience”,
“visible”: true
},
“status”: {
“text”: “5 of 20”
}
} Numeric HeaderThe Numeric Header is optimized for displaying KPIs, metrics, and quantitative data with prominent visualization.  “header”: {
“type”: “Numeric”,
“title”: “Project Cloud Transformation”,
“subtitle”: “Revenue”,
“unitOfMeasurement”: “EUR”,
“mainIndicator”: {
“number”: “44”,
“unit”: “%”,
“trend”: “Down”,
“state”: “Critical”
},
“details”: “Some details”,
“sideIndicators”: [
{
“title”: “Target”,
“number”: “17”,
“unit”: “%”
},
{
“title”: “Deviation”,
“number”: “5”,
“unit”: “%”
}
]
} Extended Header with Info SectionBoth header types can be extended with an info section for additional grouped information.Currently, only items of type “Status” are available. “header”: {
“title”: “Project Cloud Transformation”,
“subtitle”: “Revenue”,
“infoSection”: {
“rows”: [
{
“items”: [
{
“type”: “Status”,
“value”: “On Track”,
“state”: “Success”,
“inverted”: true,
“showStateIcon”: true
},
{
“type”: “Status”,
“value”: “OKR Relevant”,
“state”: “None”,
“inverted”: true,
“showStateIcon”: true
},
…
]
}
]
}
} The Card Content AreaThe Card content area defines how data is rendered by selecting a declarative card type, each offering predefined structures and configuration options to visualize business information in a consistent and self-contained way.List Card – Displays multiple items in a vertical list with flexible layouts to present titles, descriptions, and multiple attributes per item.Table Card – Visualizes structured data in rows and columns with configurable formatting, alignment, grouping, and item count to support clear data comparison and summarization.Object Card – Presents information about a single object in configurable groups, supporting rich attribute types, visibility control, and consistent usage across SAP products.Analytical Card – Displays analytical business data using chart visualizations with defined dimensions to ensure accurate and meaningful insight representation.Timeline Card – Shows time-related information as a sequence of events arranged chronologically with clear visual flow and contextual details.Calendar Card – Displays agenda or timetable data for an entity with interactive date selection, semantic legends, and dynamic data updates.Stay tuned for future articles with details for every Card type. The Card FooterThe card footer, located at the bottom of the card, is used for important or routine actions that directly impact the card functionality, such as “Approve” or “Submit” actions. It serves as the designated area where users can interact with or respond to the card’s content through an Actions Strip—a flexible toolbar that accommodates a variety of interactive elements.The Actions Strip supports diverse interaction patterns through three primary element types: Buttons for actionable operations, Links for navigation purposes, and Labels for displaying contextual information. Additionally, ToolbarSpacer elements provide precise control over the visual arrangement of actions, enabling left-aligned, right-aligned, or centered positioning within the footer.Each action element can be extensively configured to match specific use cases. Buttons offer multiple visual styles (Accept, Reject, Transparent, Emphasized) and can display either text, icons, or both—with the ability to prefer icon-only display in space-constrained layouts. All elements support standard properties including tooltips, visibility conditions, accessibility attributes, and overflow behavior through overflowPriority settings (High, Low, NeverOverflow, AlwaysOverflow), which determine how actions adapt to different screen sizes.Actions themselves can be of various types: Navigation actions for opening URLs or triggering deep links, Submit actions for posting data to backend services, Custom actions that invoke extension methods. Each action can be configured with parameters and enabled/disabled states, often bound to dynamic data for context-sensitive behavior.Here’s an example demonstrating the versatility of footer configurations: “footer”: {
“actionsStrip”: [
{
“type”: “Link”,
“text”: “View Details”,
“icon”: “sap-icon://detail-view”,
“actions”: [
{
“type”: “Navigation”,
“parameters”: {
“url”: “{detailsUrl}”
}
}
]
},
{
“type”: “ToolbarSpacer”
},
{
“text”: “Approve”,
“buttonType”: “Accept”,
“overflowPriority”: “High”,
“actions”: [
{
“type”: “Submit”,
“url”: “/api/approve”,
“method”: “POST”
}
]
},
{
“buttonType”: “Transparent”,
“icon”: “sap-icon://email”,
“preferIcon”: true,
“text”: “Contact”,
“tooltip”: “Send an email”,
“actions”: [
{
“type”: “Navigation”,
“parameters”: {
“url”: “mailto:{company/email}?subject={company/emailSubject}”
}
}
]
}
]
} Beyond the Actions Strip, the footer supports additional built-in features that enhance usability. It provides built-in pagination/scrolling support through the “Show More” button, which elegantly handles content overflow by opening cards in an resizable Dialog view. When cards are displayed within dialogs, the footer automatically manages a “Close” button, streamlining the user experience without requiring explicit configuration. This is achieved by defining paginator element in the footer declaration.  “footer”: {
“paginator”: {
“totalCount”: “{/itemsCount}”,
“pageSize”: 5
}
}The footer’s visibility can be controlled dynamically through binding expressions, allowing it to appear only when specific conditions are met:  “footer”: {
“visible”: “{= ${/itemsCount} > 0}”,
“actionsStrip”: [ /* actions configuration */ ]
} Final ThoughtsYou can use Declarative UI Integration Cards as an entry point to an app or if you want the user to focus on a single object, topic, or group of objects.Avoid building complex, small apps within the card that require navigation flows. Instead of being complex or multifunctional, each card is designed to serve a specific role or display business data in a clear manner.Clarity and simplicity are prioritized in Declarative UI Integration Cards, enabling users to easily understand and integrate the cards without unnecessary complexity or ambiguity.The architecture’s three-part structure—header, content, and footer—establishes a predictable framework that accelerates development while ensuring consistency across diverse use cases. This structured approach not only simplifies the creation process but also enhances the end-user experience through familiar, intuitive patterns that work seamlessly across all SAP solutions.By embracing the declarative paradigm, developers can rapidly compose powerful, data-driven cards without deep technical expertise, while maintaining the enterprise-grade quality and accessibility standards that users expect. The result is a flexible, scalable solution that transforms how business information is surfaced and acted upon across the digital workplace.    Read More Technology Blog Posts by SAP articles 

#SAP

#SAPTechnologyblog