Daktela

Connect AI agents to Daktela, an omnichannel contact center and helpdesk platform. Agents open and resolve tickets, keep contact records in sync, create accounts, and read the activities, queues, and directory behind each conversation.

19 actions API key available

Daktela website ↗ Platform Documentation ↗ Capability data verified 2026-08-05

A scheduled run picks up an inbound request from a web form or an upstream system

Agent runs List Contacts to find the caller, and Create Contact only when no match exists

Agent runs List Activities for that contact to read the recent calls, emails, chats, and SMS behind the request

Agent runs List Ticket Categories and reads the SLA and outgoing queue configured on each candidate

Supervisor receives the proposed category, the queue it routes to, and the clock it starts

Supervisor confirms the category before Create Ticket puts the customer into a voice or SMS queue

What This Integration Enables

Daktela is a contact centre first, a helpdesk second, and the connector is honest about the difference. Activities in Daktela are the record of real customer contact across calls, emails, web chats, SMS, and messenger, and this connector reads them. It does not write them, because those events are produced by the telephony and channel layer rather than by an API caller. So an agent can assemble a complete picture of what a customer has already been through, filtered by ticket, channel type, queue, assigned user, or contact, and then act on that picture in the ticket layer where writes belong.

That leads to the second thing worth stating plainly. This connector has no customer visible send. Add Ticket Comment posts a comment activity onto the ticket timeline for the team, and there is no action here that emails, texts, or dials the customer directly. Outbound contact happens through Daktela's own queue routing, which is configured on the ticket category. Everything else is CRM hygiene and directory lookup: contacts and accounts can be created, contacts updated, and the directory of users, queues, ticket categories, and statuses read so an agent picks values that exist instead of guessing at them. Accounts and directory objects are read after creation rather than continuously edited, so treat Daktela as the system of record for routing configuration and something upstream as the system of record for company data.

Without FlowRunner

Channel history lives in four places Agents open a ticket without the calls, emails, chats, and SMS that led to it

Category is picked under time pressure The field that sets the SLA and the outbound queue is chosen in a hurry at intake

Contact records fork on every channel The same customer exists twice because the phone request and the web request were logged separately

With FlowRunner

One timeline assembled before the ticket opens List Activities pulls the cross channel history and attaches it as context

Routing consequences stated before the write The approver sees which queue and which SLA the chosen category commits to

Contacts matched before they are created The agent searches the CRM first and creates only what is genuinely new

Use Case Scenarios

Web form request that lands on the right queue

A request arrives through a website form. The agent runs List Contacts against the submitter's name and, finding a match, skips creation entirely and links the existing record. It then runs List Activities filtered to that contact, discovering two calls and a web chat in the past week about the same problem. Rather than opening a fresh ticket in isolation, it drafts one that references what already happened, runs List Ticket Categories to read the SLA and outgoing queue attached to each candidate category, and posts the proposal to a supervisor. Only after the supervisor confirms the category does Create Ticket run, and the customer lands in the queue that was actually chosen for them.

Ticket briefing before an agent picks it up

A ticket has been sitting in the Waiting stage. A scheduled agent runs Get Ticket for the current state, List Activities scoped to that ticket to gather every call recording summary, email, and chat attached to it, and Get Contact to pull the customer's CRM record. It composes a short brief covering what the customer has tried, which channels they used, and how long each stage has taken, and writes it back with Add Ticket Comment so the brief lives on the timeline rather than in a chat window. The next person to open the ticket reads the history in the place the history belongs.

CRM synchronisation from the system that owns the company

A new customer is signed in the upstream system and lands in a row in Google Sheets. An agent runs List Accounts to check whether the company already exists in Daktela, creates it with Create Account against the right CRM database when it does not, then runs List Contacts and Create Contact for each named person, linking them to the parent account. When a job title or name changes upstream, Update Contact keeps the person current. The contact centre stops asking callers to spell their company name because the record was already there, and a message goes to the operations channel in Slack summarising what was created.

