Skip to main content
Smart UI can be configured to pre-fill an applicant’s personal information. There are two main use-cases for this:
  1. The user is a returning user who previously abandoned the Smart UI onboarding flow and you don’t wish them to enter their details again.
  2. You are using Smart UI to verify personal information that you have already captured through your own interface.
Any required information defined by the configuration, if missing, will be requested from the user before they can save and verify their details.

​
Identify the customer

When initializing Smart UI, specify an identifier so Smart UI can retrieve the applicant’s details from FrankieOne. The identifier may be an applicant reference, also known as a customer reference. Typically you would specify an applicant reference, which is defined by your system and represents your own internal identification for that applicant. The example below initializes Smart UI using an applicant reference:
JavaScript
frankieFinancial.initialiseOnboardingWidget({
	applicantReference: string,
  ...
})
Note
When the applicant isn’t found, the request returns an HTTP response of 404 Not Found, which might log a network error on the console, but that response is expected and can be ignored.

​
Capture personal information using your own interface

If your own interface already captures personal information, you can use the Create Entity API to save those details without checking them. The API response will return the entity’s ID, which you can use to initialize Smart UI with. The example below initializes Smart UI using an Entity ID:
JavaScript
frankieFinancial.initialiseOnboardingWidget({
  entityId: 'ENTITY_ID',
  ...
});

​
Preloading recipes/check profile

The Smart UI will always force checks to be run under the configured checkProfile. Even when an applicant is preloaded with a recipe “A”, if the Smart UI is configured with checkProfile “B”, “B” will be used. The one exception to this is if the Smart UI is configured with checkProfile “auto” and the preloaded applicant already uses the recipe “C”, then “C” will be used. The following is a table with the different scenarios for preloading recipes, demonstrating the “configured” value, “preloaded” value, and the resulting value that will be “used”:
ConfiguredPreloadedUsed
”A""B""A"
"auto” OR
Missing configuration		”B""B"
"A""auto""A"
"auto""auto""auto”
In the last scenario, “auto” will be used, which means the service will make a educated decision on which of the available recipes to use, based on the context of the applicant.