Intro
The SAP Fiori onboarding pattern provides a consistent, native-first user experience, allowing users to set up their account and get the app running. It features a sequence of optional, configurable flows that support custom pages, along with individual page patterns available within the SDK. The flows and sub flows can vary depending on the configuration of the app by the admin or the IT department in terms of data sensitivity, security level, and number of users.
Single-user onboarding process flow
Usage
Do
- Use the single-user onboarding flow to:
- Streamline the user activation and onboarding process.
- Simplify the security framework of your company.
Don't
Don’t use the single-user onboarding flow if there are several users sharing one device; use multi-user onboarding instead.
- Send a welcome email to users, providing short and clear instructions about the onboarding process.
- Add visual cues to the welcome email to help users navigate faster.
- Welcome users with an element of excitement for the experience ahead.
- Keep the entire onboarding process as simple as possible and use clear language.
- Don’t repeat the onboarding flow after the user has completed the process for the first time.
- Don’t skip the onboarding flow for first-time logins.
- Avoid asking the user for multiple permission requests, such as camera access, notifications, settings, etc., during the onboarding process unless it’s absolutely necessary.
Variations
First-Time User Onboarding Flow
The onboarding flow for first-time users checks different elements of your security, IT, or legal requirements and displays required flows to users.
It includes semi-configurable subflows, also known as ‘steps’ in the technical docs, and individual sample pages. However, you can add custom pages to meet your security requirements.
First-time onboarding flow from left to right: launch (optional), activation, authentication, passcode creation (optional), permissions (optional), and then use app
Installation
A user's initial interaction with the app that is formally not part of the onboarding flow begins with either an email notification about the app's availability and instructions to download it, or the app may be already pre-installed on the company device.
Launch
Splash Screen (Guideline Only)
The splash screen is the first branded screen users encounter after the system-controlled launch screen, which appears briefly during startup and is not part of the onboarding process. As the app’s first interactive surface, the splash screen serves as the entry point into the onboarding experience.
In SAP applications, it is generally kept minimal, typically showing only a centered logo to create a smooth transition from the launch screen while avoiding unnecessary delays. Apple encourages apps to move quickly into meaningful content, so the splash screen should remain lightweight unless a short delay is needed while the app gets ready.
Splash screen example
Welcome Screen
Welcome screen (left) and optional demo (right)
Types of Welcome Screens
Variations of the welcome screen support the different services that can be used to onboard a user. Additionally, you can now insert subflows between steps/screens by linking the main call-to-action button on the welcome screen to open a desired custom page or subflow. If the developer is already aware of the supported backend setup, any of the appropriate variations below can be utilized.
- Mobile Device Management (MDM) and Hardcoded: MDM is a push model, so the onboarding data is just pushed to the app and the data is made available. Hardcoded requires the developer to include the onboarding data into the compiled app. In both cases, the user can onboard by signing on the Cloud Identity Services login screen directly from the launch screen.
- Activation Link: An activation link, generally provided in the welcome email, is required to start the activation process.
- Discovery Service: The user is required to enter their corporate email address on this variation of the launch screen which the Discovery Service then uses to make the right backend connection.
- QR Code Scanner: The user must be provided with a QR code to scan that is required to start the activation process.
If a standard app is getting shipped via the App store, the following option with all variants of onboarding should be used:
Standard App Store: The user can onboard on the activation screen as the app has no way of knowing which onboarding variant is supported by the customer.
Different variations of the welcome screen Configurations for Welcome Screens
The welcome screen also supports additional configurations for further customization.
- Top Image: An image placed on the header area that is generally used for application logos.
- Bottom image: This image is placed in the footer area and is generally used to add secondary logos, such as parent companies or affiliates.
- User Legal Agreements: In proprietary software, an end user license agreement (EULA) or software license agreement is the contract between the licensor and purchaser, establishing the purchaser’s right to use the software. To move forward in the onboarding process, users must agree to the contracts. This area lists out the hyperlinks to the legal terms that users must agree to before proceeding to the app. Users must check the checkbox to continue with the app. The terms of service are also surfaced here for the user to view if they wanted to.
Different configurations for welcome screens
Activation
Default activation methods (optional)
Discovery Service Activation Method
The Discovery Service connects users to the right system landscape when first using the app by automatically determining the tenant based on the information provided by the user, such as an email domain or onboarding code.
This step is part of the onboarding flow but only appears if your environment requires this activation method.
Discovery Service activation method (active state example)
Custom page for QR code activation
Authentication
Authentication is the only mandatory step in the onboarding flow, facilitated through your identification management technology (identity provider). Based on your security requirements and the device used to start the onboarding, this subflow might be launched within the app or in an external browser.
Basic Authentication
Basic authentication screen (default state)
Passcode Creation (Optional)
If your app’s security protocol requires users to create an app passcode to lock access to the app, you can include the “Create Passcode” subflow as part of the first-time onboarding process. This step ensures that users define a passcode that complies with the security standards set by the administrator or IT department.
If a passcode is not required, a “Skip Passcode” variant of the “Create Passcode” screen is available. This allows users to bypass local passcode creation when adequate protection is already ensured through device-level or MDM-enforced security.
Passcode creation screen with passcode required (left) and passcode creation screen with passcode optional (right)
Biometric Authentication
Biometric authentication
Permissions (Optional)
EULA and Other User Consent Agreements
An End User License Agreement (EULA) is a legal contract between a software application author or publisher and the user of that application. Depending on legal requirements and region, a EULA can be added to the onboarding process.
The default EULA screen is included in the onboarding flow, with variations available as individual page types.
You can also use consent forms that enable the capturing consent on data privacy and app-related services such as location sharing and voice permissions, all of which use the consent form pattern.
Different permission screens
Returning User Onboarding Flow
The onboarding flow identifies returning users and launches relevant flows by verifying security measures.
Passcode Change (Optional)
The “Change Passcode” flow is part of the returning user experience and allows users to update or remove their existing app passcode after onboarding. It includes screens for verifying the current passcode and setting or confirming a new one in accordance with the security policies defined by the administrator or IT department.
By default, this flow is automatically triggered by the Onboarding Flow SDK whenever there is a change in the app’s security policy. This includes any adjustments such as enabling “Skip Passcode”, modifying passcode complexity, or updating the required number of characters. In these cases, existing users will be guided through the flow the next time they open the app. Applications should provide additional context to help users understand why they are being asked to update their passcode again.
In addition to being automatically triggered, the “Change Passcode” flow can also be invoked manually. Developers can launch it through provided APIs and surface it within a custom “Settings” or “Security” screen, allowing users to change or remove their passcode at any time. Embedding passcode management in settings also provides a more natural placement for security-related tasks and allows teams to include messaging tailored to their specific policies or compliance needs.
“Change Passcode” screen with passcode required (left) and “Change Passcode” screen with passcode optional (right)
Custom User Onboarding Flow
With Write Your Own Flow, you can create a custom flow using individual page types included in SAP BTP SDK for Android or other SAP Fiori for Android components.
Behavior and Interaction
Onboarding is designed to be a modular process to provide flexibility in terms of setting it up as per the app’s requirement.
The various views in onboarding are designed to be modal windows to give users a way to exit the onboarding process at any time.
Once the user takes an action on a view to proceed further, the next view in the process is presented. Include a blank white screen as a layer above the launch screen when these modular transitions take place. Once the entire onboarding process is complete, the launch screen transitions into the Home screen of the app.
Adaptive Design
In general, the onboarding screens can adapt their widths to fit various iOS device sizes.
The welcome screens for single user onboarding are only available in portrait mode for compact screens; however, on regular screens they support both portrait and landscape layouts.
End user license agreement on compact screen (left) and expanded screen (right)
Resources
Development: Onboarding patterns, FUIWelcomeScreen
SAP Fiori for Android: Onboarding
Related Components/Patterns: Basic Authentication, Consent Forms, Biometric Authentication, QR Code Scanner