Modular Workflows (Task Chaining)

Figranium supports Modular Workflows, allowing you to break complex automations into smaller, reusable tasks and chain them together using the Start Task block.

​

Why Modular Workflows?

As automations grow, a single monolithic task becomes hard to maintain. Modular workflows let you:

​

The Start Task Action

The Start Task action triggers another task by its ID, running it as a sub-task within the current execution context. Key behaviors:

• The child task runs to completion before the parent continues.
• Variables from the parent task are passed down to the child task automatically.
• The child task’s block.output (extraction result) is available back in the parent as block.output after the Start Task block.
• If the child task fails, the parent task’s error handling applies.

---

​

How to Chain Tasks

---

​

Common Modular Patterns

​

Pattern 1: Shared Login Task

Create a single “Login” task and call it at the start of all tasks that require authentication:

​

Pattern 2: Paginated Scraping

Break pagination into a loop calling a “Scrape One Page” sub-task:

​

Pattern 3: Error Recovery

Use an On Error block to trigger a recovery sub-task when something goes wrong:

---

​

Accessing Child Task Output

After a Start Task block, the child task’s extraction result is available in block.output:

---

​

Recursive Flows

It is technically possible to create recursive chains (Task A starts Task B, which starts Task A). This can be useful for retry loops or indefinite monitoring tasks. Always include a termination condition to prevent infinite loops:

---

​

Finding Task IDs

You can find a task’s ID in several ways:

1. Dashboard URL: When you open a task, the URL contains the task ID (e.g., /editor/task_abc123).
2. Export: The exported JSON file includes the task ID at the top level.

---

​

Task ID validation

The Start Task block sanitizes the task ID before issuing the internal API call. Only alphanumeric characters, underscores (_), and hyphens (-) are preserved; any other character, including path separators, query strings, and whitespace, is stripped out. If sanitization removes every character (for example, when a template variable resolves to ../../api/clear-cookies? or any other non-conforming string), the action fails fast with Invalid task id. and no request is made. This prevents a crafted variable value from being used to probe other internal endpoints through the Start Task block. When user_input resolves to task_abc123, the action runs normally. When it resolves to ../../api/clear-cookies?, the action errors with Invalid task id. and the parent task continues with that step marked failed.