Tracker integrations

A tracker integration gives two things: the team addresses Buff where it already works — in a ticket, an issue, a pull request discussion — the question is asked in a comment and the answer arrives in the same place; and the model in “Ask” and in deep research reads your tracker as a source — how exactly.

All tracker integrations behave the same way; the only differences are what a particular tracker lacks. The differences are in the table below.

How to address the bot

Work starts only when the bot is addressed directly. This is a decision, not a limitation: labels and statuses are changed by automation rules and bulk edits, and starting on them would mean work that nobody ordered but somebody paid for.

There are two ways to address it, and both work everywhere:

Useful details:

• Case does not matter. @Buff, @BUFFBOT, /Research — these are all requests.
• Alias. Besides the bot account, a short name from the connection settings (mention_alias) works, usually @buff.
• The tracker’s autocomplete works too: an inserted mention is recognised just like one typed by hand.
• The text around the request counts — you can first describe the context and then ask.
• Addressing the bot again in the same ticket continues the same conversation: you can follow up without starting from scratch.
• The bot does not intercept other people’s mentions: @buffalo is a different person.

What you can ask for

Without a command it is a question: the most frequent case and therefore the default.

The visibility scope is access control

Every connection has a list: the repositories or project keys where the bot works. The list works both ways — in places not on it the bot neither reads requests nor writes answers.

The bot account’s permissions in the tracker are the outer boundary, the list is the inner one. It is sensible to have both: the bot’s access is limited by what it was given, and within that — by what you selected.

Who may ask the bot

The list of places says where the bot answers. Which people may address it is a separate connection setting, “Who may ask the bot” (connector v0.18.0 and newer):

• rules, one per line: a login (petrov), an address (petrov@company.ru), a domain (@company.ru) or a regular expression (/^dev-.+@company\.ru$/);
• “Buff organisation members” — those whose address in the system matches the address of a member of your organisation in Buff may ask; with single sign-on — any address on the organisation’s verified domains.

An empty list and an unticked box — everyone may ask, as before. To an author the rules do not admit, the bot politely replies that they can ask in Buff, and gives a link; nothing is started and nothing is charged. Every request and every refusal is recorded in the audit log — without the text of the question.

The bot takes the login and address from the system itself, and not all systems show them: Jira Cloud, Confluence Cloud, Notion and Google Drive have no login — only the address, unless the person hid it; GitHub, GitLab and Gitea show the address only if it is public in the profile; Redmine — only to an administrator’s token; Bitbucket Cloud has no address. Figma shows neither: with rules set, nobody will be able to ask from it.

The answer is published as privately as the question was asked: to an internal GitLab note — as an internal note, to a private Redmine note — as a private one, to a Jira comment restricted to a role or group — for the same role or group, to an internal Jira Service Management comment — as an internal one. A document for a private question on an issue is not attached (everyone would see the attachment) — it stays in Buff behind a link.

An answer based on the code where the question was asked

A question asked in a pull request discussion is a question about the code of this branch. The integration passes the branch along with the request, the platform pulls it from your repository and computes the answer on it.

For this to work, the repository must be connected to Buff as a code source — by the same connector, in the “Repositories” section. If it is not connected, the bot still answers based on the project’s main branch and says so plainly in the ticket: an answer computed on other code and passed off as an answer about this pull request is worse than none.

What the bot writes in the ticket

1. Right away — a short “got it, working”: research takes minutes, and without this it is unclear whether the bot heard you at all.
2. A link — to the conversation, the draft or the research in Buff. Where the tracker can store links separately (Jira), it goes into the ticket’s links block rather than getting lost in the comment feed.
3. The result — the finished answer as a comment. For research — also the document itself: where the tracker accepts attachments, the PDF is attached to the ticket.

If information is missing, the bot asks a clarifying question in the same ticket and waits for the answer. If something did not work, it says so too: silence would read as a breakdown.

The bot never touches statuses, labels, assignees or fields. No tracker integration has a tool for that: the only writing tool is the comment, and it is not given to the model.

Assigning a task to the bot

Assignment is a borderline case: the task really is addressed to the bot, but tasks are also assigned by routing rules when nobody ordered the work. So it is off by default and is turned on with the “Accept tasks assigned to the bot” checkbox — if assignments at your place are made deliberately by a person.

Events: polling and webhooks

Polling always works. Each connection reads its tracker at its own interval — every 20 seconds by default; an integration may suggest another one, and the connection’s “Polling interval” field has the final say. This does not require opening a single port to the outside — the connection is outbound. For a closed perimeter this is the default working mode.

Webhooks only speed up delivery. The receiver belongs to the connector — one address for all connections, set up in the “Connection” section. The connection itself has only a toggle: the connector issues the link with the secret, you do not need to make it up.

Where to paste the link and which events to subscribe to:

The bot does not dig through old requests. For a new connection the count starts from the moment you turned it on: tickets written before that will not suddenly be answered retroactively.

Which tracker can do what

Besides trackers, the catalogue has knowledge sources — Confluence, Notion, Google Drive, Figma and files on disk: there the bot does not run tasks but reads what the team has written and answers in the page’s discussion; there is also the “Web” integration and the option to bring your own MCP server. Separate pages: “Knowledge sources”, “The web for the model”, “Custom MCP servers”.

Bitbucket Data Center has no task tracker of its own — the integration lives in pull requests. For Bitbucket Cloud, Atlassian removed the task tracker from the API (410 Gone) — the integration, as with Data Center, lives in pull requests. If your tasks are in Jira or Redmine, install their integration alongside: there can be any number of connections, and each has its own development project or space.

What reaches us from the tracker

Only what the request cannot be carried out without, and only when the bot is addressed directly:

• the text of the request (without the rest of the ticket’s content — the model reads it with a tool when it needs it);
• the ticket title and link, the ticket key, the name of the request’s author;
• for a question from a pull request — the branch and repository name.

The tracker token never leaves: the connector makes the requests to the tracker from inside your network.

If something does not work