Skip to main content
Figranium uses a powerful variable system to make tasks reusable and dynamic. You can reference variables anywhere in a task using the {$varName} syntax, and combine them with JavaScript expressions for complex logic.

​
Variable Syntax

Anywhere in a task (URL, Selectors, Action Values, Scripts), you can reference a variable using the {$varName} syntax. Example:
  • Variable: query = “Figranium”
  • Action: Type into input[name="q"]
  • Value: {$query}
When executed, Figranium replaces {$query} with “Figranium”.

​
Defining Variables

Define default values in the Editor > Variables section.
  • Types: String, Number, Boolean.

​
Variable Types

Global Variables

Defined at the task level and accessible throughout the entire execution. Set defaults in Editor > Variables or pass them at runtime via the API.

Task Variables

Scoped to the current task execution. These include variables you define in the task settings and any values set during execution with the set action.

Loop-Local Variables

Available only inside loop blocks. loop.index, loop.item, loop.text, and loop.html provide context for the current iteration.

Built-in Variables

Figranium provides special variables like {$now} for the current timestamp and block.output for the previous action’s result.

​
Special Variables

Figranium provides several built-in variables:

{$now}

Current ISO timestamp.

block.output

The result of the previous action (e.g., text from a javascript block).

loop.index

The current index in a foreach loop.

loop.item

The current item in a foreach loop.

loop.text

The text content of the current loop item.

loop.html

The HTML content of the current loop item.

​
Dynamic Usage

You can use variables to build complex logic:
  1. URL Templating: https://example.com/search?q={$query}
  2. Selectors: .item[data-id="{$itemId}"]
  3. Scripts: const user = "{$username}";

​
Persistent Variables

The set action allows you to update variables during execution.
  • Action: set
  • Var Name: counter
  • Value: {$counter} + 1 (JavaScript expression)
This value persists for the remainder of the task execution.

​
Handling Sensitive Values

Figranium does not currently mask or redact variable values in execution logs. Any value you Type into an input, pass as a {$variable}, or return from a javascript block can appear in the execution record stored at data/executions.json (or the equivalent PostgreSQL table). Treat that record as sensitive. For passwords, API tokens, and other secrets used in a login flow, we recommend:
1

Don't hard-code secrets as defaults

Default values are saved with the task definition and persist across executions and exports.
2

Pass secrets at runtime

Trigger the task via POST /api/tasks/:id/api with the secret in the variables payload. The value only lives in memory for that run and is not saved back to the task definition. See REST API.
3

Reference the value once

Use {$password} directly in the Type action’s Value field rather than copying it into intermediate set variables or javascript blocks, which increases the surface area where the value can be logged.
4

Rotate execution history

Delete runs that contain secrets from Executions, or purge everything via Settings > Data > Clear Execution History. Figranium also auto-rotates the log at MAX_EXECUTIONS entries (default 500). See Captures & Storage.
5

Restrict access to the host

All execution data stays on your own machine or server. Because there is no in-app redaction, anyone with filesystem or database access to data/executions.json can read historical values. Follow Security best practices to keep that data private.
Output provider credentials saved under Settings > API Keys (Baserow tokens, Gemini/OpenAI/Claude keys, and similar) are stored separately and are redacted in the GET /api/credentials API response. This section applies to values typed into pages during a scrape, not to those saved credentials.
Use block.output to chain actions together. After a javascript block returns data, the next block can reference it with {$block.output} to build dynamic, multi-step workflows without intermediate variables.