Routing and notifications: Slack, Microsoft Teams, Linear, Jira

Routing destinations are where Watari posts updates and files issues. They are distinct from your support tools (Zendesk, Intercom, and Freshdesk), which send tickets in. You can connect any of them or none. They are optional, and they let your wider team see what Watari is doing.

All of them are bundled. They never add to your Mapped Issue count.

Get helpCopy Anchor Link

Connecting routing destinationsCopy Anchor Link

What a filed issue containsCopy Anchor Link

Every issue Watari files carries the report it wrote: the steps to reproduce, expected and actual behavior, the customer impact and the customer's own words, plus a link back to the issue in Watari. When Watari has found the issue in your code, the filed issue also lists up to three likely code locations (file, function, lines and repository), each marked Strong match, in the order Watari ranked them. That makes the issue a brief your team, or a coding agent you assign it to, can start from. The locations are a starting point, not a confirmed cause. Weaker matches are left out of the filed issue and stay visible in Watari.

A filed issue carries no scores or percentages. If you file every issue rather than only the ones Watari found in your code, an issue Watari is less sure about says so in one line: read the customer's words before acting on it.

Public repositories and projectsCopy Anchor Link

When Watari files a GitHub issue in a public repository, or an Azure Boards work item in a public Azure DevOps project (or cannot confirm that it is private), the issue leaves out the customer's own words, any screenshot or attachment links and the likely code locations, and links to the original report in Watari instead. Linear and Jira are private to your team, so they always get the full report.

Picking up issues from JiraCopy Anchor Link

If your team tracks customer problems as Jira issues rather than in a support desk, Watari can read them the same way it reads a support ticket. This is off until you turn it on, because connecting Jira so Watari can file issues is not the same as asking Watari to read yours.

Before you startCopy Anchor Link

• Only an owner or admin of your Watari workspace can change these settings.
• No Jira administrator is needed if you connected with Continue with Atlassian. Watari sets up the delivery of your issues itself, with the access you granted, and keeps it running. If Jira was connected before October 14, 2026, choose Reconnect on the Jira card once (your settings stay) so Watari can do this. If you connected with an API token, Watari sets it up when that account is a Jira administrator; otherwise it shows you exactly what a Jira administrator pastes once.
• Think about who Watari comments as. Watari comments on the issues it picks up as the Jira account your workspace is connected with. Connecting with a dedicated account keeps those comments under one name.
• Give the people who file issues a format to follow. An issue with a summary and one line is hard to find in code. The free bug report template lists the nine fields that matter and copies the result as Jira wiki markup.

Set it upCopy Anchor Link

1. Open Settings → Connected tools → Jira → Configure and turn on Pick up issues from Jira. The pickup settings appear once it is on.
2. Choose the projects to read issues from. Watari reads nothing from a project you leave unticked.
3. Choose how issues are handed to Watari. You can combine any of these:
   • Label. Someone adds a label you list, such as watari. You can also narrow by issue type, status or component.
   • Mention. Someone types @watariai in the description or a comment, then presses Esc. Jira opens its people search when you type @, and when you save it removes a search that matched nobody, so without Esc the mention disappears. Mentioning a Jira user named watariai works too. Mentioning it again in a comment on an issue Watari already has, with where to look, starts it again with that detail when Watari stopped without a draft fix or found the code and is waiting to draft. A mention with nothing else in it gets a reply with where the issue stands and a link to it in Watari.
   • Assignment. Watari does not appear in Jira's assignee list by itself. Enter the display name or Atlassian account ID of a Jira user you own, and assign issues to that user. Email addresses are not matched, because Jira usually hides them.
   • Every new issue. Watari picks up each issue when it is created in one of those projects. Existing issues are never picked up this way, so switching it on does not pull in your backlog.
