TL;DR

• Fiori is browser-reachable in a way SAP GUI’s Java client isn’t, but reachable is not the same as stable. Automating it reliably is a different problem than getting into it.
• SAPUI5 generates controls at runtime from OData metadata rather than fixed markup. That means dynamic control IDs, asynchronous rendering, and role or variant-driven UI differences, all of which break scripts that assume static HTML.
• SAP’s own recommended end-to-end testing framework changed in 2026. UIVeri5 was archived in July 2026. SAP now points teams to wdi5 instead.
• Generic web automation tools that rely on static locators are the most exposed. OpenText UFT One’s own community documentation shows the setup work required just to get Fiori objects recognized reliably.
• Sahi Pro identifies elements by relationship and context instead of fixed DOM position, which is built to survive exactly the kind of ID churn Fiori produces.
• We could not verify Fiori-specific failure details for Tricentis Tosca or Worksoft Certify beyond general “supported” claims in their own materials, so we are not implying weaknesses we cannot back up.

SAP Fiori runs in a browser. That single fact has led a lot of testing content, including our own comparison of Worksoft and Sahi Pro for SAP and Teamcenter testing, to describe Fiori as reachable by any competent web automation tool. That’s accurate as far as it goes. SAP GUI’s Java-based rich client needs a purpose-built engine to reach at all. Fiori doesn’t. But reachable isn’t the same as automatable without maintenance. Fiori apps, especially the SAP Fiori Elements apps most S/4HANA teams run today, don’t ship as fixed HTML. The screen is generated at runtime from OData metadata, which means the thing your script is looking for can be a different shape tomorrow than it was today, even though nothing about the underlying business process changed. This piece covers what actually makes that generation model hard to automate, what breaks first, and what SAP itself recommends as of 2026.

Fiori looks like a simple web app. Under the hood, it isn’t.

Fiori is a design language built on the SAPUI5 (or its open-source counterpart, OpenUI5) JavaScript framework. Instead of hand-written HTML, developers compose pre-built controls, tables, buttons, object pages, smart filters, that the framework renders to the DOM at runtime. The framework follows a model-view-controller pattern, and a two-way data binding layer keeps the rendered screen in sync with an underlying OData model automatically. That’s a fundamentally different starting point than a hand-authored web app, where element IDs and DOM structure are set once by a developer and stay put.

SAP documents two ways Fiori apps get built. Freestyle apps are custom-coded SAPUI5, closer to a typical single-page application, though still control-rendered rather than plain HTML. SAP Fiori Elements apps go a step further: the UI is generated at runtime directly from OData service metadata and annotations. The app declares what data and behavior it needs, and SAP’s smart templates generate the screen, using standard floorplans like List Report, Object Page, Overview Page, and Worklist. Most new S/4HANA development leans on Fiori Elements rather than freestyle apps.

This is the real root cause of automation fragility in Fiori. There is no fixed markup to target, because the same annotation set can render a different control structure depending on the OData service version, the annotation content, or even which generation of Fiori Elements (V2 versus V4) is running underneath.

What actually breaks when you automate it

Dynamic, auto-generated control IDs. SAPUI5 assigns control IDs at runtime, and those IDs are not guaranteed to stay the same across sessions, application launches, or SAPUI5 versions. A locator that matches today can point at nothing tomorrow, not because the business process changed, but because the framework regenerated its internal naming.

Asynchronous rendering tied to OData calls. UI5 builds the page after the data behind it arrives, not before. A script that checks for an element the instant a screen appears can be checking before the OData response has resolved, which produces flaky failures that look random but aren’t.

Role, variant, and personalization-driven differences. The same Fiori app is not the same screen for every user. SAP’s own App Variants and Key User Adaptation features let a screen render differently by role, company code, region, or device. A script built against one user’s view of a screen can fail against another user’s equally valid view of the same app.

Responsive and adaptive layout shifts. Fiori’s layouts adapt to screen size and window width. Automation built on fixed screen positions or coordinate-based clicks can miss entirely once the layout reflows to a different breakpoint.

Where common automation tools hit this wall

Generic web automation tools built around static locators are the most exposed to all four of the problems above, because they assume the DOM they recorded against is the DOM they’ll see again. SAP’s own community documentation makes the contrast directly: its wdi5 framework “automatically manages delays and busy indicators, whereas Selenium requires developers to code specifically for the delays, resulting in fragile tests.”

Among named commercial tools, the clearest documented example is OpenText UFT One. Its own community forum shows real setup requirements specific to Fiori: enabling the correct browser agent rather than relying on UFT’s standard “record and run on any open browser” behavior, activating the SAPUI5 add-in in UFT’s Add-in Manager, and configuring WebDriver before Fiori objects are recognized at all. OpenText’s own blog also describes property-based object recognition breaking on simple UI relabeling, using its own example of renaming a “Login” button to “Sign-In.” Its stated fix is an AI-based recognition layer added on top.

