Workflows

Access from: Processes → Workflows

A workflow is an automation that runs a sequence of steps over your Amazon data, either on demand or on a schedule. It lets you audit products, detect issues and create review tasks without having to do it manually.

How are they created?

Today there are two ways to create a workflow in Epinium:

• From a template — by cloning one from the Templates library. This is the recommended and fastest path.
• With VelaxAI — describe in natural language what you want to automate and VelaxAI generates the workflow for you.

There is no option yet to create a workflow from scratch on a blank canvas. Once a workflow exists (cloned from a template or generated by VelaxAI), you can edit it freely: change its trigger, conditions, code, connections, etc.

Workflow, Task or VelaxAI?

• Workflow — for recurring rules that run periodically (every Monday, every 1st of the month).
• Task — to review and approve the suggestions that a workflow (or VelaxAI) generates.
• VelaxAI — for ad-hoc natural-language queries and to create new workflows.

Workflow states

A workflow can be in one of three states:

State	Meaning
Paused	Configured but won't run automatically. This is the default state when you clone a template. You can still execute it manually.
Active	Will run automatically according to its trigger.
With validation errors	The editor detected a problem in the graph (disconnected node, empty condition, broken reference). It cannot be activated until you fix it.

The visual editor

The editor shows the workflow as a graph: each box is a node (a step) and each line is a connection (what comes next).

• Canvas — you can move nodes to reorganize visually. It doesn't affect the logic.
• Connections — some are simple (a single outgoing path). Others branch: a Condition has Yes and No outputs; a Loop has per item (for each element) and on done (when the iteration finishes).
• Configure a node — click a node to open a modal where you can edit its parameters: message, URL, condition, variable assignments, etc.
• Edit a node's code — the Run code node opens an editor where you can read and modify the script (generated by VelaxAI or copied from the template).
• Automatic validation — the editor highlights errors in red (orphan nodes, broken connections, conditions without an operator). If there are errors, the workflow cannot be activated.

A node's configuration modal

The gear icon (⚙️) on each node opens its configuration. Depending on the node type, different tabs appear:

Tab	What it holds
General	The node name — the text shown on the diagram. Present on every node
Configuration	The parameters specific to the node type: the condition, the task data, the HTTP request URL…
Filters	Only on For each loops with a Query source: which elements will be iterated. See § Loop filters
Reduce code	Only on For each loops that collect results: the code that aggregates them. See § Reduce code

Renaming a node — change it in the General tab. Give it a name that says what it does («Check title», «Notify on Slack») instead of the generic one: names appear on the diagram, in the run history and in other nodes' variable references, so a clear name pays for itself when debugging. If you leave the field empty, the default name is kept.

Version history

Every time you save a workflow, Epinium archives the previous version before overwriting it. The Version history button opens the list, with one row per version: name, status, node count, validation errors and date.

From there you can Restore any previous version. The current version is archived before restoring too, so going back loses nothing: if the version you brought back wasn't the one you wanted, restore the previous one.

On restoring, the graph is validated again. If the version you bring back had errors, the workflow ends up with validation errors and cannot be activated until you fix them.

Node types

These are the available nodes:

Node	What it does
Start	Marks where the flow begins. Every workflow has exactly one start node.
End	Marks an end point. A workflow can have several end nodes (one per branch, for example).
Action	Performs a concrete task. It has several sub-types (see next table).
Condition	Yes / No branch based on a field and an operator (equals, greater than, contains, is empty…).
Multi-branch	Like a condition but with multiple outputs depending on the value of a field. Useful when there are more than two cases.
Loop (For each)	Iterates over a set of items (products, campaigns, search terms…). See § Loops.
Wait	Pauses the flow for a duration (seconds, minutes, hours) before continuing.

Sub-types of the Action node:

Sub-type	What it does
Log message	Writes a message to the execution log. Useful for debugging or leaving traces.
HTTP request	Calls an external URL (a webhook, an integration with another system). Lets you send data to third-party tools.
Run code	Runs custom logic in a sandboxed environment. It is the engine behind the audit-template checks: it evaluates complex rules over a product and returns a structured result. You can read and edit the script from the editor.
Create task	Generates or updates a task with one or more items for human review. See § Tasks and human oversight.
Resolve task	Marks as resolved the items of a task whose problems no longer apply (because they have been fixed).

