Teamwork Desk
Helpdesk & ITSMConnect AI agents to Teamwork Desk, the shared inbox and ticketing product from Teamwork. Agents open and update tickets, keep customer records current, and read the desk configuration behind routing.
What This Integration Enables
Teamwork Desk is the shared inbox half of a product suite built around client services work, and that origin shows in what the connector is good for. Tickets carry an inbox, a status, a priority, a type, tags, an assigned agent, and a customer, and each of those is either set on creation or moved afterwards through a dedicated call. Change Ticket Status and Assign Ticket exist as single purpose actions alongside the general Update Ticket, which is a small design detail with a real consequence: an agent can move a ticket's state without risking an accidental overwrite of the subject or the inbox, because the call it uses cannot touch them.
The customer surface is properly searchable rather than an afterthought. Search Customers matches on name, email, and organization, Get Customer returns the full profile including organization, job title, phone numbers, and notes, and Create Ticket will accept either an existing Customer ID or a bare email address, creating the customer when the address is new. That means intake never stalls on a missing record. The configuration reads, List Inboxes and List Agents and List Tags, are exactly that, reads: they let an agent resolve a valid inbox, agent, or tag before a write instead of hardcoding IDs that go stale when the desk is reorganised. Routing itself happens through Assign Ticket and Change Ticket Status, driven by values those reads returned.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Client email answered with the account history attached
A ticket arrives in the client services inbox. The agent runs Get Ticket with the message thread included, then Search Customers on the sender's email to pull their organization and job title. It checks the client's open work in ClickUp and finds two deliverables in progress, one of them the subject of the email. It drafts a reply that answers the actual question with the current status of that deliverable, and stages it with Reply To Ticket as a draft. The account owner opens the ticket, sees a draft that already knows what the client is waiting on, and releases it.
Triage that routes without touching the customer
Overnight tickets land across three inboxes. A scheduled agent runs List Tickets per inbox, reads each with Get Ticket, and classifies. For each one it runs Assign Ticket to the agent who owns that client, resolved from List Agents, and Change Ticket Status to move it out of the unassigned state. Where the ticket needs internal context, it uses Reply To Ticket with Private Note enabled so the note is visible to agents only and the client sees nothing. Nothing customer facing happens in this pass at all: the queue is sorted, owners are set, and the humans start the day with tickets that already belong to someone.
Escalation opened from a monitoring signal
A monitoring alert fires for a client's integration. Rather than emailing the account manager, the agent runs Search Customers to resolve the client's primary contact, then Create Ticket in the escalations inbox with that customer's email, a subject naming the affected integration, a high priority, tags resolved from List Tags, and the alert detail in the initial message. It assigns the ticket with Assign Ticket to the on call engineer and posts the ticket link to the incident channel in Slack. The escalation exists as a ticket with an owner and a clock before anyone has had to write it up.
Human-in-Loop Highlight
Reply To Ticket on this connector sends to the customer by default. The internal note is the opt in: Private Note is a flag you have to remember to set, and a flow that forgets it, or that computes it from a condition that evaluates the wrong way once, emails a client the internal reasoning it meant to keep to itself. That is the single most dangerous field in this connector, and it is one boolean on one call. Fortunately Teamwork Desk ships its own answer, and the right design uses it rather than inventing one: Reply To Ticket can be sent as a draft. So the agent writes the reply into the ticket as a draft, where the account owner reads it in context alongside the customer's message and the ticket history, and asks for a decision in the channel the owner already lives in: "Draft reply staged on ticket 4471 for Hannah Mercer at Northgate Retail about the delayed integration cutover. It quotes a new go live date of 22 September. Open the ticket to release it, or reply here and I will revise it." No message leaves the desk until a person releases it, and the draft state means the approver is reviewing the actual thing that will send rather than a copy of it pasted into chat. That is human-in-the-loop done with the vendor's own grain: the safest gate is usually the one the product already built.
Agent Capabilities
15 actionsTickets
8- List Tickets Retrieves a paginated list of tickets with filters for inbox, status, priority, type, and assigned agent, plus ordering controls. This is the polling path that stands in for event delivery on this connector.
- Get Ticket Retrieves the full details of a single ticket including subject, status, priority, type, inbox, customer, and assigned agent, optionally including the full message thread. Used to read the whole exchange before drafting.
- Search Tickets Full text search across tickets by subject, message content, customer details, and ticket number, with pagination. Used when you have a keyword or a customer detail rather than a ticket ID.
- Create Ticket Creates a ticket in an inbox with an initial message, identifying the customer by either an existing Customer ID or an email address, optionally setting priority, type, assigned agent, and tags. A new email address creates the customer, so intake does not stall on a missing record.
- Update Ticket Updates a ticket's subject, status, priority, type, inbox, and assigned agent, changing only the fields supplied. Use the dedicated status and assignment actions when those are all you mean to change.
- Change Ticket Status Changes the status of a single ticket, for example to Active, On Hold, Waiting, or Closed, using a status ID or state name resolved from the statuses picker. Single purpose, so it cannot accidentally overwrite anything else on the ticket.
- Assign Ticket Assigns a ticket to a specific Desk agent, or unassigns it. Used in triage to give every overnight ticket an owner before the day starts.
- Reply To Ticket Adds a message to a ticket. By default the reply is sent to the customer; enabling Private Note makes it an internal note visible only to agents. The reply can also be staged as a draft and attributed to a specific agent. The default is customer facing, which is why the draft option is the right foundation for an approval gate.
Customers
4- List Customers Retrieves a paginated list of customers in the account. Used for reconciliation sweeps against a CRM.
- Get Customer Retrieves a customer's full profile including name, email, organization, contact details, and timestamps. Used to attach who the client is to a ticket before anyone answers it.
- Search Customers Full text search across customers by name, email, and organization, with pagination. Used to resolve a client from a sender address or a company name when you do not have their ID.
- Create Customer Creates a customer with at minimum an email address, optionally setting name, organization, job title, phone numbers, and notes. Used when onboarding a new client contact ahead of their first ticket.
Desk Configuration
3- List Inboxes Retrieves the inboxes configured in the account with their name and email address. Read only. Used to resolve a valid inbox ID before creating a ticket or scoping a query.
- List Agents Retrieves the Desk agents with their names and emails. Read only. Used to resolve a valid assignee for Assign Ticket rather than hardcoding an ID.
- List Tags Retrieves the tags defined in the account. Read only. Used to apply an existing tag when creating a ticket; tags themselves are managed inside Desk. --- The Teamwork Desk connector exposes no FlowRunner triggers, so nothing here listens for new tickets or new customer replies. Reactive flows run on a schedule that calls List Tickets scoped to an inbox and status, or Search Tickets when the signal is a keyword, and diffs each run against the previous one. List endpoints are paginated with page and page size, with a maximum page size of 500 on most collections, so a full sweep should page rather than assume one call covers the queue.
Frequently Asked Questions
What can FlowRunner do with Teamwork Desk?
FlowRunner agents can run List Tickets, Get Ticket, and Search Tickets in Teamwork Desk, plus 12 more actions.
Does connecting Teamwork Desk to FlowRunner require OAuth?
No. Teamwork Desk connects to FlowRunner with basic authentication (a username and password), no OAuth flow required.
Can Teamwork Desk trigger a FlowRunner workflow automatically?
Teamwork Desk doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Teamwork Desk
$100 in credits. No card required. Connect in minutes.