We looked for equivalent Fiori-specific failure detail on Tricentis Tosca and Worksoft Certify and could not find it. Both vendors describe Fiori support at a general “supported” level in their own materials, without documenting the specific failure modes UFT One’s own community has discussed openly. We’re noting the absence rather than guessing at a weakness we can’t verify.

SAP’s own testing tools, and where they stop short

SAP documents a testing pyramid of its own. QUnit handles unit-level tests for individual modules and controllers. OPA5, built on top of QUnit and shipped with SAPUI5, hides asynchronicity behind a polling mechanism and gives direct access to SAPUI5 elements, but it’s weak for true end-to-end testing: it has screen-capture restrictions, no remote execution, and complications around authentication flows.

For genuine end-to-end testing, SAP’s current recommendation is wdi5, a WebdriverIO service built on UI5’s own test API. It locates elements through UI5 control metadata instead of DOM selectors, and it synchronizes with the framework’s own rendering state instead of relying on fixed waits.

This matters for anyone building or updating a Fiori test strategy in 2026 specifically: UIVeri5, the tool a lot of older SAP testing content still points to, was archived as of July 2026. SAP is no longer developing it and now recommends wdi5 in its place. If your team’s Fiori testing approach is still built around UIVeri5, that’s worth revisiting on its own, independent of anything else in this piece.

Best practices for automating Fiori reliably

Locate elements by UI5 control metadata, not by DOM ID or XPath. SAP’s own UI5 Test Recorder generates the kind of stable control locator that wdi5 and OPA5 are built to use, and it’s a meaningfully different approach than recording raw DOM selectors.

Don’t rely on fixed sleeps for timing. Wait on the framework’s own rendering and data state instead, since a fixed pause either wastes time waiting past when the screen is ready or fails intermittently when it isn’t ready yet.

Test in layers, in order: load, render, data, authorization, end-to-end. Automating a full user journey before the individual layers underneath it are reliable makes it harder to tell which layer actually broke when a test fails.

Where Sahi Pro fits into this

Sahi Pro identifies elements by relationship and context rather than fixed DOM position or a generated control ID, which is the specific property Fiori’s ID churn stresses hardest. That’s not a Fiori-only feature. It’s how Sahi Pro identifies elements across SAP GUI, Fiori, the surrounding web layer, desktop applications, and mobile, in a single script, on a proprietary engine rather than a Selenium or Appium wrapper.

Sahi Pro customers report a 90% reduction in regression man-hours and an 80% reduction in test maintenance compared to conventional tools. Those are company-wide figures across Sahi Pro’s 1,000-plus enterprise customers, not a Fiori-specific case study, and we’re stating them as such rather than implying a Fiori-specific result we haven’t confirmed.

A note on recent Fiori changes. SAP’s Horizon theme is now the current default visual theme, with the older Belize theme officially removed. A pure theme change shouldn’t affect automation built on control metadata, but it will affect anything built on visual or pixel-based matching, which is worth checking if your suite leans on screenshots.

Ready to see how Sahi Pro handles your own Fiori screens? Book a demo and bring the Fiori flow that keeps breaking your current scripts. We will run it live.

Sources

• SAPUI5 SDK documentation
• SAP Fiori design system: get started with UI5
• Deep Dive into SAP Fiori Architecture (Medium)
• SAP Help: Using SAP Fiori Elements Floorplans
• SAP Community: Fiori Elements vs. Freestyle Apps
• SAP Fiori Elements overview
• Qyrus: why Fiori test automation scripts fail
• Opkey: challenges automating SAP Fiori apps
• Automators.ai: SAP Fiori testing, a practical guide
• SAP Help: Using App Variants
• SAP Community: choosing the best test automation for your Fiori app
• OpenText Community: UFT One and SAP Fiori setup
• OpenText: accelerating Fiori testing with UFT AI
• OpenText UFT One for SAP Solutions datasheet
• SAP-docs GitHub: SAPUI5 testing overview
• GitHub: ui5-community/wdi5
• GitHub: SAP/ui5-uiveri5 README (archived)
• SAP Community: Horizon theme now generally available
• SAP Community: removal of Belize theme
• sahipro.com: Worksoft vs Sahi Pro for SAP and Teamcenter testing (source for its exact Fiori framing, quoted above)
• Sahi Pro proof points: internal, per Sahi Pro brand and positioning documentation (90% regression savings, 80% maintenance reduction, company-wide figures)