Issues and ticket tools

When you approve a journey report, each priority becomes an issue with its own number, such as UXR-12. Open Issues in the organisation menu to see them all. An issue keeps what to change, where, why it matters, how to measure it, the page it is on and its history: the run that found it, every later check, and who shipped, dismissed or reopened it.

• Open: the problem still needs a fix.
• Shipped, waiting for a check: your team says the fix is live. The next check confirms it.
• Verified fixed: a run or spot check saw the change on the live website, with a screenshot.
• Dismissed: your team decided not to fix it. Later runs do not check it.

The history also shows New wording is live when the page timeline finds an issue’s proposed wording on its page. That is a prompt to check, not a verdict.

Filter the list by status, then select an issue to see its details and history. Select Mark shipped when a fix is live, Dismiss for something you will not fix, and Reopen to bring a fixed or dismissed issue back. Screenshots from each check appear in the history beside the verdict.

Open an approved journey analysis and select Run this journey again. UX Robot copies the brief into the same project with the last 28 completed days of evidence and keeps the earlier report untouched. Start autopilot once the changes you want to test are live.

1. The new run carries every open and shipped issue for that journey, and the five most recently fixed ones so a fix that came undone is caught, up to 15 in all.
2. The desktop agent checks each one as the journey reaches its page and captures the same area. It must cite a screenshot for every verdict, or say why it could not check.
3. The report opens with Since the last run: each earlier issue marked Fixed, Partly fixed, Still there or Not checked, with Came back for a fix that came undone. Priorities that continue an earlier issue show its number.
4. Approving the report updates every issue: fixed issues are verified, shipped issues that are still there reopen, and new problems become new issues. The stakeholder summary reports the progress.

A spot check looks only at chosen issues on the live website, without repeating the journey or writing a report. It is requested through UX Robot’s MCP tools, usually by the coding agent that made the fix, and carried out by any connected agent that can control a browser. The agent opens each page, captures the area and records whether the issue is fixed, partly fixed or still there. The verdict and screenshot go into the issue’s history, and a linked ticket gets a comment.

Spot checks use no analysis unit. See Coding agents and MCP for how to request one.

Each organisation connects one ticket tool at the top of the Issues page. Anyone who can edit the organisation can connect it. You approve access on the tool’s own page; UX Robot never sees your password.

• Jira Cloud: select Connect Jira, approve access, and choose the Jira site if you have more than one. The account you connect needs permission to create issues in the project.
• Azure DevOps: select Connect Azure DevOps and sign in with your work Microsoft account. Your Azure DevOps organisation must use Microsoft Entra ID, as most company organisations do. If your company limits which apps people can approve, an administrator approves UX Robot once.
• Linear: select Connect Linear and approve access to your workspace.
• GitHub: first install the UX Robot GitHub app on the repositories you want, then select Connect GitHub. UX Robot can reach only those repositories, and only their issues.

Then choose where tickets go: a project in Jira and Azure DevOps, a team in Linear, or a repository in GitHub. Jira and Azure DevOps also ask for the ticket type, such as Bug or Task. Use Change project to send later tickets somewhere else, and Disconnect to stop. Tickets already created keep their links when you disconnect.

Open an issue and select Send to Jira, Send to Azure DevOps, Send to Linear or Send to GitHub. Each issue is sent once, and the issue then shows the ticket’s number and status. The ticket gives a developer everything without opening UX Robot:

• where UX Robot found it, what to change, where, and why it matters;
• the proposed change from the after picture, such as In the restaurant card, change “Call” to “Call 03 9650 5525”;
• how to measure it, the evidence, and when it counts as done;
• a link back to the issue in UX Robot.

Jira issues get the labels ux-robot and the issue number; Azure DevOps work items get the tags UX Robot and the issue number and a link; GitHub issues get the ux-robot label.

• Every 15 minutes, UX Robot reads the status of each linked ticket. When a ticket is moved to done, or closed as completed in GitHub, its issue becomes Shipped, waiting for a check.
• When a run’s report is approved, or a spot check finishes, UX Robot comments on each linked ticket with what it found: verified fixed, still there, partly fixed, or came back. Each result is commented once.
• UX Robot creates tickets and comments on them. It never edits, moves or closes them; your team stays in charge of its board.

Alerts tell a channel when something changes, so the team hears about a fix that worked, or one that came back, without opening UX Robot. Set them up in the Alerts panel on the Issues page. Anyone who can edit the organisation can add up to five channels.

• Journey reports approved: the run’s new issues, the ones verified fixed, the ones that came back after being fixed, and the ones still there, with links to the report and the Issues page.
• Spot checks finished: each checked issue and its verdict.
• Monthly impact summary: from 9am on the 1st in the organisation’s timezone, last month’s verified fixes, new issues, fixes that came back and what is still open. See the impact dashboard guide.

Slack: create a Slack app for your workspace at api.slack.com/apps, open Incoming Webhooks and turn it on, select Add New Webhook to Workspace, choose the channel, and copy the URL. It starts with https://hooks.slack.com/services/. Then select Add Slack channel in UX Robot and paste it.

Microsoft Teams: in Teams, open the channel’s More options (…) menu, choose Workflows, and pick the Send webhook alerts to a channel template. Name it, confirm the team and channel, save, and copy the URL the workflow gives you. Then select Add Teams channel and paste it. Teams’ older Incoming Webhook connector has been retired, so UX Robot accepts only Workflows URLs.

UX Robot sends a test message as soon as a channel is added; use Send test to try again later. Each channel shows when it last received an alert, or why the last one failed. When Slack or Teams is briefly unavailable, an alert is tried twice more over the next few minutes.

UX Robot stores each connection’s access encrypted and renews it automatically before it expires. It asks only for what it needs: Jira’s read and write access to issues, Azure DevOps access as the signed-in person, Linear read and write, and GitHub’s Issues permission on the repositories where the app is installed. If a tool stops accepting the connection, for example because someone revoked it, the Issues page asks you to reconnect.

To remove access completely, select Disconnect on the Issues page, then revoke UX Robot in the tool: Atlassian account settings for Jira, the Microsoft account or Entra admin center for Azure DevOps, Linear’s workspace settings, or the GitHub app’s installation settings.