Connect Jira

Use this when your support desk lives here and your engineers live in Jira. A ticket can be sent to Jira as an issue, and from then on the ticket reports what Jira says about it, so nobody has to keep two queues in step by hand.

Connect it

1. 1Open Markedsplads from the sidebar and choose Jira.
2. 2Select Forbind Jira and sign in with Atlassian. You will be asked to approve what we may do; we only ever act as the account that signs in.
3. 3If your Atlassian account can reach more than one Jira site, the page asks which one to use under Vælg hvilket Jira-site der skal bruges. Pick the site your support work actually lives in. With only one site, it is chosen for you.
4. 4On Hvad synkroniseres, set Projekt and Sagstype. This is where a pushed ticket is created.

Connecting is not configuring. See Connect an integration. Until a project is chosen there is nowhere for a ticket to go, and the page says so.

Which way things flow

This is the part worth understanding before you switch anything on, because it is deliberately not symmetrical.

Jira decides the state of a linked ticket. When an engineer moves the Jira issue, the ticket moves with it. Moving the ticket here does not move the Jira issue. That is on purpose: if both sides could push status at each other, one change would bounce back and forth and neither would be trustworthy. One owner per fact, and for engineering state that owner is Jira.

This side keeps the customer conversation. Replies to the customer, the requester, the subject: those stay here and are not Jira's business.

The switches under Hvad der kommer tilbage fra Jira let you choose how much of that happens:

• Flyt sagen når Jira-sagen flyttes is the main one. Leave it on unless you want the link to be a reference only.
• Kopiér Jira-kommentarer over på sagen som interne noter brings Jira comments in as internal notes, so your agents see the engineering discussion without it ever reaching the customer.
• Kopiér interne noter fra sagen ind i Jira-sagen is off by default. Turn it on only if your engineers genuinely read Jira rather than the ticket.
• Opret automatisk en Jira-sag for hver ny sag is off by default, and worth thinking about before turning it on. Every ticket becoming a Jira issue includes the ones that were a password reset.

Matching Jira statuses to yours

Your ticket statuses are your own (you can rename them and add your own, see Set up the support desk), so there is no list we could match to Jira for you. Until you map them, a Jira status is read by its category: Jira's "To Do" and "In Progress" keep the ticket open, and "Done" resolves it. That is usually right, and it is worth setting explicitly if you have statuses that matter, like a waiting-on-customer step.

What to expect

• One Jira issue per ticket, and one ticket per issue. A ticket cannot be pushed twice, which is what stops one Jira transition moving two tickets.
• Disconnecting stops the flow, it does not undo anything. Tickets already linked keep their link and their history, so reconnecting picks up where you left off.
• We act as the person who connected. If that account loses access to the project in Jira, the sync stops and the page asks you to sign in again. Connecting with a service account rather than an individual is worth doing if people move around.

If it is not in your list

Jira is enabled per company. If you cannot see it, one of three things is true: it is not switched on for your company, your role cannot reach the marketplace, or the connection has not been set up for your region yet. Those have different answers, so it is worth telling them apart. Connect an integration explains how.