Customer support

It reads the queue. It cannot answer a customer

Zendesk is read-only in Aestus: six operations read tickets and organizations; the other six, including the reply to a customer, are refused.

Not open yetThe Zendesk integration is not yet available to external organizations. This guide describes the intended experience; availability will be updated when access is ready.

Join the waitlist See the Zendesk example

Zendesk with Aestus

Keep the tool. Change what the team can see.

Aestus already ships a watch over escalations, and it deliberately does not touch Zendesk. It reads the work that lives in Aestus, because declaring a connection the graph cannot actually reach would put a logo in front of a read that does not happen. That decision is the reason this page exists: the capability gap is a real one and it is better named than papered over.

So what can you do now? Connect the instance, decide by policy whether workflows may reach it at all, and write the graph yourself. A queue summary is pure reading and costs nobody an interruption. Anything that speaks to a customer is held, because a support reply sent by a machine that nobody read is the specific failure every support team fears.

One design note for whoever builds it. Triage has two halves that are worth keeping apart: working out the likely owner and priority, and applying them. The first half is safe to run every few minutes. The second changes what a person sees when they open their queue, and belongs behind a decision.

Good first workflows

Spot what keeps coming back
Cluster a week of tickets by cause and show which cluster is growing, with its tickets listed.
Watch the escalations
Report the tickets that crossed a threshold and the work already open against each one.
Draft the triage, not the reply
Propose the owner and the priority, and leave the customer-facing answer to a person.

A complete Zendesk example, from trigger to proof.

The example names the people, task event, tool boundary, returned evidence, and acceptance state. The run row below it is a fixed product example, not customer data.

Example — fictional team and data. Not a live run or customer result.

Inside the connected tool

What the Zendesk connection gives you today

An org-owned account a workflow you author can read through. No Aestus support workflow ships behind it yet.

meridian · connectedConnection only

Runs without an approval

Read the tickets in a window

Held for a named person

Post a comment a customer will see

Not built yet

No Aestus Zendesk workflow and no pinned operation list yet.

Example — fictional team and data. Not a live run or customer result.

Concrete workflow example

See what last night's tickets were really about

This is what the connection makes possible. Aestus ships no built-in Zendesk workflow yet, so today the connection is the part that exists.

TriggerA workflow you build reaches Zendesk through the connected account

1
Organization admin
Connects Zendesk in Settings, Integrations
One org-owned connection, visible and revocable in the same place as the others.
connected · org-scoped
2
Aestus agent node
Reads the tickets in a window
Reading a queue changes nothing in it, so no approval stands between the run and the answer.
read-only · no gate
3
Aestus workflow
Groups them by cause and counts each group
Group sizes come from code. Every group names the tickets it is made of.
EXAMPLE-ZD-01 · grouped
4
Aestus
Keeps replying to a customer a separate decision
A public reply is a write. It is gated, named and recorded, never a side effect of a summary.
reply · approval required

Example — fictional team and data. Not a live run or customer result.

Illustrative product example — not a production run

Group last night's tickets by cause

Example run		Runtime	Outcome
EXAMPLE-ZD-01	Aestus workflow	aestus	Completed	$0.0231	33.5s

Tokens in / out: 11,200 / 820
Failure code: —
Agent: —

Illustrative Aestus workflow; actual costs and results vary

Example run cost

$0.0231 in the illustrative product example

A fixed illustration drawn from comparable Aestus workflow runs rather than a Zendesk workflow that has run, since none ships yet. It stands for one grouping run of 11,200 input tokens.

Set it up in four steps.

Follow the real Zendesk connection path. Provider steps link to the provider documentation. Aestus steps name the contract they follow.

01
Authorize the Zendesk instance
An organization admin connects it from Settings, Integrations. One connection per organization, visible and removable there.
Read the provider docs
02
Grant reading before anything else
Zendesk documents how its API access is authorized and scoped. Start with the access that only lets a run look at tickets.
Read the provider docs
03
Decide whether runs may reach it
Connecting an account and letting workflows use the toolkit are separate permissions, and the second is an organization policy choice.
Aestus product guide
04
Author the workflow yourself
No Zendesk use case ships in the catalog. The graph is one you write and seed, following the same loop as every other workflow.
Aestus product guide

The boundary stays visible while the work moves.

See what Zendesk can do, where a person still decides, and what Aestus records for every governed run.

Where control lives

Looking at a queue is free

A step that only reads tickets needs no approver, which is what makes an hourly watch practical instead of exhausting.

A customer-facing reply is refused, not held

Posting a public comment reaches a customer in your organization's voice. Aestus does not give that operation to an agent at all, so there is no approval to click through in a hurry.

Triage proposes; it cannot apply

Suggesting an owner or a priority and applying it are different acts. Aestus can do the first. Creating, changing and deleting a Zendesk ticket or organization are all refused.

What Aestus records

The tickets behind a cluster

A group of recurring issues lists the tickets in it, so "this keeps happening" can be opened and checked.

Who answered the customer

Where a reply is permitted, the approver and the exact text they released stay with the run that sent it.

Run economics

Tokens, latency, cost and failure code sit on the run row, as they do for every workflow Aestus executes.

Questions teams ask

Is there a support triage use case we can turn on?

Not yet. The escalation and triage use cases in the library work from the work already in Aestus. A shipped Zendesk workflow, with its own pinned tool list, is still ahead of us.

Could Aestus reply to a customer by accident?

No. A public reply is a write and writes are held. A workflow that groups or summarizes tickets has no path to a customer-facing comment.

What do we get by connecting it today?

An organization-owned connection that an agent node in a workflow you author can read through, plus the policy control that decides whether runs may use it at all.

See all integrations See the security controls

Start with one Zendesk run.

Bring one real run. Map its actors, boundary, evidence, cost, and acceptance step.

Talk to us

It reads the queue. It cannot answer a customer

Zendesk is read-only in Aestus: six operations read tickets and organizations; the other six, including the reply to a customer, are refused.

Not open yetThe Zendesk integration is not yet available to external organizations. This guide describes the intended experience; availability will be updated when access is ready.

Example — fictional team and data. Not a live run or customer result.

Concrete workflow example

See what last night's tickets were really about

This is what the connection makes possible. Aestus ships no built-in Zendesk workflow yet, so today the connection is the part that exists.

TriggerA workflow you build reaches Zendesk through the connected account

1
Organization admin
Connects Zendesk in Settings, Integrations
One org-owned connection, visible and revocable in the same place as the others.
connected · org-scoped
2
Aestus agent node
Reads the tickets in a window
Reading a queue changes nothing in it, so no approval stands between the run and the answer.
read-only · no gate
3
Aestus workflow
Groups them by cause and counts each group
Group sizes come from code. Every group names the tickets it is made of.
EXAMPLE-ZD-01 · grouped
4
Aestus
Keeps replying to a customer a separate decision
A public reply is a write. It is gated, named and recorded, never a side effect of a summary.
reply · approval required

Example run

Runtime

Outcome

EXAMPLE-ZD-01

Aestus workflow

aestus

Completed

$0.0231

33.5s

Questions teams ask

Is there a support triage use case we can turn on?

Not yet. The escalation and triage use cases in the library work from the work already in Aestus. A shipped Zendesk workflow, with its own pinned tool list, is still ahead of us.

Could Aestus reply to a customer by accident?

No. A public reply is a write and writes are held. A workflow that groups or summarizes tickets has no path to a customer-facing comment.

What do we get by connecting it today?

An organization-owned connection that an agent node in a workflow you author can read through, plus the policy control that decides whether runs may use it at all.

It reads the queue. It cannot answer a customer