Flows

flows could simply be viewed as a bucket containing multiple docid\ xsd0meic4aadzddtkedsy 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 additional options we get to modify a flow edit flow ttls 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 application report 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 docid\ xf0u527lduktlb9ys 4zw 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 docid\ jbnpso4 vmjzos6z mb5r the output report is a pdf file in the tab 'application report' within the application details otp verification 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 hide logout button 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 disable device back button 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 location check configuration 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 docid 46h2m9xghwpmrtuxmfcn5 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 configure handoff button text this option helps to configure the text that appears on the docid 07w9kmycu35nw mczxxw button it can be modified by simply entering the text to be displayed in the docid\ l 2puiqmrkb4l w2 7dt and clicking on the 'save' button configure priority mapping 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 docid 2doincdlsv06dyk3jlbvu 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 settings for existing flow kra configuration 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 docid\ yo1w5m 2yyytuqhdnkenq duplicate flow 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 delete 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 distributor assignments 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 download push merchant api specs this option helps to download the json file for push merchant api specs download distributor push merchant api specs this option helps to download json file for the distributor push merchant api specs backops custom tabs 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 curl location globoff 'https //{{frontenddomain}}/api/custom merchant data?userid={{userid}}\&tabid={{tabid}}' \\ \ header 'authorization eyjhbgcioijiuzi1niisinr5cci6ikpxvcj9 eyj1c2vyswqioii1zge0y2fjztk2ywq1yja5y2jmotfmnwyilcjhchbsawnhdglvbklkijoinwqyyzk2m2iyngmznmyyyzrlzjvmmzc1iiwiawf0ijoxnjk4mji2mzc3lcjlehaioje2otk0mzu5nzd9 pcidjkgudntheyntfvzpjz90xhxreqivx6s48jxxfiq' \\ \ header 'content type application/json' \\ \ data '{ "response" {} }' 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