Configure ticket intake and workflow states

Workflow intake decides which tickets MergeLoom can pick up and how those tickets move through your existing workflow.

The goal is not to replace your project management process. The goal is to make the existing process explicit enough that MergeLoom can follow it.

This is in the customer controller

Configure intake source, output target, labels, and status mappings from https://controller.mergeloom.ai. The local worker UI does not own workflow state rules.

Intake is off by default

New workspaces do not poll tickets automatically. Scheduled intake starts switched off, so you can connect integrations, sync repositories, confirm repository routing aliases, and install a worker before MergeLoom picks up any work.

Turn Scheduled intake on from Global workflow settings only when your worker, repository routing labels, and first test ticket are ready.

MergeLoom customer controller workflow intake page showing intake source, output target, and status mappings. — Customer controller: workflow rules decide what enters the queue and how MergeLoom moves tickets through your existing process.

Core concepts

Setting	Meaning
Intake source	Where MergeLoom looks for ready work.
Code output	Where MergeLoom creates the PR or MR.
Managed intake label	The label or tag that marks work as eligible.
Ready state	The state that means a ticket can be picked up.
In progress state	The state MergeLoom can move work to when a run starts.
Review/testing state	The state MergeLoom can move work to when validation passes.
Blocked state	The state MergeLoom can use when a run cannot safely continue.

The shipped managed intake label default is:

mergeloom

Keep Scheduled intake off while you test the setup. MergeLoom will not automatically poll eligible tickets until you switch it on.

Jira intake

Use Jira intake when your team manages work in Jira.

Example JQL:

project = MIR AND labels = "mergeloom" AND status = "To Do" ORDER BY updated ASC

Recommended first-run pattern:

add the mergeloom label to one small issue
keep the issue in the ready state, usually To Do
make sure the issue has enough context for an engineer to implement it
route the issue to an enabled repository

monday.dev intake

Use monday.dev intake when your team manages work in monday.com boards.

Configure:

monday.com board IDs
status column ID
repository routing column ID if needed
description column ID
assignee column ID
ready status label
in-progress status label
review/testing status label
blocked status label
done status label

Recommended first-run pattern:

use one board
use one ready status label
make sure the item has enough description/context to implement
route the item to an enabled repository

GitHub Issues and GitLab Issues intake

For GitHub Issues or GitLab Issues, an eligible issue should usually:

be open
have the managed intake label, usually mergeloom
have a repo routing label such as repo-server if more than one work repo is enabled
be assigned to a MergeLoom workspace user

If intake is denied, MergeLoom should leave the issue in place, post a denial comment, and show the denial in Worker Runs.

Azure Boards intake

For Azure Boards, configure:

Azure DevOps organization
Azure Boards project
intake WIQL
ready state
in-progress state
review/testing state
blocked state
done state

Default intake expects a work item to:

have the mergeloom tag
be in the configured ready state
have a repo routing tag if multiple work repos are enabled
be assigned to a MergeLoom workspace user

Jira ticket showing the managed MergeLoom intake label and repository routing label. — Project management tool: the label or tag marks the ticket as eligible without changing your normal workflow.

Comments are part of the workflow

MergeLoom can use ticket comments as part of the next run.

For a continuation pass:

Add a comment that starts with:
```
MergeLoom -
```
Put the new instruction in that same comment.
Move the ticket back to the configured ready state.
Let the scheduler pick it back up.

Current behavior:

MergeLoom resumes on the same branch
the next run receives the previous summary plus the new continuation instruction
if a PR or MR already exists, MergeLoom updates the same review branch

Repository routing labels

Use repository routing labels when a workspace has more than one enabled work repository.

Open Repository catalog in the customer controller to see each repository alias. The alias is the label value you put on the ticket, issue, work item, or board item.

Example:

repo-server
repo-web
repo-api

In this example, the repository aliases are server, web, and api, so the labels are repo-server, repo-web, and repo-api.

If the repository alias changes in the catalog, the routing label changes with it. Update the ticket label to match the current alias before running intake.

For Jira campaigns from Epics:

put mergeloom on the Epic
put the default repo-<alias> label on the Epic if all child issues use one repo
put child repo-<alias> labels only when a child issue needs to override the Epic default

If a ticket has no matching repository route, MergeLoom leaves a comment on the ticket and records the failure in the controller activity log. Fix the repo-* label or repository catalog entry, then sync intake again.

Safe first intake setup

For the first live run:

use one intake source
use one code output provider
enable one writable repository
use one ready state
use the default mergeloom label
keep the ticket small and easy to review
turn Scheduled intake on only after the worker and routing labels are ready