Tiflux
Helpdesk & ITSMConnect AI agents to Tiflux, an IT service management and helpdesk platform. Agents open and resolve tickets end to end, communicate with the requester, and route between desks, stages, and agents.
What This Integration Enables
Tiflux is an ITSM platform built around the desk, and the connector treats the desk as the unit that matters. Desks are the queues that organise tickets, and stages, priorities, and service catalogs are scoped to them, which means a ticket's stage and priority are only meaningful relative to the desk it currently sits on. The connector exposes that structure directly through List Desks, Get Desk, List Stages, and List Priorities, all of which are desk scoped, so an agent resolves the workflow steps and urgency values of the destination before moving anything into it rather than assuming they match.
The ticket lifecycle here is unusually explicit, and that explicitness is the connector's strongest feature. Close Ticket and Cancel Ticket are different operations with different meanings: one resolves the request, the other ends it without resolving it. Reopen Ticket brings back either. Communication is split just as clearly, with Answer Ticket posting a public answer sent to the requestor, optionally with the agent's signature appended, and Create Internal Communication posting a private note only agents see. Both sides are readable too, through List Ticket Answers, Get Ticket Answer, and List Internal Communications, and Get Ticket History returns the chronological timeline of status changes, stage transitions, and assignments. Client records and their contacts round it out, with Create Client, Update Client, and Create Client Contact keeping the company side current. Descriptions and answers accept Markdown, which Tiflux converts to HTML, so an agent can write structured text without hand assembling markup.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Stalled ticket review that does not quietly bury anything
Every Monday an agent runs List Tickets scoped to a desk and filtered to tickets untouched for more than two weeks. For each one it runs Get Ticket History to see how the request actually moved, and List Ticket Answers to establish whether the requestor was ever answered at all. That distinction drives everything: a ticket with no public answer and no activity is not a stale ticket, it is a person who was never helped. The agent sorts the batch into three groups, records its reasoning on each ticket with Create Internal Communication, and sends the supervisor a list where the cancel candidates are the smallest group and every one of them is justified.
Ticket opened from an upstream alert with the client already linked
A monitoring alert fires for a managed client. The agent runs List Clients to resolve the company, List Client Contacts to find the technical contact who should be the requestor, and List Desks and List Stages to place the ticket on the infrastructure desk at the right starting stage. Create Ticket opens the request with a Markdown description containing the alert detail, the affected service, and the runbook link, sets the responsible agent from List Users, and adds the account manager to the followers. A summary posts to the operations channel in Slack with the ticket number.
Client and contact records kept current from the source system
When a contract is signed upstream, an agent runs List Clients to check whether the company already exists in Tiflux, creates it with Create Client using the trade name and legal name when it does not, and adds each named person with Create Client Contact including their email, phone number, and usage type. When a company's legal name or document number changes, Update Client applies it. Because requestors on tickets can be identified by email, keeping contacts current is what lets intake link a request to the right client automatically instead of dropping it into a general queue.
Human-in-Loop Highlight
Tiflux is one of the few help desks that distinguishes closing a ticket from cancelling one, and that distinction is exactly where an agent needs to stop. Close Ticket marks a request resolved. Cancel Ticket marks it canceled without resolving the underlying request, which is a legitimate outcome when a requestor withdraws something, and a quiet failure when a backlog sweep uses it to make old tickets go away. The difference never shows up in the ticket count, only in whether a person got help, so an automated cleanup that reaches for Cancel Ticket is an automated way of losing customers without appearing to. The agent therefore treats cancellation as the one outcome it may never choose alone. It assembles the evidence, runs List Ticket Answers to prove whether the requestor was ever answered, writes its reasoning to the ticket with Create Internal Communication so the record survives the decision, and asks: "Ticket 20841 on the Infrastructure desk has been in Aguardando for 34 days with no public answer and no requestor activity since it was opened. Cancel it, answer it, or transfer it to the Redes desk?" A second gate belongs on desk transfers through Update Ticket, because stages and priorities are scoped per desk: a ticket moved to another desk arrives carrying a stage and priority that were defined somewhere else, so the agent reads List Stages and List Priorities for the destination and shows the proposed mapping before the move. Both gates are the digital andon cord in the same place, at the moment where an automated tidy up is about to overwrite a human commitment.
Agent Capabilities
26 actionsTickets
7- List Tickets Retrieves a paginated list of tickets with filters for desk, client, stage, responsible agent, requestor, priority, catalog item, status, and date range. Supply at least one filter beyond status so a sweep does not pull the entire ticket base. This is the polling path that stands in for event delivery on this connector.
- Get Ticket Retrieves the full details of a single ticket by its ticket number including title, description, status, stage, priority, client, requestor, responsible agent, and SLA information.
- Create Ticket Opens a ticket on a desk, requiring a title and a description that accepts Markdown, optionally setting client, desk, priority, catalog item, requestor by ID or email or name, responsible agent, and follower emails. Used to turn an upstream signal into a request with an owner and a clock.
- Update Ticket Updates title, description, stage, priority, status, responsible agent, requestor, catalog item, or followers, changing only the fields supplied. Changing priority without transferring desks requires a priority change reason, which is the vendor's own way of insisting a reprioritization is justified. Desk transfers move a ticket between queues whose stages and priorities are defined separately, so they belong behind an approval step.
- Close Ticket Closes an open ticket by its ticket number, marking the request resolved. This is the outcome that says a person was helped.
- Cancel Ticket Cancels a ticket by its ticket number, marking it canceled without resolving the underlying request. Because a cancelled ticket leaves the queue without anyone having been helped, this is the action that sits behind the approval gate.
- Reopen Ticket Reopens a previously closed or canceled ticket, returning it to an active state. Used when a requestor comes back or when a cancellation turns out to have been wrong.
Ticket Communication
6- Answer Ticket Posts a public answer to a ticket that is sent to the requestor, with Markdown converted to HTML and the agent's signature optionally appended. This is the customer facing write on this connector.
- List Ticket Answers Retrieves the paginated public answers on a ticket with author, timestamp, origin channel, and content for each. Used to establish whether a requestor was ever actually answered, which is the question a backlog review turns on.
- Get Ticket Answer Retrieves a single answer with its author, timestamp, origin channel, full content, and attached file count.
- Create Internal Communication Adds a private, agent only note to a ticket. This is where an agent writes its research and its reasoning, because nothing here reaches the requestor.
- List Internal Communications Retrieves the private agent only notes recorded on a ticket with author, timestamp, and content. Used to read what colleagues have already established before adding to it.
- Get Ticket History Retrieves the chronological timeline of a ticket including status changes, stage transitions, assignments, and other recorded events. Used to understand how a request actually moved rather than only where it ended up.
Clients and Contacts
6- List Clients Retrieves a paginated list of clients with their ID, trade name, and legal name. Used as the existence check before creating a company.
- Get Client Retrieves a single client with trade name, legal name, status, and registered document number.
- Create Client Creates a client company, requiring the trade name and legal name. Used when a new customer is signed in the upstream system.
- Update Client Updates an existing client's trade name, legal name, or document number, changing only the fields supplied.
- List Client Contacts Retrieves the contacts registered under a client with each contact's owner, email, and phone number. Used to find the right requestor for a ticket opened on the client's behalf.
- Create Client Contact Creates a contact under a client, requiring owner name, email, phone number, and usage type, with an optional country code for international numbers. Keeping contacts current is what lets intake match a request to the right client automatically.
Desks, Stages and Priorities
4- List Desks Retrieves the desks configured in the account. Desks are the queues that organise tickets, stages, priorities, and service catalogs, so this is the first read in almost any Tiflux flow.
- Get Desk Retrieves a single desk by ID with its name and configuration.
- List Stages Retrieves the stages defined for a specific desk, representing the workflow steps a ticket moves through there. Scoped per desk, so read the destination's stages before proposing a transfer.
- List Priorities Retrieves the priorities configured for a specific desk, which determine urgency and SLA handling. Also scoped per desk, which is why a transfer changes what a priority means.
Users and Groups
3- List Users Retrieves the agents and attendants in the account, with an optional name filter. Used to resolve a valid responsible agent before a ticket write.
- Get Current User Retrieves the profile of the user that owns the API token in use, including ID, name, email, and role. Useful for confirming which identity a flow is operating under.
- List Technical Groups Retrieves the technical groups configured in the account, which organise agents for routing and assignment. Used to understand who a desk's work is meant to reach. --- The Tiflux connector exposes no FlowRunner triggers, so nothing here listens for new or updated tickets. Reactive flows run on a schedule against List Tickets, which uses offset as a page number starting at 1 and a limit between 1 and 200 with a default of 20. Supply at least one filter beyond status, scope the sweep to a desk, and diff each run against the previous high water mark rather than assuming a single page covers the queue.
Frequently Asked Questions
What can FlowRunner do with Tiflux?
FlowRunner agents can run List Tickets, Get Ticket, and Create Ticket in Tiflux, plus 23 more actions.
Does connecting Tiflux to FlowRunner require OAuth?
No. Tiflux connects to FlowRunner with an API key, no OAuth flow required.
Can Tiflux trigger a FlowRunner workflow automatically?
Tiflux doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Tiflux
$100 in credits. No card required. Connect in minutes.