Flows
Flows could simply be viewed as a bucket containing multiple pages๏ปฟ that are used during an onboarding process, or it is a collection of multiple pages that the onboarding merchant will be going through during their onboarding journey.
The flow created will appear under 'My Flows' at the bottom. Later on, we can even add or remove pages in the flow by simply clicking on the 'Edit' button and then checking or unchecking the pages to be added or removed, as shown in the GIF above.
It is used to define TTL (time to live) for URLs generated for onboarding. It can be of different types- Flow TTL, Draft TTL, DIY TTL, and Merchant Session Timeout.
- Flow TTL: To define TTL(in days) for the Auto Login URL of the main flow.
- Draft TTL: To define TTL(in days)ย for Auto Login URLs of the drafted application(calculated from the time of application draft).
- DIY TTL: To define TTL(in days) for the Auto Login URL of the RM to DIY flow URL.
- Merchant Session timeout: To define the time duration(in minutes) post which the merchant session is timed out.
- Restrict Multi Session for Merchant: Enabling this toggle restricts the merchant from having multiple browser sessions.
This feature is used to generate a report of the onboarding application in a PDF format. This PDF generated is not visible to the front-end onboarding user and is displayed in backops under the 'Application Report'๏ปฟ tab for the checker to review.
An HTML template can be used to configure an application report. It may be seen in the back office on the 'Application Report' page. The result is a PDF that includes all the application information that was mapped out in the HTML template.
Any detail from the front-end(including file uploads) journey can be populated within the application report. The report expects an HTML format file as a template with variable mapping from the front end. The template needs to be uploaded in the 'Flow' settings in GO Admin๏ปฟ. The output report is a PDF file in the tab 'Application Report' within the application details.
This is where OTP-based merchant authentication parameters are defined.
If enabled, the system will request OTP authentication using the mobile phone/email specified in the setup merchant API each time the auto login URL is clicked before continuing the onboarding procedure.
- Verify by mobile: This enables the verification of the mobile number by sending an OTP to the userโs mobile.
- Verify by email: This enables the verification of the Email ID by sending an OTP to the userโs email.
- Mask phone number/email?: This toggle enables the masking of the email ID/phone number in the OTP verification stage, which was entered/provided during the initial stages of the onboarding journey.
- Call third party API: The following details need to be filled out which will be provided by the third party to use their OTP services.
- OTP Request URL: The URL that triggers the 3rd party API for OTP is entered here.
- OTP Verification URL: After entering the OTP, the URL used for verification is entered in this field.
- Channel Name: The name of the channel through which OTP is sent.
- Job Subject: The purpose of sending the OTP can be configured from here.
- Message Body: The message body while sending the OTP could be configured from here.
- Header Text: The text that will appear as the header of the page during the OTP verification is entered here.
- Subheader Text: The text that will appear as the header of the page during the OTP verification is entered here.
- Generation Failure Message: The message that will appear in case the OTP generation fails.
- Verification Failure Message: The message that will appear in case the OTP verification fails.
- Resend Button Text: The text that will appear in the button that will be used to resend the OTP.
- Configure OTP waiting time in seconds: The time up to which the OTP can be entered in the specified box during verification is configured here.
This is used to hide the logout button that is usually visible in the top right corner of the page in a flow. By ticking the checkbox, the logout button can be hidden from the screen if required.
This helps to disable the back button on the device during the onboarding journey. This can be done by checking the 'Disable Device's Back Button For the Journey' checkbox and then clicking on the ' Save' button.
This option helps to configure the location check for accessing the flow. On turning on the 'Enable Location Access' toggle, the location of the onboarding customer can be accessed. We can select the parameter for location check from the drop-down menu, viz, country, state, city, and PIN code.ย
It can also be selected whether the location selected is whitelisted or blacklisted from the radio buttons. The whitelisted locations are the ones from where the flow can be accessed and the blacklisted locations are the ones from where the flow cannot be accessed. An Excel sheet containing the details of the location has to be uploaded. A sample sheet is also present that can be downloaded for reference.
Configure Assignment Strategy๏ปฟ
This option helps to configure the assignment strategy for the back office portal. The assignment strategy can be chosen from the dropdown, viz, Fields, Round robin, and Random. If the strategy is selected as 'Fields', then the 'Assignment Strategy values' and 'Secondary Assignment Strategy', viz, Random and Round robin, also have to be selected.
In the assignment strategy values, field value(s) for back office users based on which applications will be characterized(eg, branch, skill, etc.) is entered. The 'Enable bucket size' toggle helps to configure the bucket size of the user. Bucket size refers to the maximum number of applications that are permissible in the queue for a particular backops user.
This option helps to configure the text that appears on the Handoff๏ปฟ button. It can be modified by simply entering the text to be displayed in the textbox๏ปฟ and clicking on the 'Save' button.
The applications that are marked as priority appear on the top of the application queue and the application bucket. Banks and financial institutions often receive applications from high-value customers who require prompt service. Some applications may not meet rule-based criteria but require urgent processing due to exceptional circumstances.
The application can be flagged as a priority in two ways:
- Intelligent/automatic marking: Banks and financial institutions often receive applications from high-value customers who require prompt service. These types of applications are automatically flagged as a priority based on rule-based criteria based on certain logical conditions. These applications are shown with a red colored flag beside them.
- Manual marking: Some applications may not meet rule-based criteria but require urgent processing due to exceptional circumstances. These applications are marked as priority manually on Back Office Portal๏ปฟ. These applications are shown with a yellow colored flag beside them.
The configuration for rule based/automatic marking can be done from the 'Configure Priority Mapping' option.
Configuration:
- Turn on the 'Enable Priority Flagging' togggle.
- Select the page from where the details will be picked up for setting the rules for priority flagging.
- Select the variable from the selected page.
- Select the operator. (Currently only 'equal' can be used as the operator
- Enter the value that, when equal to the selected variable on the specified page, will mark the application as a priority.
Note:
- Only pending and all applications buckets will have priority flagged.
- Application with priority flag will be sorted and shown on top followed by recent onboarding date applications.
- Applications flagged by rules are prioritized over manually flagged applications in the queue.
This option is used to hand off the flow to the client so that they can use the flow and make changes accordingly. Once the bank registers with the KRA, They will get the details such as username, password, grant details, etc. The employee details viz Name and Designation can be added. The Grant details can also be configured.
- Username: Provided by the bank after registering withย KRA.
- Password: Provided by the bank after registering withย KRA.
- Email: The email of the employee to which the bank(s) want to send the handoff information through mail.
- Employee Details: All the fields under employee details are entered with the information provided by the bank.
- Grant Details: The fields under grant details will be filled with the data provided by the bank.
Refer to this for more details on how to configure KRA from flows: Configuring KRA from Flows๏ปฟ๏ปฟ
This option creates a duplicate of the flow. This is helpful when a similar flow has to be created with/without minor changes. This saves the time and effort of creating a new flow from scratch.
We can delete an existing flow by clicking on the Delete option. A pop-up message asking if we want to delete the flow or not appears for confirmation.
This option helps to assign a distributor to the flow. This distributor can access the flow and can use it according to their requirements. This can be done by clicking on 'Assign Distributor' and selecting the distributor from the dropdown menu.
This option helps to download the JSON file for Push Merchant API Specs
This option helps to download JSON file for the Distributor Push Merchant API Specs
This option streamlines the data and personalizes the Backops portal by customizing tabs according to requirements. Multiple tabs allow neatly segregating data from various APIs. Data posted through the integration tab is available across all merchant data sources such as pull merchant API, to access crucial information.
MIS reporting also becomes even more powerful with real-time access to integrated data, ensuring the generation of insightful reports quickly and accurately.
Configuration:
- Create your tab from the flow settings through admin. Copy the tab ID
- Post the data you want to post on that particular tab created using the below curl along with the unique tab ID generated using admin. Currently, data can be posted to a particular tab only one time and the user will not be able to repost or update the data.ย
Note: The response key has been made mandatory inside the request body.ย The value of the response key should always be in JSON format only.
Data posted on Backops will be visible in the following format
- For an array:
- For a nested object:
Getting help
Please feel free to contact us if you have any questions, require clarification, or have ideas for how to make the documents or any of our services better.
You can reach out to us at [email protected].
๏ปฟ