Issue trackers (Jira, Linear, Freshdesk, Odoo, TOPdesk)

Connecting a tracker lets FixControl create a ticket in your existing tracker for a FixControl issue and keep a link between the two. Engineers and support agents keep working in the tool they know; FixControl stays where intake, approvals and patches happen.

Five trackers are supported: Jira (Atlassian Cloud, and Data Center / Server through an API token), Linear, Freshdesk, Odoo Helpdesk, and TOPdesk. Freshdesk, Odoo and TOPdesk add a support layer on top: related-ticket history as evidence, governed customer replies, and (for Freshdesk) knowledge-base drafts.

How the link works

Be clear about the direction of each part, because it is deliberately narrow:

• FixControl creates tickets, outbound. A ticket is created when someone clicks Create support ticket on an issue, or automatically at intake if you switch that on (off by default, see below). Only BUG and FEATURE issues are mirrored.
• Inbound updates only touch issues that already mirror a ticket. For Jira, Freshdesk, Odoo and TOPdesk, an inbound webhook updates the cached tracker status on the linked FixControl issue. A new ticket created directly in your tracker does not create a FixControl issue, with one exception: Jira, when ticket import is switched on (see New Jira tickets as issues).
• Linear is outbound only. FixControl creates Linear issues and attaches delivered pull requests, but there is no inbound route from Linear.
• Ticket conversations are read into AI context only when you opt in (off by default, per tracker).
• Customer-visible replies need a person. For Freshdesk, Odoo, TOPdesk and Jira Service Management, a reply to the customer is only ever a draft until a person approves it, and only where you switched it on (off by default). Jira Software has no customer-visible replies.
• An inbound event never drives FixControl's workflow. A support agent closing a ticket cannot move the FixControl issue to done or start agents.

All tracker connections live under Settings → Channels → Issue tracker mirroring. You need to be an admin of your FixControl organization to connect one.

When a ticket is created

• Manually. Open a BUG or FEATURE issue and click Create support ticket. If the issue already has a ticket, the existing link is kept; no duplicate is created.
• From the intake card. In Slack or Teams, the card for a new issue offers a button to create the ticket.
• Automatically at intake (off by default). On the Freshdesk, Odoo or TOPdesk page, the Intake section has a switch such as Automatically create a Freshdesk ticket on Slack intake. With it on, an issue that arrives through Slack or Teams immediately gets a linked ticket. This is one setting for your whole organization.
• Importing an existing ticket. In Slack or Teams you can bring an existing Jira or Freshdesk ticket into FixControl from the card, for example by asking to import KAN-18.

If you connect more than one tracker, new tickets go to the most recently connected tracker that is working. A project's binding (a Jira project or Linear team on the project's Connections) decides where in that tracker the ticket lands.

If creating a ticket fails, the issue shows External ticket not created yet while FixControl retries, or Action required when the tracker refuses. Fix the connection and click Retry now.

Jira

Connect

• Sign in with Atlassian (recommended for Jira Cloud). Open Settings → Channels → Issue tracker mirroring → Jira, click Connect Jira, choose Sign in with Atlassian and click Continue with Atlassian. Atlassian asks you to grant read:jira-work, write:jira-work, read:jira-user and offline_access. Issues are attributed to your Atlassian user, and tokens refresh automatically.
• Email + API token (Jira Cloud, or self-hosted Data Center / Server). Create an API token in your Atlassian account, then choose Advanced: paste an email + API token and fill in Jira site URL, Atlassian account email, API Token and a Default project key (for example POS).

The OAuth app belongs to FixControl; you don't register one yourself.

What a Jira ticket contains

• The issue title and description.
• A priority mapped from FixControl's critical / high / medium / low.
• An issue type that matches the kind (bug or feature).
• Labels: fixcontrol, fixcontrol-<KEY> pointing back to the FixControl issue, and fc-* labels for severity, type, risk domain, affected system and source, so you can filter FixControl work in JQL.

The FixControl issue shows a deep link to the Jira ticket. When a patch is delivered, the pull request is linked back to the ticket.

Status sync back (inbound webhook)

1. On the Jira page, find Inbound webhook and click Generate webhook URL.
2. Copy the URL. It has the form https://<your FixControl address>/api/integrations/jira/webhook/<token>; the token at the end authenticates your organization.
3. In Jira, add a webhook for issue events that points at that URL.

Treat the URL as a secret. If it leaks, click Rotate token: the old URL stops working immediately, so update the Jira webhook right away.

What the webhook does is deliberately narrow:

