Triggers

A Trigger is what starts a workflow. It listens for an event from a connected Connector — or fires on a schedule — and starts the Workflow wired to it.

The triggers that exist today

Trigger	Connector	Fires when
Pull request	GitHub	A pull request is opened or updated
Workflow run	GitHub	A GitHub Actions workflow run reports back
Timer tick	Timer	The cron schedule you set comes around

Caution

That is the complete list. Teams, Jira, and MCP contribute no triggers — connecting them does not give you an event to build on. Slack has no trigger form either; it starts work through the /marketrix slash command instead (see Connectors).

Creating a trigger

1. Open the Workflows page and select GitHub or Timer.
2. Click to add a trigger and give it a name.
3. Configure its source, then save.

GitHub

Pick the repository from your connected account, the event type — Pull request or Workflow run — and, optionally, a branch filter to narrow it to a single branch.

GitHub triggers are wired up from your side, not installed automatically. Each trigger row has two buttons:

• Copy code — a ready-made GitHub Actions workflow that notifies Marketrix when the event fires. Commit it to the repository under .github/workflows/.
• Copy secret — the signing secret for that trigger. Add it to the repository as a secret named MARKETRIX_CLIENT_SECRET so Marketrix can verify the call is genuinely yours.

Each trigger has its own webhook URL, baked into the snippet. Once the workflow file is committed and the secret is set, the trigger starts firing.

Timer

Choose a schedule type — hourly, daily, weekly, monthly, or a custom cron expression — then the hour, minute, weekday, or day of month it needs. The triggers table shows the schedule in plain English along with the next fire time, so you can confirm it reads the way you intended.

Managing triggers

Triggers can be enabled or disabled at any time without deleting them — a disabled trigger stays configured but stops starting workflows. You can edit a trigger’s source configuration or delete it outright from its row.

Trigger run history

Each trigger keeps a history of when it fired. The triggers table shows the last fire time and the result of the most recent run; open an individual trigger to see the full run detail — the event, the related repository, ref, and workflow, a status of passed, failed, or unknown, the timestamp, and a link to the external run where one exists.

Common patterns

• PR validation — A GitHub Pull request trigger runs a QA Flow on every pull request and comments the result back on the PR.
• Scheduled runs — A Timer trigger runs a QA Flow nightly or weekly.
• On-demand runs — /marketrix workflow <name> starts a saved workflow from Slack without leaving chat.

Note

Workflows require a paid plan.

Next steps

Creating WorkflowsWire a trigger to actions on the canvas.

ConnectorsWhat each provider contributes.