Skip to main content
Blueprints are built from elements that you wire together to define your logic. Each element either controls the execution path or performs an action. You add elements using the element palette that appears at connection points in the diagram. The element palette at a connection point, with one icon per element type Hover over an icon to see the name of the element.

Assignment

The Assignment element performs a calculation or stores a value in a variable. It appears as a blue block on the canvas. The Assignment Start with the requested instalment, setting totalMonthlyPayments to requestedMonthlyPayment An assignment has two parts:
  • Variable name (left of =) — the variable to create or update
  • Expression (right of =) — the value or calculation to assign
Expressions support standard operators (+, -, *, /), variable references, and literal values like numbers or texts.

Decision

The Decision element creates conditional branches in your flow. It evaluates a condition and routes execution down different paths (IF/ELSE). It appears as a yellow block. The Decision No monthly income declared, checking monthlyIncome is 0, in the decision Income needed for the ratio A decision has:
  • Condition — a comparison expression (e.g., monthlyIncome is 0, totalScore >= 65)
  • True path — executes when the condition is true
  • False/Else path — executes when the condition is false

Multiple conditions

You can add multiple condition blocks to handle more complex scenarios. Each condition is evaluated top to bottom — execution follows the first one that is true. The decision Risk band by score with two IF branches for 65 and 35 points and an ELSE branch, each setting the risk category Click Create a condition below your existing conditions to add more. You can also add an Else block that catches anything not handled by previous conditions.
When a rule is really a lookup — several inputs mapping to an outcome — a Decision Table is often clearer than a long chain of conditions. It lays the rules out as a grid you can read at a glance.

Loops

Loops repeat a section of your flow. There are three types:

Loop over Items

Iterates through each item in a list. You specify:
  • What to process — the variable that holds the current item (e.g., loan)
  • From — the list to iterate over (e.g., existingLoans)
  • counter (optional) — tracks the current position (e.g., index)
The loop Count each existing loan over existingLoans, with two assignments inside that add up each loan's monthly payment

Loop with Counter

Repeats a fixed number of times, like a classic for loop. You specify:
  • Variable — the counter with its starting value (e.g., i=0)
  • Condition — when to stop (e.g., i < 10)
  • Step — how the counter changes each iteration (e.g., i=i + 1)

Loop with While Condition

Repeats as long as a condition remains true. You specify:
  • Condition — checked before each iteration (e.g., debtBalance > 0)
The loop exits when the condition becomes false.

Continue and Exit Loop

Inside any loop, two additional elements become available:
  • Continue — skips the rest of the current iteration and moves to the next one. Useful for filtering out items you don’t want to process.
  • Exit Loop — stops the entire loop immediately. Useful for search operations where you can stop once you’ve found what you’re looking for.

Return

The Return element ends your Blueprint successfully and returns the output values. It appears as a green block with a return arrow. The Return element Check complete You can place Return elements anywhere in the flow. When execution reaches a Return, the Blueprint stops and sends the output values back to the caller.

Error

The Return blueprint with an error element stops your Blueprint with an error. It appears as a red block. The error Report the missing income, which raises InvalidApplication with two fields After Fail with, you choose the error type to raise and fill in its fields — at least a message that explains what went wrong. Use it for business rule violations or any situation where the Blueprint cannot produce a sound result. The run stops unless a section on the way out handles the error — see Error Handling.
You don’t need Error elements to check that inputs have the right type, stay within their bounds, or come from a list of allowed values. Leapter checks inputs against their types before the logic runs.

What to do next