Creating a Functional Flow
Who creates functional flows?
The implementer is in charge of creating functional flows in Studio.
Where do you work?
You must access your Studio environment and work using modules created for the project.
This article includes how-to guides that explain how to solve specific use cases that may occur during the functional flow setup and building process. It includes several cases:
If you have functional flows defined and you must create and configure them in Studio. Read the documentation available to learn more about functional flows creation.
If you need to define errors that will be triggered in the module that contains the functional flow or in the parent app. To read about errors in the app, read Settings. To read about errors in the module, read Create or Edit a Module.
If you need to configure the functional flow and the app's site parameters. To learn more about these parameters, read Site Parameters.
If you already created the flow, invoked it from the parent app and now you want to test it. Read Test an App to learn more about the testing process and Branching to learn about app versioning.
Setup
Note
This use case applies to both web and mobile apps.
Each Studio environment comes with a set of predefined errors that invoke lambda processes with specific tokens that trigger different messages. When an error occurs in the app, the user sees a modal with a specific message that varies according to the token invoked, and a specific action triggers when that modal is closed.
To handle errors in the module and the parent app, specific entities must be configured in the module, replicating the app configuration. This varies according to the app channel.
In the case of a web app, the module must contain:
A local error modal in a common hidden area. To learn more, read design system standards.
A lambda process per error type that invokes a local screen to show the error and executes the following lambda process to redirect the user.
In the case of a mobile app, the module must contain:
A local error modal through the use of system pop-up component in a local screen.
A lambda process per error type that invokes a local screen to show the error and executes the following lambda process to redirect the user.
Note
This use case applies to both web and mobile apps.
To use deeplinks, onfigure the following at the module and the app level:
In the module:
Duplicate the generic token launch site parameter, as well as the screen with the processing view and the redirecting lambda process.
Edit the lambda process so that it invokes the parent app with the token information in its message, to then execute the lambda process that redirects the user.
In the parent app:
Execute the lambda process that redirects the user.
Note
The generic token launch parameter is a token number that contains the information obtained when the user clicks on a deeplink. Configuring the generic token launch allows the mapping of tokens through labels that act as parameters externally invoked to redirect the user upon the deeplink.
To manage the binary or configuration download, the app behavior must be replicated in the module. You must configure the following:
In the app's local error handling, define the behavior for downloading the configuration and redirecting to the app store when a binary update is required.
In the module, the lambda process that handles local errors redirects the user to the app and closes the module. As a result, the lambda process that handles local errors in the parent app receives the message and completes the flow.
Note
This use case applies to mobile apps only.
To set a session timeout, you must configure the specific logic in the module so that the user is redirected to a specific app screen when a session timeout occurs. The following must be configured in the module and the app, respectively:
In the module:
Duplicate the session closure site parameter. As a result:
the lambda process that executes the session closure site parameter closes the module and sends a message to the parent app to execute the action defined.
the lambda process that executes the site parameter defines a different behavior for Android devices, which makes it possible to execute the lambda process in the parent app without triggering a message.
In the app: the lambda process redirects the user to the screen specified.
Note
The session timeout parameter makes it possible to manage time (in seconds) to close the app session due to inactivity, and the next on session timeout defines the lambda process to be executed if the session closes due to inactivity.
Building
Functional flows are created through interfaces of modules. Therefore, naming conventions must be complied with throughout the module creation process. Follow these conventions as specified below:
Module name: If the module represents a functional flow, the name must include the expression Flow + the functionality of such flow. Use capital letters to start all words and separate them using underscores.
Interface name: The name is defined by the functionality represented by the flow. Use snake_case and divide words using underscores.
To learn more about naming, read Naming Conventions. In addition, read Create or Edit a Module to follow best practices in the creation of a functional flow.
Note
This use case applies to both web and mobile apps.
The generation process cannot be completed if the app has dependencies that are linked to the same entities in different versions (branches). For example, the Veribank app is linked to Module A in branch Main and Module B in branch Test; in addition, Module A is linked to Module B in branch Develop. Since theVeribank app and the module A are linked to Module B in different branches, it won't be possible to generate the app.
Tip
Check cross dependencies between apps and modules in the Dependencies diagram of the app.
To successfully generate and publish the app, you must perform one of the following three actions, depending on your project.
If the changes made to the branch do not require the information from the module linked as a dependency in a branch different than the branch linked to the app: you can unlink that module as a dependency, so that only the app is linked to the module and no cross dependencies issues occur.
Change the branch to which the module is linked. As a result, both the app and the module will be linked to another module in the same branch and no cross dependencies issues will occur.
Review the dependencies of the module branch (that is, the module linked to the parent app) and create branches to all its dependencies.
Important
You must create new branches for all the parent app's dependencies, even if no changes will be made to them.
Note
This use case applies to web apps.
If the classes defined by default in web apps have the same key name defined in the theme, the values defined in the theme are randomly overwritten. It is necessary to change the name of seven classes in the generic app theme so that they do not affect the classes defined by default.
If under project requirements you are creating the module and are instructed to apply a theme to it, you must understand how themes are applied and how they work with regard to the parent app.
App screens inherit the theme defined in the app, view or module in the following order of hierarchy: view, module and app. This means that: an app screen inherits the theme applied to the view in which it is included. If no theme is applied, it inherits the module theme. Lastly, if no theme is applied to the module, it inherits the app theme.
As a use standard, modules must not have themes applied so that they inherit the parent app's theme. Under specific business cases, you may need to apply a specific theme to the functional flow you are invoking - for example, if a specific section within the app is sponsored and requires the use of different colors. To do this, you must execute different actions depending on the app channel involved.
For mobile apps:
Go to the Dashboard and then click Modules to access the module (and branch, if applicable) that contains the functional flow.
Go to the Menu
and, in the Design section, click Views.
Find the view that contains the functional flow screens and click Edit (pencil icon).
Go to the Theme field and select the theme you need to apply.
Click Save.
For web apps:
Go to the Dashboard and then click Modules to access the module (and branch, if applicable) that contains the functional flow.
Click Settings.
Go to the Theme field and, in the Theme info section, select the theme you need to apply.
Note
You must set a theme to the module, even if it is the same theme applied to the app.
Click Save.
Note
For themes, you must comply with definitions made during the Design System stage.
Functional flows are created through interfaces of modules. Then, they are invoked from a component in a parent app's screen.
After you invoke it, you must always close it. Closing the functional flow - that is to say, the module that includes it, is key to the user experience. Closing the flow implies that it does not appear in the app screen and is removed from the navigation stack.
As use standard, the On Next tab must not be used to close the functional flow. Instead, you must configure the flow closure in the module. To do so, you must : a set of Message parameters. These messages will be then invoked from components in the app screen, which will then execute a specific action in turn. The messages you can configure are listed below:
Configure a set of Message parameters in the functional flow interface. The list of standard messages represent in which cases you define the flow closure - and therefore, the redirection of the user to a different screen. The messages are:
Onsuccess
Oncancel
Onback
Ontrxfail
Onlocalfail
Configure a lambda process with two blocks:
one block with the message you need; and
one block that is executed when the message occurs and defines that the module must be closed.
To learn how to use lambda processes, read Lambda Processes.
Invoke the flow from the app screen and define the lambda process applicable to the message invoked. This is configured in the Link to Module modal that appears upon invoking the flow. To learn how to invoke a functional flow and configure it, read the documentation available.
To learn more about Message and other parameters in the interface of a functional flow, read Create or edit a Module and Interfaces.