• It syncs only the cached tracker status on an issue that already mirrors a Jira ticket. It never drives the FixControl workflow status.
• A reopen (a done ticket moving back to an open status) notifies your managers and adds a REOPENED flag on the issue: re-surface, never re-execute.
• Each update refreshes the related-support-history cache, so the next agent turn reads the current comment thread.

New Jira tickets as issues

With the webhook set up, a project can also turn new Jira tickets into FixControl issues. It is off until you switch it on, per Jira link:

1. Open the project's Jira link: in the support software wizard, or Manage on the project's Connections page, with New tickets selected.
2. Switch on Import new Jira tickets as issues. Changing it later needs an organization admin.
3. Make sure the Jira webhook includes the Issue created event.

A new ticket in the linked Jira project (or component) then becomes an issue in this project, with the ticket's summary, description, type and priority, linked to the ticket so its status keeps following. The same ticket never becomes two issues, tickets FixControl itself created in Jira are skipped, and a ticket that matches links on two different projects is not imported at all. Whether work starts on the issue is the project's own policy.

Optional Jira behaviour (off by default)

These Jira options have no switch in the settings screen today. Ask your FixControl contact if you want one switched on for your organization:

• Conversation into AI context. The linked ticket's recent comments (PII-scrubbed, Jira Service Management internal comments marked as notes) are added to the AI context. Read direction only.
• Capture learning. A ticket moving to a done status is stored as project-scoped learning (PII-redacted; only when the issue belongs to a project).
• Status push on resolve. Resolving the FixControl issue transitions the Jira ticket to a done status through its own workflow. A workflow without a matching transition shows as a visible sync failure.
• Mirror sent replies. A reply sent from a FixControl issue is copied onto the Jira ticket as a regular (internal) comment.
• Jira Service Management customer reply. Resolving queues a customer-visible reply draft in the communications review queue. It is posted as a portal reply only after a person approves it, and only for genuine Jira Service Management requests.

Resolved Jira work as evidence

During triage, FixControl pulls a small set of related resolved Jira issues as support-context evidence, each with why it matched and a trust score: evidence to weigh, not an authoritative answer. On Jira Service Management, internal comments are excluded from extracted resolutions, so internal text never leaks into agent context as a resolution.

Linear

Connect

• Sign in with Linear (recommended). Open Settings → Channels → Issue tracker mirroring → Linear, click Connect Linear, choose Sign in with Linear and click Continue with Linear. Linear asks you to grant read and write.
• API key. Create a personal API key in Linear, then choose Advanced: paste an API key and fill in the key and a Default team key (for example ENG).

What a Linear issue contains

