Workflows Overview
Workflows integrate Marketrix into your product stack. Connect a tool your team already uses, wire one of its events — or a schedule — to a Marketrix action, and the work starts without anyone kicking it off.
Everything lives on the Workflows page in the dashboard, under Dev Tools. The page has two halves: the Connectors cards at the top, and the Workflows table below.
Unlike the rest of the platform, Workflows belong to the workspace rather than to a single Application. Your connected Connectors, triggers, and workflows are shared across every Application in the workspace, and deleting an Application leaves them untouched.
The three building blocks
Section titled “The three building blocks”- Connectors — The platforms you link to Marketrix: GitHub and Slack, plus the built-in Timer and MCP. Teams and Jira appear in the list but cannot be connected — see Connectors.
- Triggers — The events or schedules that start a workflow, such as a pull request or a nightly cron schedule.
- Workflows — Visual sequences that wire a trigger to one or more actions.
How the pieces fit together
Section titled “How the pieces fit together”- Connect a Connector — Authenticate GitHub or Slack so Marketrix can listen for their events and act on your behalf. Timer and MCP need no external account.
- Create a Trigger — On the provider’s page, define what starts the run: a GitHub event, or a Timer schedule.
- Build a Workflow — On the canvas, drop the trigger and one or more actions and connect them.
- Let it run — When the trigger fires, the workflow runs each step in order. You can also open a saved workflow and click Run Now.
What a workflow can do today
Section titled “What a workflow can do today”These are the actions a workflow step can run:
| Action | Comes from |
|---|---|
| Run QA Flow | Marketrix |
| Run Simulation | Marketrix |
| Comment on PR | GitHub |
| Create issue | GitHub |
| Send message | Slack |
| Post thread reply | Slack |
Run history
Section titled “Run history”Every workflow keeps a history of its runs. Each run records its status, when it started and finished, how long it took, the data the trigger passed in, and a per-step breakdown. You can see exactly which step succeeded, failed, or was skipped, and inspect each step’s output. Triggers keep their own run history too, so you can confirm an event actually fired.