4. Save. If Watari could set up the connection, you are done. If not, the dialog stays open and says why: either reconnect Jira, or have a Jira administrator add the address, the secret, the three events and the issue filter it shows under Jira settings → System → WebHooks (Jira's name for that screen). It is added once, and keeps working when you change the settings here.
5. If nobody can add it there, the same panel describes a second way: a Jira Automation rule with a Send web request action, which a project administrator can usually create. A rule cannot tell Watari who made a change, so on a rule a label or an assignment hands over only issues that someone on your Jira team reported.
6. If one of those projects creates issues from email or from a public form, fill in Accounts that file for people outside your team with the Jira user those issues are filed under (its display name or Atlassian account ID). Jira files such issues under an ordinary user account, so Watari cannot tell them from an issue a teammate wrote unless you name that account. Once named, those issues are treated like requests from outside your team: nothing is picked up until someone on your team labels, assigns or mentions. If you skip this, anyone who can email that address can have an issue picked up automatically.
7. Label one test issue (or mention Watari on it) and watch it appear under Issues within a minute or two. Open the dialog again to see the Recent issues list: each issue Watari received, what your saved settings did with it and, for one that was skipped, why.

If you later point Watari at a different Jira site, issue pickup is switched off and its project list is cleared, because those projects belonged to the previous site, and the connection details change. Choose the projects again; on a connection that needs a Jira administrator, add the new details on the new site.

Jira Service Management projectsCopy Anchor Link

A service project takes requests and comments from your own customers through the portal. Watari treats them as people outside your team: a request or comment from a portal customer never starts work by itself, even when it carries your label or types the handle, and what they wrote in a comment is not read. Someone on your Jira team hands such a request over by adding the label, assigning it, or mentioning Watari. Anything skipped for this reason is listed in the dialog as "came from someone outside your team".

On a service project, Watari's comments are added as internal notes and carry where the issue stands and a link to Watari only: no link to the draft fix, no investigation notes and no suggested answer. Watari checks each one: if Jira does not confirm a comment as internal, Watari removes it and stops commenting on Jira issues altogether, until an owner or admin turns Post progress on the issue off and on again. The customer update (what went wrong and how it was fixed) is not posted on a service request; it stays in Watari for your team to send through the portal.

What happens nextCopy Anchor Link

Watari works on each issue it picks up the same way as on a support ticket. Questions that are not code defects get a suggested answer for your team instead of a draft fix. An issue counts toward your Mapped Issue allowance only if Watari finds it in your code.

An issue Watari picked up is its own issue: Watari posts progress on it and does not file a second one beside it in Jira, even when issue filing to Jira is switched on. Issues Watari files for reports that came from somewhere else are never picked up as new reports, so the two features can run in the same project.

Watari comments as the issue moves (see What Watari's comments say). When the draft fix opens, Watari adds it to the issue as a web link. On an issue only your team can see, comments include that link and the customer update you approved in Watari. You can turn Watari's comments off in the same dialog.

Turning issue pickup off, or disconnecting Jira, removes the connection Watari set up in Jira. One your Jira administrator added by hand stays in Jira until they remove it, and stops being accepted by Watari once Jira is disconnected. On a connection made with an API token, if the one Watari added is later removed in Jira, Watari does not put it back, not overnight and not when you change an unrelated setting: the Jira card shows Not receiving issues with a Repair connection button, and your owners and admins are notified.

If issue pickup has been on for two days and nothing at all has arrived from your Jira, the Jira card shows No issues received and your owners and admins are notified. That usually means the connection has not been added in Jira yet, or was added with a different address or secret. Open Configure for the details, then create or edit an issue in one of the chosen projects to check.

Picking up issues from LinearCopy Anchor Link

If your team tracks customer problems as Linear issues rather than in a support desk, Watari can read them the same way it reads a support ticket. This is off until you turn it on, because connecting Linear so Watari can file issues is not the same as asking Watari to read yours.

Before you startCopy Anchor Link

• Only an owner or admin of your Watari workspace can change these settings.
• Watari has to be installed as an app in your Linear workspace, and that takes a Linear workspace admin. The ordinary Linear connection is one person's own authorization, which is all filing issues needs. Picking up issues needs more: Watari becomes its own member of your workspace, so it can be delegated an issue and mentioned, and its comments are posted under its own name. Linear lets only a workspace admin approve that. The person who does it needs to be an owner or admin of your Watari workspace and an admin of your Linear workspace. It does not use a paid Linear seat.
• One Linear workspace can have Watari installed from one Watari workspace. If a teammate already installed it from another Watari workspace, ask an owner there to invite you instead.
• Give the people who file issues a format to follow. An issue with a title and one line is hard to find in code. The free bug report template lists the nine fields that matter.

Set it upCopy Anchor Link

1. Open Settings → Connected tools → Linear → Configure. If Watari is not installed as an app yet, the dialog says so and shows Install Watari in Linear. Press it, and approve the install in Linear, choosing the teams Watari may see. Your issue filing settings are kept, and issue pickup stays off until the next step.
2. Open Configure again and turn on Pick up issues from Linear. The pickup settings appear once it is on.
3. Choose the teams to read issues from. Only teams you gave the Watari app access to in Linear are listed. Watari reads nothing from a team you leave unticked.
4. Choose how issues are handed to Watari. You can combine these:
   • Delegate. Pick Watari from the assignee menu on an issue. The issue stays assigned to whoever owns it; Watari is added as the agent working on it.
   • Mention. Mention @Watari in a comment on the issue, choosing it from Linear's mention list.
   • A rule. Pick up issues once they match what you fill in: a status (for example Triage), a label, or a project. Leave the rule empty and it is off. A rule is checked when an issue is created and each time it is edited, so an older issue that matches is picked up the next time someone changes it. Keep the rule to a status or label your team applies on purpose.
   • Every new issue. Watari picks up each issue when it is created in one of those teams. Existing issues are never picked up this way, so switching it on does not pull in your backlog. Issues brought in by an importer keep their original dates and are not treated as new.
5. Save, then delegate one test issue to Watari. It answers on the issue within a few seconds, and the issue appears under Issues in Watari within a minute or two. Open the dialog again to see the Recent issues list: each issue Watari received, what your saved settings did with it and, for one that was skipped, why.

Delegating and mentioning work as soon as pickup is on, with nothing more to configure.

Typing @watariai as plain text does nothing. On Linear a mention is a real mention of the Watari app, chosen from the list.

When Watari asks a question on a Linear issue, reply on the issue and mention @Watari with your answer: Watari tries again with it, and its reply says so. A short question back, such as "status?", is not read as the answer; Watari replies with where the issue stands. When Watari stopped without a draft fix, or found the code and is waiting to draft, and you know where the problem is, mention @Watari in a comment with where to look: Watari starts again with what you wrote, exactly as a message sent to Watari from the issue page does, and its reply says so. This works the same on every tracker. A reply that repeats what the issue already says starts nothing, and Watari tries one issue at most five times in a day. A mention with nothing else in it, or one on an issue with a draft fix open or being written, gets a reply with where the issue stands (still working, a draft opened, or finished without a draft) and a link to it in Watari.

What Watari reads, and what it does notCopy Anchor Link

Once anyone in your Linear workspace has connected Watari, Linear sends Watari a notice whenever an issue there is created or changed. That is how Linear works for every connected app, and it is true of the ordinary filing connection too. Watari discards those notices on arrival and keeps nothing from them unless all three of these hold: Watari is installed as an app in your workspace, you turned pickup on, and the issue is in a team you chose. Inside a chosen team, an issue becomes a Watari issue only when someone hands it over or it matches your rule. Watari does not receive your comments, except the one comment in which someone mentions it.

An issue that reached Linear from outside your workspace, such as a customer request through Asks, a form, or an email to a team address, is not picked up by your rule on its own. Anyone who knows the address can send those, so Watari waits for someone on your team: add one of your rule's labels to the issue, or delegate it to Watari, and it is picked up. In Recent issues such an issue reads as skipped because it came from outside your team.

What happens nextCopy Anchor Link

Watari works on each issue it picks up the same way as on a support ticket. Questions that are not code defects get a suggested answer for your team instead of a draft fix. An issue counts toward your Mapped Issue allowance only if Watari finds it in your code.

When someone delegates an issue or mentions Watari, Watari replies on the issue straight away: that it picked the issue up, or why it did not and who can change that. It then comments as the issue moves (see What Watari's comments say). When the draft fix opens, Watari attaches its pull request to the issue as a link, whether your code is on GitHub or Azure Repos. After the fix ships, the customer update you approved in Watari is posted on the issue as a comment, for your team to pass on.

Some Linear issues are read outside your workspace: an issue synced with a GitHub issue or a Slack thread, one linked to a support conversation, or one a customer sent in. On those, Watari's comments leave out file names and links, and the customer update is not posted on the issue (it stays in Watari, marked skipped). The draft fix is still attached. You can turn Watari's progress comments off in the same dialog; Watari still answers a delegation or a mention, because the person who asked is waiting.

An issue Watari picked up is its own issue: Watari posts progress on it and does not file a second one beside it in Linear, even when issue filing to Linear is switched on. Issues Watari files for reports that came from somewhere else are never picked up as new reports, so the two features can run in the same team.

If an issue moves to another team, Watari keeps following it as the same issue. If it moves to a team you did not choose, later changes to it are no longer read.

If you connect a different Linear workspace, issue pickup is switched off and its team list is cleared, because those teams belonged to the previous workspace. If you remove Watari from your workspace in Linear, the Linear card in Watari says Linear stopped accepting Watari's sign-in, and your owners and admins are notified. Reconnect Linear installs Watari as an app again, so a Linear workspace admin has to approve it; your teams and rule are kept. To go back to a personal connection that only files issues, disconnect Linear first, then connect.

What Watari's comments sayCopy Anchor Link

On an issue Watari picked up, in Jira, Linear, GitHub or Azure Boards, Watari keeps its comments to what someone needs to read:

• When it picks the issue up: that it is looking for the cause in your code.
• When it finds the code: "Your move · Ready for a fix", and that a developer can reply on the issue mentioning Watari with where to look to start a draft fix, or ask for one in Watari.
• When it drafts a fix: "Your move · Review the fix", and that the fix is ready for an engineer to review. On a private project the comment links the pull request by name, for example "Review PR #110 on GitHub". If Watari first comments after the fix was already merged or closed, it says that instead of asking for a review.
• When the fix is merged: if your workspace waits for a deploy, "Shipping · Nothing needed from you", that the fix is merged and on its way to production, and that Watari will say on the issue when it is live.
• When the fix is live: once your deploy is confirmed, or when it merges if you do not wait for a deploy, that the fix is live and who updates the customer: "Your move · Update the customer" when someone on your team sends the customer update, or "Watari's move · Sending the customer update" when you already approved it and Watari sends it on its own. If the customer was already updated, or your team chose not to send an update, it says so.
• When the customer update is ready: on an issue only your team can see, the comment quotes the update Watari wrote and how to act on it from the issue. Reply @watariai send to send it as written, @watariai send: followed by your own text to send your version (25 to 120 words, the same limit as in Watari), or @watariai skip if no update is needed. On Linear, mention Watari the same way. If Watari writes the update after it already said the fix is live, it posts one more comment carrying it. Anyone whose comments Watari already trusts on that issue can do this, the same people who can answer Watari's questions there. Watari replies with what happened: sent, skipped, or why nothing changed (already sent, nothing to send yet). On an issue other people can read, the update stays in Watari and the comment says to send or skip it there.
• When the issue is done: once the fix is live and the customer update was sent or skipped, one last comment, "Done · Customer updated" or "Done · Closed, no update needed", and Watari closes the issue: closed as completed in GitHub, moved to your team's first Done state in Linear, to the work item type's Done (or Closed) state in Azure Boards, and through a transition into a Done status in Jira. When the Jira workflow needs something filled in on the way to Done, or the issue is a Jira Service Management request (closing one emails the portal customer), Watari only comments and leaves closing to you. An issue someone already closed is left as it is. To keep Watari from closing issues, turn off Close the issue when the customer is updated in the tool's Configure dialog.
• When it found nothing to change in the code: "Your move · Close it". The code already does what the report asks, or your team told Watari there is nothing to change, so the issue can be closed. If it still happens, a reply mentioning Watari with where to look starts it again.
• When it cannot find the code, or stops without a fix: "Your move · Needs an engineer", and what can happen next. When Watari stopped without a fix, anyone who knows where to look can reply on the issue mentioning Watari with the detail, and Watari tries again with it; the comment says how many tries are left. The next comment says who added detail (on an issue only your team can read) or that someone on your team did, never what they wrote. When it could not find the code, telling it where to look is a new code search, which an owner or admin starts in Watari.
• When it is missing one fact: "Your move · Watari asks", with its one question. Reply on the issue and Watari tries again with your answer. A short question back, such as "status?", is not taken as the answer: Watari replies with where the issue stands and the question it is still waiting on, and starts nothing.

A comment that hands the issue to a person always opens with Your move and the same step the issue page shows. Comments never carry scores, percentages or file paths; those are in Watari, one click away. Mentioning Watari again on an issue it already has, with detail, starts it again as described above; a mention with nothing else in it gets a short reply with where the issue stands and a link to it in Watari.

DisconnectingCopy Anchor Link

To disconnect any routing destination, go to Settings → Connected tools, click Configure on it, then click Disconnect at the foot of the dialog and confirm. Watari stops posting immediately. Disconnecting Linear also removes Watari's access in Linear, so it no longer appears in your assignee menu. Past issues, and any issues already filed in Linear or Jira, remain in those systems, Watari doesn't clean them up on disconnect. See Disconnecting integrations, token revocation and data retention windows for full details on token revocation and data retention.

---

Next: Events Watari receives and sends, the full list of what Watari listens for and what it sends out.