Incidents linked to TOPdesk, caller replies held for approval
FixControl creates and links incidents in TOPdesk and reads their processing status back, so the service desk stays the system of record for the incident and the conversation with the caller. A reply to a customer of your organization is drafted by AI and held until someone on your team approves it — only then is it posted as an incident action the caller can see.
What the TOPdesk connection covers
Incident create and link
An approved FixControl issue becomes a first-line TOPdesk incident: title as the brief description, body as the request, and the operator group from the project binding when one is configured. The FixControl issue key travels in the incident’s external number; the issue keeps the incident number and a deep link.
Processing status read back, never guessed
Processing statuses are configured per TOPdesk instance, so FixControl reads the incident’s status back over the API instead of assuming a name. Resolving an issue marks the incident completed and, where you named one, sets the processing status you chose — an incident the service desk already settled is left alone.
Approved caller-visible replies
Resolving an issue can queue a reply draft in the review queue. A person approves it, and only then is it posted as an incident action visible to the caller. Reject or escalate posts nothing.
Operator-only progress notes
Engineering progress — a patch ready, a pull request opened, with its link — can be posted as incident actions marked invisible to the caller. Operators only, and one-way.
The caller identifies the customer
On a TOPdesk incident the caller plays the role a requester plays on a helpdesk ticket. Linking a customer to a TOPdesk-linked issue sets the caller on the incident, so the customer record and the incident agree on who is asking.
Settled incidents as evidence
Triage pulls a scoped set of related settled incidents, each with why it matched and a trust score, to weigh rather than to trust blindly. Only actions visible to the caller can count as a resolution; actions marked invisible to the caller are excluded, fail-closed.
Which TOPdesk paths are working, shown per path
Creating an incident, posting a caller-visible reply, writing an operator-only note, pushing a status and setting the caller are separate write paths with separate requirements, and each records its own health. A working incident create can never disguise a broken reply path behind one connected badge.
Reads incidents, their processing status and their actions within the linked project, to build support context and answer questions.
Creates and links first-line incidents under the application password of the operator you nominate. An operator group bound to a project routes incoming incidents deterministically — FixControl never guesses a project.
Off by default and switched on per organization; even then the draft is held until a person approves it. Caller-visible actions and internal ones share one action stream and differ only in a visibility flag, which is exactly why the visible one sits behind the approval flow.
Off by default. Where enabled, progress is posted as an action marked invisible to the caller — for operators and engineers, never in the caller’s view.
Off by default. Resolving marks the incident completed, and sets a processing status only when you name one from your own instance’s list — FixControl never invents a status name.
Linking a customer looks the person up on an exact e-mail match and only proceeds on a single hit. No match, or more than one, is a visible failure — FixControl never creates a person record in your instance to make a link succeed.
Needs a configured shared secret and an Events & Actions HTTP action you author yourself; without the secret the endpoint is disabled. The incident is then always read back over the API.
Not mirrored. Priority, urgency, impact, category and subcategory are configuration records in your own instance, a TOPdesk incident has no free-form label field, and attachments are not synced. The FixControl priority stays readable in the incident request text.
Your callback is a trigger, not the truth
Questions about the TOPdesk integration
Does FixControl reply to callers automatically?+
What keeps an internal note from reaching the caller?+
Which permissions does the TOPdesk operator need?+
How do updates from TOPdesk reach FixControl?+
Are priority, categories and attachments mirrored?+
Watch a TOPdesk reply wait for approval
Book a demo: an issue resolves, AI drafts the reply on the linked incident, and the caller-visible action waits until someone approves it.