Creating Workflows
A Workflow connects a Trigger to one or more actions that run when the trigger fires. You build one on a visual canvas, connecting nodes to define what happens and in what order.
Before you build
Section titled “Before you build”The canvas draws from what you have already set up on your provider pages. A workflow can only use triggers and actions that exist, so create them first:
- Triggers — Add a GitHub or Timer trigger on its Connector page.
- Actions — Add an action from the Actions table on any connected provider’s page. Each provider offers its own actions plus the two built-in Marketrix ones:
| Action | Where it comes from |
|---|---|
| Run QA Flow | Marketrix — available on every connected provider |
| Run Simulation | Marketrix — available on every connected provider |
| Comment on PR | GitHub |
| Create issue | GitHub |
| Send message | Slack |
| Post thread reply | Slack |
Building a workflow
Section titled “Building a workflow”- On the Workflows page, click New Workflow.
- Choose a starting point: the GitHub PR → QA Check template, one of your existing triggers or actions, or start from scratch.
- On the canvas, drag triggers and actions from the left palette — or click one to append it — and connect the nodes.
- Click a node to configure it in the details panel.
- Name the workflow and save.
A workflow can’t be saved until it has a name, at least one trigger, and at least one action.
The one built-in template
Section titled “The one built-in template”GitHub PR → QA Check is pre-wired: a GitHub Pull request trigger feeding Run QA Flow. Open it, pick which QA Flow to run, and save. It’s the fastest way to see how a trigger and an action connect.
Configuring a node
Section titled “Configuring a node”Each node type has its own fields in the details panel. Run QA Flow asks which QA Flow to execute; Run Simulation mirrors the Generate Simulation modal — Application, persona, and instructions or a past simulation to copy.
Action fields can also reference the trigger’s output instead of a fixed value, using the node’s id and the field path — for example {{trigger-pr.output.pull_request.number}} to pass through the pull request that started the run. The details panel lists the fields each trigger emits.
Running a workflow
Section titled “Running a workflow”Workflows run automatically whenever their trigger fires. You can also open a saved workflow and click Run Now to run it on demand.
A workflow is active or inactive — toggle it from the workflows table without deleting it. Inactive workflows do not run when their trigger fires.
Run history
Section titled “Run history”Every workflow keeps a run history. Open a workflow to see its runs in a two-pane view: pick a run on the left to inspect it on the right. Each run shows:
- Status — running, completed, failed, stopped, or pending.
- Timing — when it started, when it finished, and total duration.
- Trigger data — the data the trigger passed into the run.
- Per-step results — each step’s status (running, completed, failed, skipped, or stopped), its output, any error, and how long it took. Failed steps open expanded so the error is the first thing you see.