Fiori Enrichment Record Template | S/4HANA 2025 Evidence

In 30 seconds

What it is The September 2026 export gives you app identity, description, technology, component, LoB, lifecycle and a supplied transaction code. It does not give you a GUI relationship test result, earliest availability, Joule capability, implementation prerequisites, successor comparison, clean-core evidence, or a roadmap status. This page gives the seven-field evidence table, the eight rules for modeling that data safely, and a copyable CSV header, so a project can track it without inventing values.

You use it when You have an approved shortlist of Fiori apps and need a consistent record structure for the evidence the SAP export does not supply, before configuration or role design starts.

Guide covers Migration / Reference and Templates

Why it matters

The export’s evidence ends at a known boundary: it supplies app identity, description, UI technology, component, Line of Business, lifecycle status, backend stack and a supplied transaction code where one exists. Everything a project needs beyond that — whether a GUI transaction is actually replaced, when an app first became available, whether it carries a Joule capability, what its implementation prerequisites are, how it compares to its successor, whether it has a released clean-core extension point, and where it sits on SAP’s roadmap — is enrichment work the project has to do and track itself. This page is the record structure for that work, and the seven fields and eight rules below are this site’s catalogue analysis, not export columns.

Required evidence by field

Field	Required evidence
Proposed GUI relationship	Specific transaction, business task, scope exclusions, and test result
Earliest availability	Historical app/product release evidence, distinct from selected release
Joule capability	Exact capability, supported product/release, entitlement, source, verification date
Implementation prerequisites	Target-release app implementation record and project-specific configuration
Successor relationship	Explicit SAP relationship and feature comparison
Clean Core design	Released extension/API evidence and governed exceptions
Roadmap	SAP item ID, current status, planned period, and date checked

Decide

Question	If yes	If no
Is the app on the approved, tested shortlist?	Create an enrichment record for it.	Do not create a row. Do not duplicate thousands of empty enrichment cells for apps outside scope.
Do you have a source and a date for a field’s value?	Fill the field with the evidence, its source and the verification date.	Store the field as null with a documented reason, never as a silent blank and never as “No”.
Will this record ever be combined with a different product/release export?	Key it by App ID plus the selected product/release and backend stack.	App ID alone is sufficient, but remember it is unique only within this supplied snapshot.

Do this

Prepare · Solution Architect — Key records by App ID plus the selected product/release and backend stack whenever you combine multiple exports. App ID alone is unique only within this supplied snapshot.
Prepare · Fiori lead — Keep the original source fields separate from your editorial module grouping and implementation decisions; enrichment adds to the record, it does not overwrite it.
Prepare · Fiori lead — Preserve source Line of Business strings as supplied. A parsed multi-value filter can be derived from them without replacing the original text.
Prepare · Fiori lead — Preserve lifecycle status and App ID suffixes exactly. Never merge similarly named or versioned applications automatically.
Prepare · FI-CA lead / Utilities lead — Model GUI relationships as many-to-many business-task mappings with evidence and exclusions, not as one-to-one transaction replacements.
Prepare · Solution Architect — Store missing enrichment values as null, with a reason. Do not translate unknown Joule support into false.
Prepare · Solution Architect — Put roadmap records outside the delivered-app population; keep them in their own register with SAP item ID, status, target period and verification date.
Prepare · Solution Architect — Refresh the enrichment record by comparing snapshots and reviewing what changed, rather than overwriting historical evidence.

Copyable CSV header

app_id,product_release,backend_stack,proposed_gui_relationship,business_task,scope_exclusions,test_result,earliest_availability,joule_capability,joule_source,joule_verified_at,prerequisites,successor_app_id,successor_feature_comparison,clean_core_extension_evidence,roadmap_item_id,roadmap_status,roadmap_period,checked_at

For FI-CA, the business_task and scope_exclusions columns need to separate reversal coverage, reconciliation-key handling and payment clarification into distinct rows even when they point at the same app, because each has its own test result. For Utilities, do the same for meter-reading exceptions, billing outsorts and BPEM cases: one app can carry several genuinely different business tasks, and collapsing them into a single row loses the exclusion that matters most.

Do not populate this template for the entire 3,185-app export. This site’s catalogue analysis warns against duplicating thousands of empty enrichment cells for apps that are out of scope; their absence is already recorded once, at the source, and repeating it per app only adds maintenance burden without adding evidence.

The September 2026 export for product 2025 (Private Cloud) carries eleven source columns across 3,185 app records, covering App ID, app name, app description, UI technology, application component and its description, Line of Business, lifecycle status, backend stack, transaction code and the release label. Within those records, 97 descriptions, 68 Line of Business values and 140 backend-stack values are blank, and 726 records carry a supplied transaction code. None of the seven enrichment fields listed on this page is one of those eleven columns. The snapshot has not been revalidated against the live SAP Fiori Apps Reference Library.

Store this CSV in whatever tracker the project already uses for the business-task register (rule 2 above keeps it separate from the source data on purpose). A spreadsheet with one tab per sub-area works well in practice; a single flat sheet for all shortlisted apps tends to make the business_task and scope_exclusions columns unreadable once a project passes a few dozen rows.

Frequently asked questions

Should we create an enrichment record for every app in the export?

No. Create one only for apps on the approved, tested shortlist. This site's catalogue analysis warns against duplicating thousands of empty enrichment cells for apps that are not in scope; their absence is already recorded once, at the source, rather than repeated per app.

What do we put in a field when we do not yet have evidence?

Store it as null, with a documented reason, following this knowledge base's own data rule. Never translate unknown Joule support into false, and never leave a field silently blank where a later reader might assume it was checked and found empty.

Is App ID alone enough to key an enrichment record?

Only within this supplied snapshot. If you expect to combine this data with a different export, key records by App ID plus the selected product/release and backend stack, because App ID uniqueness is not guaranteed to hold across snapshots.