Appearance
Automations
An automation is a rule that turns an event into work for your agents, so nobody has to start it by hand. A ticket is created in Jira, Linear or Notion, someone comments on a GitHub pull request, a job finishes, or a schedule comes round, and Kadmo starts a playbook on the ticket or runs a workflow on an agent. A typical rule: every new Bug in the ENG project starts the Bug Fix playbook. After that, filing the bug is all it takes.
Each automation has three parts:
| Part | In the form | What it is |
|---|---|---|
| Trigger | When — Trigger | The source of the event (Jira, Linear, Notion, GitHub, Figma, Kadmo or Cron) and its filters |
| Action | What — Action | A Playbook run on the ticket, or a single Workflow job |
| Options | Under the action | Where it runs, how it is approved, and how it reports back |
Before you start
- Connect the source under Integrations. See Jira, Linear, Notion and Integrations. Until a source is connected, the form shows a notice such as Jira connection required or GitHub App installation required instead of its filters. Filters you saved earlier are kept.
- Have a playbook or workflow to run. The seeded playbooks (Bug Fix, Feature Implementation, Hotfix, …) are ready to use.
- Have an agent that can run the roles the playbook needs. See Agents.
- Optional: link the tracker project to a workspace, so runs land in the right repository. See Workspaces.
Kadmo receives Jira and Linear events through webhooks, set up from the Integrations page when you connect the tracker. Notion boards are checked for changes every 5 minutes.
Create an automation
Only account admins can create, edit, switch off or delete automations.
- Open Settings → Automations (
app.kadmo.ai/automations). - Click + New Automation.
- Enter a Name, for example
Bugs to Bug Fix. - Under When — Trigger, pick the Trigger Type and set its filters (see Triggers).
- Under What — Action, choose Playbook or Workflow and set its options (see Actions).
- Click Save. The rule is live as soon as it appears in the list.
If something is missing, the form says so: Name is required, Trigger type is required, Workflow is required or Playbook is required.
Triggers
Every filter you set must match (they are combined with AND). A filter left at Any matches everything.
Jira
| Filter | Matches |
|---|---|
| Project | The issue's project |
| Issue Type | The issue type, for example Bug |
| Assignee | A Jira user. Type a name and pick from the suggestions. |
| Status | The issue's current status name. This is not a from–to transition. |
| Trigger on events | Issue created, Issue updated, Comment added, Issue assigned (Jira app only) |
Linear
| Filter | Matches |
|---|---|
| Team | The Linear team |
| Label | The issue's first label. Linear has no issue types, so a label stands in for one. |
| Assignee | A Linear user, picked from the suggestions |
| Status | The workflow state name |
| Trigger on events | Issue created, Issue updated, Comment added. With none checked, created and updated both count. |
Comment events carry no labels, so a rule with a Label filter never fires on comments.
Notion
| Filter | Matches |
|---|---|
| Data source | The board (database) the card belongs to |
| Type, Assignee, Status | The card's properties |
| Trigger on events | Card created, Card updated (properties) |
Comment added is shown but not available yet: comments on Notion cards are not delivered. Cards created before the board was connected are not picked up.
GitHub
GitHub events come from the GitHub App you install under Integrations; there is no webhook for you to set up.
| Filter | Matches |
|---|---|
| Trigger on events | Comment added (the default), Review submitted, PR opened, PR ready for review, PR updated, PR closed |
| Repositories | Repositories the app covers. None checked means all of them. |
| Mention | Any comment (no mention required), Connected GitHub identity, Kadmo AI handle or Custom login… |
| Minimum comment author | From Anyone (no floor) to Repository owner only. The default is Collaborator or better, so strangers cannot start work on public repositories. |
| Review verdict, Merge outcome, Base branch | Narrow review and PR events |
A GitHub rule with a playbook action needs a specific playbook (not routed by issue type), and it works the ticket named in the pull request's description. A GitHub workflow rule needs the repository attached to a workspace.
Figma
Starts work from Figma: a comment is posted, a layer's Dev Mode status changes, a named version is saved, a library is published, and more. It needs a Figma connection and a Figma team, project or file bound to a workspace. Filters include Bindings, Mention, Keyword and Who can start work.
Kadmo
Fires when one of your own agent jobs completes. Filter by Workflow and Agent. Use it to chain work, for example running a check after a deploy workflow. With Same agent (from trigger) as the action's agent, the follow-up runs on the agent that did the first job.
Jobs started by an automation never fire a Kadmo trigger, so rules cannot loop.
Cron
Runs a workflow on a schedule. Enter a cron expression in Schedule (for example 0 9 * * 1-5), or pick a preset: Every hour, Daily 9am, Weekdays 9am or Weekly Mon 9am. A scheduled run is skipped while the previous one is still going. Changes take effect within a minute.
Actions
Playbook
Available for Jira, Linear, Notion, GitHub and Figma triggers. Choose the playbook:
- Route by issue type (recommended): each ticket runs the playbook its issue type maps to under Issue type routing. Types set to skip create nothing, and unmapped types are pooled for you to pick. See Issue type routing.
- Always use:
<playbook>: every matching ticket runs that playbook.
| Option | Choices | What it does |
|---|---|---|
| Run via | Task pool (default) / Run immediately | Task pool adds the ticket to Tasks for dependency-ordered runs. Run immediately starts the run at once. |
| Approval | Auto-approve / Hold for review | Auto-approve lands the task as Waiting; it starts when its blockers clear. Hold lands it as Pending for you to approve. |
| Sync ticket status | on / off | Moves the ticket through its statuses as the run progresses. |
| Validate resolution | on (default) / off | Checks the finished work against the ticket's acceptance criteria. |
| hint | free text | Instructions added to every run this rule starts |
| Effort tier | Auto or one of your tiers | The run's effort tier |
Workflow
Runs one workflow as a single job. Choose the Workflow from your enabled workflows and the Agent:
| Agent | Meaning |
|---|---|
| Any available agent | The first eligible agent takes it. |
| Same agent (from trigger) | Kadmo trigger only: the agent that ran the triggering job |
| All agents | One job per agent |
| A named agent | Only that agent |
Under Workflow Parameters you can set a hint. A tracker-triggered workflow job also receives the ticket's URL, key, project, issue type, assignee and status as inputs. Cron rules always run on any available agent.
GitHub workflow rules can also acknowledge the comment (React with 👀, Reply on the pull request or Do nothing) and continue a live session. Figma workflow rules can reply when the job ends.
What happens when an event arrives
- Kadmo checks the event against every enabled rule of the source.
- A rule that matches is checked further. It is skipped when:
- webhook processing is paused for the account;
- the event was caused by Kadmo itself, such as an agent's own comment or status change;
- the ticket already has an active run (a ticket is never worked twice at once);
- the event is a duplicate delivery;
- the account is out of credit or over its daily cap.
- Otherwise the action runs: the ticket is pooled or a run starts, or a job is queued.
The rule's page records the outcome, and the run reports back on the ticket as it goes.
Firing again on the same ticket is safe. The task's details are refreshed, but approvals and dependencies you set by hand are kept.
Pause all webhooks
To stop all tracker-triggered work at once, switch Webhooks off on Issue type routing (Settings → Task setup). Incoming Jira and Linear events are then acknowledged but ignored; manual runs and the task scheduler are not affected. While it is off, the Automations page shows Webhook processing is paused for this account. with a Resume webhooks button.
The automation page
The list shows each rule with its trigger, its action (for example Playbook · Routed by issue type), a Holds for review chip when approval is held, an Off chip when it is switched off, and N jobs linking to the jobs it has queued.
Click a rule to open its page:
- Enabled / Disabled, plus Trigger Now, Edit and Delete
- A Configuration card with the trigger, action, approval (Holds for review or Starts automatically), status sync, workspace, agent and effort tier
- Trigger Execution Logs: every matched event, 20 per page, marked MATCH or SKIPPED with the reason. Each links to what it started: Job #N, Run #N or Task pooled.
Trigger Now runs the rule by hand. A playbook rule asks for a Ticket URL, then Start Run reports Run started! Run #N. A workflow rule reports Dispatched! with a link to the job. Trigger Now is not available for GitHub rules or while the rule is disabled.
Every incoming event across all rules, matched or not, is listed under Settings → General → Logs → Webhooks.
Cost is not shown on the automation page. Open the run or the job it started to see what it cost.
Switch off or delete
Use the toggle on the list or the rule's page to pause a rule without losing it. A disabled rule matches nothing. Delete removes the rule and its logs; this cannot be undone.
Rules Kadmo creates for you
When you connect Jira or Notion, Kadmo adds a rule called Assigned to Kadmo Agent (Assigned to Kadmo Agent (Notion) for Notion). Assigning a ticket to Kadmo pools it with the playbook its issue type routes to. Edit or switch it off like any other rule.
Troubleshooting
| Symptom | Check |
|---|---|
| Nothing fires | Is the source connected under Integrations? Is the rule enabled? Is webhook processing paused? |
| Fires on the wrong tickets | Filters are combined with AND, and an unset filter matches everything. In Linear, the label filter matches only the first label. |
| Comment events never fire | Comment added must be checked. On Linear, remove the Label filter. On Notion, comments are not delivered yet. |
| The log says matched but nothing started | Read the SKIPPED reason. Common ones: the ticket already has an active run, the task is pooled and waiting for approval or blockers, or the account is out of credit. |
| A pooled task never starts | See When an approved task does not start. |
| Runs land in the wrong repository | Link the tracker project to the right workspace. |
| A GitHub comment is ignored | Check Mention and Minimum comment author, and that the repository is covered by the app. |
Related
- Playbooks: what a playbook action runs
- Tasks: where pooled tickets wait and run
- Integrations: connect the sources
- Workflows: what a workflow action runs