Triggers

A workflow can be launched in two ways:

• Manual — Run button on the workflow page. It opens a modal that shows the estimated maximum cost before you confirm.
• Scheduled — the workflow runs on its own following a schedule:
  • Cron — standard 5-field cron expression. Examples: every Monday at 9:00, day 1 of each month at 5:00.
  • Interval — every N minutes, hours or days.
  • One-off date — a single run at a specific date/time.
• Time zone — configurable per workflow (e.g. Europe/Madrid). The trigger is interpreted in this zone, not in UTC.

Estimated cost

Before running a workflow manually, Epinium calculates and shows the maximum cost in credits. This number reflects the worst case (every audited product, every node executed without skips).

Check the cost before activating

If you're about to activate a scheduled workflow that iterates over the whole catalog, run it manually first to see the actual cost. On large catalogs, an accidental daily run can consume more credits than expected.

Loops (For each)

A For each node repeats the steps inside it once per element of a list.

Data source — two modes:

• Query — pick a collection from your account (products, campaigns, search terms, ad groups, product ads, keywords, clusters) and apply filters to narrow it down. This is the most common mode.
• Reference — iterate over a list produced by a previous node (for example, the result of an HTTP request).

Per-item error handling — if the evaluation of an item fails, the loop can:

• Continue (default) — keep processing the rest of the items.
• Abort — stop the whole loop.

Collect results — optionally, the loop can aggregate what each iteration produces into a final summary. The audit templates use this to count how many products comply vs how many don't, and show the summary in the log.

The loop has two outputs: per item (what runs for each element) and on done (what runs once all are processed).

Loop filters

With the source in Query mode, the node's Filters tab narrows down which elements will be iterated. With no filters, the loop goes through all the elements in the collection.

Filters are organised into rule groups, and how they combine is the key part:

• Rules within the same group combine with OR — one of them matching is enough.
• Groups between themselves combine with AND — every group has to match.

That is how you express conditions like «(brand A or brand B) and (no main image)»: one brand per rule in the first group, and the image condition in a second group.

Each rule has three parts and a switch:

Part	What it is for
Field	The path of the data inside the element, for example commonFields.ASIN
Value	What it is compared against
Format	How to interpret the value: Text, ObjectId, Boolean, Date or Exists (number) — the last one takes the elements that have a number in that field
Active	Turns the rule off without deleting it, handy for testing

Format matters

The same value filters differently depending on the format. true as Text looks for the string "true"; as Boolean it looks for the boolean value; as Exists (number) it checks that the field holds a number (a configured max bid, for instance). If a filter doesn't return what you expect, the format is the first thing to check.

In Reference mode the Filters tab does not apply: the loop iterates over what a previous node produced, so the filtering has to happen in that node.

Reduce code

When the loop has Collect results enabled, the Reduce code tab lets you aggregate what each iteration returns into a single final result.