Title, description, priority (mapped to Linear's scale) and labels, in the default team or the team bound to the project. Delivered pull requests are attached to the Linear issue.

Linear does not send anything back to FixControl: there is no inbound webhook, so status changes in Linear are not reflected on the FixControl issue.

Freshdesk

Freshdesk plays two roles: the support desk FixControl creates tickets in, and a source of support knowledge FixControl learns from. Freshdesk stays the system of record for the customer conversation.

Connect

1. In Freshdesk, copy your API key from your profile settings.
2. In FixControl, open Settings → Channels → Issue tracker mirroring → Freshdesk and add a connection:

Authentication failures (401, 403, 404) put the connection on reconnect; temporary 429 and 5xx errors are retried.

What a Freshdesk ticket contains

• Title → subject, body → description (converted to safe HTML), priority mapped to Freshdesk's 1-4 scale, and kind (BUG/FEATURE) to the ticket type.
• A link in both directions: the FixControl issue stores the ticket id and URL; the ticket carries the FixControl key (and, when your account's fields allow it, the custom fields cf_fixcontrol_key and cf_fixcontrol_url).
• A consistent tag set: fixcontrol, fc-severity-<priority>, fc-type-<bug|feature>, fc-domain-<domain>, fc-system-<system>, and fc-source-slack for Slack intake. Your own tags are kept; email- or phone-shaped values are never tagged.

Related support history (evidence)

When FixControl triages a new issue, it pulls a small set of related past tickets, preferring the fc-* tags, then derived search terms, then recent resolved tickets. Each one explains why it matched and carries a trust score, as evidence to weigh, never an answer that bypasses review. This history is kept separate from the docs knowledge base.

Resolved tickets → knowledge-base drafts

When a ticket is resolved, FixControl can turn the agent's public resolution reply into a pending knowledge-base draft. Quality gates skip short or generic resolutions, duplicates are detected, and a person approves the draft before anything is published.

Status sync back (inbound webhook)

By default FixControl reads a ticket's status when it needs it. To have Freshdesk push updates instead:

1. Ask your FixControl contact for the webhook URL and the webhook secret. The secret is managed by FixControl; without it the endpoint stays closed.
2. In Freshdesk, add an Automation rule ("Ticket is updated" → "Trigger webhook") that POSTs JSON to that URL, for example { "ticket_id": "{{ticket.id}}", "status": "{{ticket.status}}", "secret": "<the secret>" }. The secret may instead go in the x-freshdesk-webhook-secret header.

What the webhook does:

• It updates only the cached tracker status on an issue that already mirrors the ticket. It never drives the FixControl workflow status. An unknown ticket id is acknowledged and ignored.
• On resolve or close, it starts the same knowledge-base draft flow described above.
• Each update refreshes the related-support-history cache, so the next agent turn reads the current conversation.
• Reopen → re-surface, not re-execute. A ticket that goes back to open notifies your managers and adds a REOPENED flag. No agents are re-run.
• Resolve and reopen appear as milestones on the mission timeline.

Freshdesk options (all off by default)

On the Freshdesk page, under Inbound sync and Outbound sync, each option is a separate switch for your organization:

Inbound sync (Freshdesk informs FixControl):

• Feed the ticket conversation into the AI context. Recent customer replies and agent notes (emails and phone numbers redacted).
• Sync ticket priority onto the issue. Data only.
• Map ticket tags to issue flags (allowlist only). Only the tag=FLAG pairs you list ever map.
• Re-surface on negative customer satisfaction. Notifies your managers.
• Mark merged tickets as duplicates.
• Sync ticket assignment onto the issue. A responder email applies directly; otherwise your group → assignee map decides.
• Re-surface on (approaching) SLA breach. Notifies your managers; never re-executes.
• Capture resolved tickets as project learning. PII-redacted; tickets without a project are never captured.

Outbound sync (FixControl updates the ticket):

• Post mission progress as private notes. Agent-only notes; never visible to the customer.
• Move the ticket to Pending when the issue resolves. Never Resolved or Closed; support owns closing the loop.
• Reopen the ticket when a shipped fix regresses. With a private note.
• Raise ticket priority on critical escalation. Raise only.
• Draft a customer reply when the issue resolves. The draft goes to the communications review queue; it is posted as a public reply only after a person approves it.

Pushes are best-effort and one-way: a Freshdesk hiccup never blocks or rolls back a FixControl decision.

Boundaries

• Slack never calls Freshdesk directly. The flow is always Slack → FixControl intake → FixControl issue → (optionally) Freshdesk ticket.
• Deployment gates are unchanged. A Freshdesk link never relaxes an approval gate.
• Support history and the knowledge base stay separate. Retrieved ticket history is evidence; the knowledge base is human-approved.

Odoo Helpdesk

Odoo Helpdesk (odoo.com) works the same way as Freshdesk: the helpdesk stays the system of record for the customer conversation; FixControl creates and links tickets, reads their stage back, and learns from resolved work.

Connect

1. In Odoo, create an API key under your account security preferences.
2. In FixControl, open Settings → Channels → Issue tracker mirroring → Odoo and add a connection:

Helpdesk teams → projects

In a project's Connections, you can bind an Odoo helpdesk team to the project. When the inbound webhook sees a ticket whose issue has no project yet, the project is taken from that binding, and only from that binding. FixControl never guesses a project.

What an Odoo ticket contains

• Title → ticket name, body → description (converted to safe HTML), priority mapped to Odoo's 0-3 scale, and the default team when configured.
• After creating it, FixControl reads the ticket's stage back from Odoo; stages are free-form per team, so the label is never guessed.
• The FixControl issue key travels in the ticket description; the FixControl issue stores the ticket id and link.
• Odoo tags are not mirrored. FixControl does not create tag records in your Odoo.

Odoo options (all off by default)

On the Odoo page:

• Feed the ticket conversation into the AI context. Recent chatter, PII-scrubbed, internal notes marked as notes.
• Capture settled tickets as project learning.
• Post mission progress as internal notes. Never visible to the customer.
• Move the ticket to a stage you name when the issue resolves. Fill in Target stage name (for example "Awaiting confirmation"). With no stage named, nothing is pushed; tickets support already settled are left alone.
• Draft a customer reply when the issue resolves. The draft goes to the communications review queue; it is posted as a customer-visible chatter message (which Odoo e-mails to followers) only after a person approves it.

Status sync back (inbound webhook)

1. Ask your FixControl contact for the webhook URL and the webhook secret. The secret is managed by FixControl; without it the endpoint stays closed.
2. In Odoo, add an Automation rule on helpdesk tickets with a Send Webhook Notification action that POSTs to that URL. Send the secret in the x-odoo-webhook-secret header or as secret in the body.

The payload is treated as a trigger, never the source of truth: FixControl reads the stage back from the Odoo API. The same limits as Freshdesk apply: only the cached tracker status changes, a reopen re-surfaces (notifies managers, adds REOPENED) without re-running agents, and each update refreshes the related-support-history cache.

Related support history (evidence)

During triage, FixControl pulls a small set of related settled tickets as evidence, each with why it matched and a trust score. Only customer-visible messages from your team count as a resolution; internal notes, and anything that can't be classified, are excluded.

TOPdesk

TOPdesk (SaaS, https://<name>.topdesk.net) works the same way: the service desk stays the system of record for the incident and the caller conversation; FixControl creates and links incidents, reads their status back, and learns from resolved work.

Connect

1. In TOPdesk, sign in as the operator FixControl should act as and create an application password under your operator settings. Copy it; it is shown once. Note the expiry date (TOPdesk defaults to one year); an expired password puts the connection on reconnect.
2. Give that operator API access, read/create/edit rights on first- and second-line incidents, and read rights on Persons (used to resolve the caller).
3. In FixControl, open Settings → Channels → Issue tracker mirroring → TOPdesk and add a connection:

FixControl checks the connection by reading the current operator back. A 401 or 403 is reported as an authentication failure that needs a reconnect, usually an expired or revoked application password.

Operator groups → projects

In a project's Connections, you can bind a TOPdesk operator group to the project. When the inbound webhook sees an incident whose issue has no project yet, the project is taken from that binding, and only from that binding.

What a TOPdesk incident contains

• Title → brief description (TOPdesk caps it at 80 characters), body → request, and the operator group from the binding when there is one.
• New incidents are created as first-line incidents.
• The FixControl issue key goes in the external number field; the FixControl issue stores the incident number (for example I 2607 001) and a link.
• After creating it, FixControl reads the processing status back; status names are your own, so nothing is guessed.
• Priority, categories and labels are not mirrored. These are configuration in your TOPdesk; the FixControl priority stays readable in the request text.

TOPdesk options (all off by default)

On the TOPdesk page:

• Feed the incident's actions into the AI context. PII-scrubbed; actions hidden from the caller marked as internal.
• Capture settled incidents as project learning.
• Post mission progress as internal actions. Marked invisible to the caller.
• Complete the incident when the issue resolves. Optionally fill in Processing status name; with it empty, the incident is only marked completed. Incidents the service desk already settled are left alone.
• Draft a reply to the caller when the issue resolves. The draft goes to the communications review queue; it is added as an action the caller can see only after a person approves it.

Linking a customer

The incident's caller identifies the customer. Linking a customer to a TOPdesk-linked issue sets the caller on the incident.

Status sync back (inbound webhook)

TOPdesk has no webhooks an application can register for you, so you set up the callback yourself:

1. Ask your FixControl contact for the webhook URL and the webhook secret. The secret is managed by FixControl; without it the endpoint stays closed.
2. In TOPdesk, under Events & Actions, add an event on incident changes with an HTTP action that POSTs to that URL and sends the secret in a request header.

FixControl treats the payload as a trigger, never the source of truth and always reads the incident back from the TOPdesk API. The same limits apply: only the cached tracker status changes, a reopen re-surfaces without re-running agents, and each update refreshes the related-support-history cache. There is no scheduled polling, and attachments are not synced.

Related support history (evidence)

During triage, FixControl pulls a small set of related settled incidents as evidence. Only actions visible to the caller can count as a resolution; hidden actions, and anything that can't be classified, are excluded.

Reconnect

OAuth tokens refresh automatically. If a refresh fails (consent revoked, app removed), the connection shows Reconnect required and its health panel says why. Connect again and re-consent; existing links between issues and tickets are kept.

FAQ

Can one organization use both Jira and Linear? You can connect both, but new tickets go to one tracker: the most recently connected tracker that is working. Within that tracker, the project's binding decides the project or team.

Can I map custom Jira fields or statuses? Not in the settings screen. FixControl picks the issue type from the issue kind and, when the status push is switched on, a done transition from your own workflow. Ask your FixControl contact if you need something specific.

Can I stop mirroring? Yes. Turn off the automatic intake option, or remove the connection. Issues that were already mirrored keep their link; no new tickets are created.

Related: Integrations overview · Customer communication · Governance & policy