SaFi Bank Space : Decision: Onboarding flow orchestration

Status	IN PROGRESS
Impact	MEDIUM
Driver	Juraj Macháč (Unlicensed)
Approver
Contributors
Informed
Due date
Resources

Background

The onboarding process is a process which guides customer through the data collection process. It has multiple steps which are in high-level described in https://safibank.atlassian.net/wiki/pages/resumedraft.action?draftId=4522346 .

The business owners would like to:

monitor the process
- identify drop-offs
- investigate potential issues with a process related to a specific customer
be able to change the process
- modifications to the screen flow are expected as means of customer conversion rate optimization
- change in rules (how often & how many times an OTP can be re-sent, what are thresholds for compliance rules to get approved onboarding)

There are multiple ways how to orchestrate the screen flow of onboarding process. Multiple different layers of abstraction. In the next section we’ll briefly explain some of those considered.

The provided diagrams strive to show the workflow definition with commands and expectation the workflow goes through. It uses the following naming:

“EXPECT - XYZ“ - Await a specific signal sending the XYZ to the workflow
“SHOW - XYZ” - Instruct App to show the screen XYZ. The screen shown is also persisted within the workflow and can be queried at any time.

Hard-coded within the App

The App has the screen flow hard-coded. There is no notion about a “workflow” in the backend during the screen flow, every piece of data is saved to the Customer record during the flow in order which the App chooses. Eventually, the customer-manager (BE) validates whether customer record contains all mandatory fields before submitting the customer and initiating the onboarding decision workflow.

Full orchestration by workflow

For (almost) every screen, the FE awaits to be instructed by the workflow to show it. The logic of the onboarding screen flow resides completely in the workflow definition. The App only deals with individual screens and doesn’t know anything about succession.

Sections orchestrated by workflow

The workflow still maintains the screen flow, but only by sections. The FE can change (some of the) customer data at any time. However, the workflow maintains control over specific parts of the flow and sets expectations on what data should be collected next. In the end, the workflow verifies if the customer contains all of the mandatory data before submitting for compliance & decisioning.

Some parts, such as phone number collection, are not controlled by the screen-flow-workflow, but the app is rather instructed that the phone number should be verified.

Screen flow workflow

Phone number verification sub-flow

The customer can change their contact details at any time as long as they verify the phone number through the workflow.

Options considered

Hard-coded in App

Full orchestration

Orchestration by sections

Description

Screen flow is hard-coded within the app. There is no screen flow defined in the backend.

The app awaits to be instructed by the BE before showing any screen. Screen flow logic is implemented completely in the BE workflow.

The app knows what is expected in each of the sections, but expects to be told by the workflow which section to show.

Pros and cons

Quicker to implement

Flexible for changes from the backend perspective

Going back and forth possible (unless specific rules are enforced in the backend)

Difficult to enforce rules for specific part of the workflow (OTP resend time, number of attempts for ID verification, etc..) while keeping the BE flexible.

Little to no insight on the onboarding progress of a specific customer. Any such insights need to be done by deducting the flow progress from logs, or using a completely different FE tool for analysis (e.g. Google Analytics).
Changes to the flow need to be done by changing the App. Only customers with the latest app version will access the new flow

No possibility to resume the flow after reinstalling the app, or when logging in from a different device.

The above might not be such a problem since this is onboarding and hence one of the first things done after downloading the App.

Complete control over the screen from from the workflow definition perspective.

Complete & configurable control over the business logic & rules in each of the steps

Allows for changes in the flow which are possible to immediately roll to all customers, or even just a subset (canary deployment).

Full insight into flow of the individual customer. Basically to the level of showing a specific screen where the customer finished.

Possible to implement app resume even after app reinstallation (assuming that we collect enough information to login the customer).

Communication heavy. Every response between the screens is asynchronous. Turnaround time for the asynchronous flow needs to be considered.

More difficult to implement from the BE perspective.

Difficult to implement any “back” functionality. Any such needs to be implemented directly in the flow, which makes it much more complicated.

Control over the screen flow of sections.

Control over business rules applied to specific steps.

Allows for changes in the flow which are possible to immediately roll to all customers, or even just a subset (canary deployment).

Some insight into a specific customer application. Which section is the customer stuck in.

Possible to implement app resume back to the beginning of the section

Allows some flexibility in the backend

The communication heavy async flow is limited to be between sections (and phone number collection).

The “back” functionality can be implemented more easily when compared to fully orchestrated flow as it does not have much expectations from the sections.

No single consolidated logic for the whole set of rules applied to onboarding

As the data can be changed even outside of the workflow itself, there is no single track of record for the changes done.

Perhaps this is not a problem if the changes would be in audit log.

Estimated cost

MEDIUM

LARGE