It works in batches (streaming): the code runs once per batch, not once per element. It receives input.items (the current batch) and input.accumulator (the previous batch's result, null on the first one) and must return the accumulator for the next batch.

This is how you get totals out of an audit — how many products pass and how many don't — without holding the whole catalog in memory. The final result is visible on the node, in the run inspector.

Variables and context

Workflows use variables to pass data between nodes. The syntax is {{ ... }} and there are three origins:

Variable	Where it comes from	Example
{{trigger.X}}	Data sent to the workflow when you run it manually.	{{trigger.email}}
{{nodes.NAME.result.X}}	Output of a previous node.	{{nodes.checkTitle.result.titleTooLong}}
{{forEach.NAME}}	The current element when you're inside a loop. By default it's called item, but templates typically use more readable names like product.	{{forEach.product}}

Example use in a Condition: evaluate whether the result of a code node says the title is too short:

• Field: {{nodes.checkTitle.result.titleTooLong}}
• Operator: is true

Campaign selection (Smart Campaigns)

The Smart Campaigns Optimizer workflow offers, in its Variables tab, a control to decide which campaigns it acts on.

Include all campaigns with a target ACOS configured (toggle):

• On — the workflow automatically manages every campaign that has its target ACOS/ROAS and maximum bid configured.
• Off — manual selection: the workflow only acts on the campaigns you choose. When you add a new workflow the toggle starts off. It saves instantly (no need to click "Save changes").

With the toggle off, the Algorithm campaigns button is enabled, opening a table where, per campaign (Sponsored Products):

Column	What it does
Optimize	Whether the workflow should optimize that campaign. Can only be enabled if the campaign has an objective set.
Objective	Objective type — ACOS or ROAS.
Value	The target value (e.g. 25% ACOS).

The table is paginated, has search and shows already-managed campaigns first. Changes are saved with the modal's own Save button.

Relationship with per-campaign AI Settings

Checking a campaign here is equivalent to forcing that workflow from the campaign's AI Settings: it's the same information seen from the workflow side, and the objective you edit is the campaign's objective.

If, with the toggle off, you check no campaign, the workflow processes none — it doesn't fail, it just doesn't act until you choose.

Tasks and human oversight

Workflows can generate tasks so a human can review their findings before any change is applied. This is the strong point of the system: automation detects issues, but nothing gets applied until you approve.

Create task node

When a workflow detects a problem, this node creates a task (or adds items to an existing task). Items can include a suggested value (auto-fix) that the user can accept with one click.

• Idempotency — the workflow uses a unique key per problem. Re-running the workflow doesn't duplicate tasks: it adds new items if new problems appear, and leaves alone the ones that were already there.
• HITL (Human-in-the-Loop) — when enabled, items are not applied automatically. A human must review and approve them before they reach the product or campaign.

Resolve task node

Marks as resolved the items of a task whose problems no longer apply. Useful when you re-run a workflow and a product that used to fail now complies — the node automatically closes the associated items.

More about the task system in Tasks.

Execution history

Every time a workflow runs, the run is recorded and viewable from its page. The possible states are:

State	Meaning
Pending	Queued, hasn't started yet.
Running	In progress.
Completed	Finished without errors.
Partial	Finished, but some items failed and were left unprocessed. It shows up in workflows that iterate: one campaign failing, for instance, while the rest are optimized normally.
Failed	A node failed and aborted the flow.
Cancelled	Manually stopped.

Execution inspector

Click a node inside a run to open the inspector and see:

• Input — the resolved variables the node received.
• Output — the result it produced.
• Error — if any, with a readable message.

Debug a failed run

Start with the first node in red. Read its output or its error. Check the input variables — most failures come from a broken reference to a previous node or from empty data where a value was expected.

Creating workflows with VelaxAI

VelaxAI includes a dedicated agent that generates workflows from natural language. The user describes what they want to automate and VelaxAI proposes a complete workflow: nodes, connections, conditions, and, when needed, the code of the Run code nodes.

What you can do:

• Describe your need in a conversation.
• Ask for changes to the initial proposal.
• Manually review and edit the code generated in the Run code nodes.
• Adjust the trigger (schedule, interval).
• Activate the workflow once you're happy with it.

Generation in evolution

VelaxAI's generation keeps improving. Very complex workflows may need manual adjustments after the initial generation — VelaxAI will tell you what's missing or what to validate.

More about VelaxAI in VelaxAI.

Best practices and limits

• Enable HITL when the workflow modifies sensitive data (prices, titles, descriptions, campaign budgets). It gives you a checkpoint before the change reaches Amazon.
• Check the estimated cost before activating a scheduled workflow, especially if it iterates over the whole catalog. A prior manual run shows you the actual cost.
• Start paused. Run the workflow manually once to validate the result, and only then enable the cron.
• Failed runs don't retry on their own. If a run fails, open the history, identify the failing node, fix the root cause and re-run manually.
• For mass audits, prefer the templates — they are tuned to process large catalogs with batching and per-item error handling.