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

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 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

Welcome Screen

The welcome screen serves to set the overall tone of the app while also succinctly presenting major information and features to the user. It provides key actions for users to start interacting with the app, including agreeing to legal terms, trying out demo mode, and continuing to the application setup.

Welcome screen (left) and example for an 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 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

Different configurations for welcome screens

Activation (Optional)

The activation subflow is designed to identify your company’s domain and connect the mobile app to the correct system landscape. This process can differ based on security requirements and the type of devices users utilize for onboarding, such as corporate or personal phones. For example, if a user is on a corporate device managed by mobile device management (MDM), the flow automatically detects the enrolled device and bypasses several steps of the onboarding process.

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)

QR code scanning is an activation method used to advance users to the next onboarding flow step by scanning an existing QR code. We recommend providing instructions on where to locate the QR code, using a custom page with an image and the breadcrumbs of the file location.

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 is a login method included in the onboarding flow that enables users to log in using an email address and password.

Basic authentication screen (default state)

Biometric Authentication

Biometric authentication methods such as fingerprint scanning and facial recognition are available based on users’ device capabilities. These features are integrated from the native iOS system, ensuring the authentication dialog adheres to system standards.

Biometric authentication

Passcode Creation (Optional)

If your app’s security protocol requires an app passcode for users to be able to lock access to the app, you can add a “Create Passcode” subflow for first-time user onboarding, where users must create a passcode that adheres to predefined security standards.

Passcode creation screen

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

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

Detailed User Flow

CCSL Mobile Compliance Resources Library