Approaches for Start and Resume Journey for User Onboarding to Platform (Part I)

5 min readMar 20, 2022

Use cases like start and resume journey are pretty common for applications where onboarding of new users to their platform is required before allowing them to access services. For example, if you want to use AWS then you need to create one account which will be used for billing and allow you to access services offered by AWS services.

Another example could be, say you want to invest in some stocks/crypto again you are required to onboard to broker platform or on exchange platform before making any investment or trade. They require us to perform some steps like KYC, document upload, personal details sharing, bank account setup, nominee declaration and there can be many more steps.

As we can see, onboarding journeys can become long and if we don’t handle this flow properly then users might not visit again and may delay or move to another platform.

So, now we understand the importance of onboarding and what will be the cost if not designed properly. Here we need to understand that most of the time the user wishes to onboard quickly and start using services. But let’s say if for some reason the user drops from the onboarding journey in between and later tries to continue and then he sees that he needs to restart the journey, do you think he will be happy to continue? Sometimes the user might not and sometimes he might and yes there is a good risk that the user might leave your platform and go for another platform to get the services.

Common use cases:

Let’s list some of the common use cases for start and resume application during onboarding:

Drop user from KYC verification page if identity proof is not clear and ask to reupload and continue from there.
Allow user to navigate between steps like going back to the previous step for correction.
If KYC verification failed then reject the application.

In this article, let’s discuss some of the approaches that can be used to allow the user to continue from where he left off.

Approach 1:

Create separate Tables(SQL)/collections(No-SQL) in the database for each step and update those tables/collections as users proceed with the journey. For each step completed, we will save the data provided by the user into the respective tables/collections like Personal details table, KYC Verification table, etc. There will be another table/collection that will hold the metadata details related to the onboarding process like In Progress, Not started, Completed, and Rejected.

Here when the user starts the onboarding process, the application will first make a call to a Table/collection which holds details for the onboarding application process and will provide the status of the application.

If the user is starting the process for the first time, then he will have status as Not started and the application will ask for details from each step, and as step gets completed that details will be saved to the respective table/collection in the database.

If the user has dropped the Journey in between then status will be in progress and then applications need to make a call to individual table/collection to find out the last unfilled table against that application number.

If the user has completed the onboarding process, then the status will be completed and the user will be shown a different page/portal which allows access to the services.

If the user has been rejected then the status will be rejected or terminated and accordingly drop or error page will be shown.

For resume journey, the application will query to each table/collection and based on that continue the flow from last stopped on the incomplete step.

What are the advantages?

Data is well organized.
To find the next step that the user needs to perform, simply check the last unfilled table/collection in the steps and identify the step and resume that journey.
If the user drops in between, we can always check the last table filled and resume after that.
Steps can be arranged in any order.

Ok, What are the disadvantages?

The database is getting flooded with more tables/collections.
If in the future more steps are added or removed then we have to accordingly update/remove the table from the database.
More network call is happening for a single application which is bad for the database.
For rejected applications, we might need to create another table/collection which is another additional network call for the application.
Even if the application got rejected in between it may have to update other tables/collections associated with those steps.
To resume the user journey, It needs to check each step from the start and based on that it will come to know the last incomplete step which means more database call to just know that last step.
In some cases, Effort is more for simple changes to the application like in-app code, database, etc.
Code sharing with other applications in some cases will be less.
Journey resetting is a costly operation.

When should I pick this approach?

This approach is straight forward and to some extent, it looks easy to understand, but the cost to maintain and make changes is more. Hence, even though this approach is doable, but not recommended for application which has huge traffic.

I mentioned this approach because I have seen this kind of application but this design strategy doesn’t help in this case instead of increasing complexity.

Approach 2:

Approach 1 can be further enhanced, instead of creating a separate table for each step, we can have only one document per user in the collection using a No-SQL database. Here, all details can be stored in a single collection, one network call is required to fetch the application state and the next step for the user to continue.

What are the advantages?

A single collection is enough.
To find the next step to continue, one field can be created to track the current step.
Same as approach 1.

What are the disadvantages?

Collection may become bulky with time.
More data is transmitted in a single network call.
Resetting the journey might be tricky, and, implementation-wise, the application may get complex.

This article is continued in Part 2, for further reading refer below,