Structure and Organization
Even though logic construction is done through a visual editor, it requires following structured criteria to ensure clarity and maintainability. This section proposes a basic structure and outlines best practices that support consistent development across projects and teams, reducing the likelihood of errors and facilitating collaborative work.
As not all logic requires the same level of structuring, it is important to adapt the approach according to its volume and complexity. For simple and limited processes, a linear flow without variables or helper functions may be sufficient. This is common in logic aimed at modifying screen component behavior (presentation logic). For medium or complex processes, it is necessary to organize logic into specific functions and avoid hard-to-read structures with deep nesting. The best practices detailed below are mainly oriented to this type of processes.
Simplicity: For simple, low-volume processes, keep the logic linear and concentrated within the main statement. Avoid overengineering.
Modularity based on complexity: As logic grows and incorporates decisions, validations or branches, you should structure it through functions.
Reuse: Extract repeated validations or calculations into functions to reuse them in any other part of the process.
Use of variables for internal data handling: Avoid unnecessary tokens. Tokens are mainly intended for exchanging information with other entities, transactions, or call APIs. For internal processing, use lambda variables.
Prevention of unexpected side effects: Make sure that functions do not cause unexpected side effects. This happens when a function implicitly modifies global or external data in a way that is not evident from its definition.
Organizing the process into clear sections helps ensure understanding and maintenance. The following structure serves as a general guide and can be adapted depending on the process complexity. It may or may not include every component listed below, but following this order supports consistency across projects. The following structure encapsulates the different parts of the logic into specific functions:
Variable and structure initialization: Prepare the variables needed for the process. If the process receives information through input tokens, assign them to local variables at this stage. Function name: initVariables()
Initial validations and transformations: Check preconditions, validate input data, and perform initial transformations or calculations. Function name: validateInput()
External invocations (Transactions and call APIs): Encapsulate each external call in a separate function that includes its own error handling. This improves the readability of the main flow, reduces the visual noise of large blocks such as transaction blocks, and makes it easier to test specific parts of the process.
Response and output tokens definition: At the end of the process, prepare the output data and assign it to the output tokens, if applicable. Function name: setResponse()
The on start block should include the process main logic, this is, the logic that represents the main purpose of the process, and perform the calls for the functions described above. This structure supports clear sequential execution and allows the on start block to act as the orchestrator of auxiliary functions, keeping the visual logic organized and predictable.
While structuring logic into functions is a best practice, an excessive use can be counterproductive. On the one hand, unnecessarily breaking down the logic may hinder overall understanding. On the other hand, it is best to avoid meaningless chains of functions —such as an on start block that simply calls a function, which then calls another one, and so on. These structures add no real value and make the main flow harder to follow. Striking a balance between clarity and modularity is key to building logic that is both maintainable and easy to understand.
Currently, lambda processes do not have a strict size limit, but the following guidelines must be followed to ensure clarity and maintainability:
Avoid excessively long processes (over 250 blocks), as they become hard to follow and prone to errors.
In complex processes, divide the logic into subprocesses to improve maintainability.
Avoid over-fragmenting logic into functions without a clear reason. Having more than 10 functions in a moderately complex logic might be a sign of overengineering.
Lambda processes do not receive explicit parameters; they share information with other entities through tokens instead. Using the model structure presented above should allow you to clearly define input and output data. Otherwise, it is advisable to use comments to explicitly document which tokens the process expects and modifies.