Human-in-Loop Highlight

On most helpdesk connectors the risky call is the reply. On Daktela it is the category, because Daktela ticket categories carry SLA settings and outgoing queues, which means the category chosen on Create Ticket decides both how fast someone is obliged to respond and which channel the customer gets contacted through. Pick the wrong one and a billing question starts an outbound voice dial on a support SLA, or an urgent outage sits on a clock nobody is watching. So the agent does the research and stops before the write. It runs List Ticket Categories, reads the SLA and outgoing queue on each plausible option, and asks in Slack: "Inbound request from Marek Novak about a failed direct debit. Proposed category Billing Escalation, which routes to the outbound voice queue and starts a four hour SLA. Confirm, or choose another category?" A supervisor answers, and Create Ticket runs with a routing decision a person owns. This is what the digital andon cord looks like in a contact centre: the agent stops the line at the point where an irreversible routing commitment is about to be made, not after the customer's phone has already rung.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via Slack

Human decides

Agent resumes with decision

Agent Capabilities

19 actions

Tickets

List Tickets Retrieves a paginated list of helpdesk tickets, newest first, filterable by title search, stage, priority, category, assigned user, or linked contact. Used to build queue reports and to find the tickets a workflow should act on.
Get Ticket Retrieves a single ticket by its unique name, including stage, priority, category, assigned user, linked contact, and SLA fields. Used to check current state before any update.
Create Ticket Creates a helpdesk ticket with a required title, category, stage, and priority, optionally assigning a user, linking a CRM contact, and setting a customer email. The category carries SLA and outbound queue configuration, so this write commits a routing decision.
Update Ticket Updates an existing ticket by its unique name, changing only the fields supplied. Used to reassign, recategorize, move stage, or adjust priority as work progresses.
Close Ticket Closes a ticket by setting its stage to Closed. Used at the end of a resolution workflow, once the resolving action in the downstream system has actually succeeded.
Add Ticket Comment Adds a text comment to a ticket, recorded as a comment activity on its timeline. Comments are the connector's way of writing context back for the team; they are not a customer facing reply.

Activities

List Activities Retrieves contact centre activities across calls, emails, web chats, SMS, and other channels, newest first, filterable by parent ticket, channel type, assigned user, queue, or linked contact. This is how an agent reconstructs everything a customer has already been through before it acts.
Get Activity Retrieves a single activity by its unique name with its type, title, description, user, queue, contact, and parent ticket. Used to read one specific interaction in full.

Contacts

List Contacts Retrieves a paginated list of CRM contacts, filterable by a search term against full name or by parent account. Used as the duplicate check before any contact is created.
Get Contact Retrieves a single CRM contact by its unique name with full name, database, parent account, and description.
Create Contact Creates a CRM contact, requiring a full name, last name, and CRM database, optionally linking a parent account. Used only after a search has established the person is genuinely new.
Update Contact Updates an existing CRM contact by its unique name, changing only the fields supplied. Used to keep names, titles, and account links current with an upstream system of record.

Accounts

List Accounts Retrieves a paginated list of CRM accounts, filterable by a search term against the account title. Used to check whether a company already exists before creating it.
Get Account Retrieves a single CRM account by its unique name with its title, database, assigned user, and description.
Create Account Creates a CRM account against a required CRM database. Used when a new customer company appears upstream and needs a parent record for its contacts.

Frequently Asked Questions

What can FlowRunner do with Daktela?

FlowRunner agents can run List Tickets, Get Ticket, and Create Ticket in Daktela, plus 16 more actions.

Does connecting Daktela to FlowRunner require OAuth?

No. Daktela connects to FlowRunner with an API key, no OAuth flow required.

Can Daktela trigger a FlowRunner workflow automatically?

Daktela doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Daktela

$100 in credits. No card required. Connect in minutes.

Start Building Free Talk to us