New Forest app for Zendesk: Replace a lost card right from the ticket

A support agent at a regulated fintech picks up a ticket. The customer has lost their card. In one motion, the support agent orders a replacement, logs the action in the audit trail, and closes the ticket. Without leaving Zendesk.

Regulated fintechs live between two tools. Zendesk holds the ticket. Forest holds the customer record, the KYC status, the card ledger, the audit trail, the action.

Showing that record inside the ticket is the easy part. A sidebar that reads an email and paints a customer profile is table stakes. The Zendesk Marketplace is full of apps that do it.

The hard part starts the moment the support agent has to do something. Replace the card. Refund the transaction. Reopen the account. That stops being a display problem and becomes a control problem.

Who is allowed to run this action? What did it actually change in your systems? Can you prove it weeks later, tied to a named person? For a regulated fintech, those three questions are the job. Get them wrong and a helpful support agent turns into an audit finding.

For every fintech living between Forest and Zendesk, that gap between what an agent can see and what an agent can safely do has come up in nearly every conversation we've had for months. Today those three questions have an answer inside the ticket. We're launching the Forest app for Zendesk.

Now live on the Zendesk Marketplace, the Forest app lets your support agents run governed back-office actions from inside every ticket. Under your Forest permissions. Logged in your Forest audit trail. On your own infrastructure. The customer record, KYC status, and cards on file come with it, but the record was never the point. The action under control is.

How the Forest Zendesk app governs every action

The sidebar loads inside every ticket, matches the sender to your Forest record, and renders what the agent is allowed to see. Balances, cards on file, KYC status, all from your schema. That part is not hard. What runs underneath it is.

Not every agent can run every action

The sidebar only offers what the agent's Forest role permits. A first-line agent can replace a lost card. Refunding above a threshold, or reopening a closed account, may sit with someone else. Same ticket, same customer, a different agent sees a different set of actions. RBAC decides what is clickable before anyone clicks, so the control lives in the design of the role, not in the discipline of the person.

Every action is a governed operation, not a macro

A Forest action is not a text template or a canned reply. It is a real operation on your back-office, with dynamic forms, validation rules, and provider calls into your custom code. Refund a transaction. Update an account. Send a card replacement. Each one runs bounded and validated, against your systems, not next to them.

Every action is provable, tied to a person

Every action a support agent runs writes one entry in your Forest audit trail, linked to the ticket ID and the agent's Forest identity. Who ran it, what it changed, when. Weeks later, when a regulator or a risk review asks what happened on an account, the answer is one lookup, not a reconstruction.

All of it calls your Forest MCP Server on your own infrastructure. Nothing is stored outside your systems. Nothing is copied. Nothing leaves.

One ticket, start to finish with the Forest Zendesk app

A customer opens a Zendesk ticket. They say they have lost their card. Here is what happens next.

1. The Forest sidebar loads inside the ticket. It reads the requester's email, matches it against your Forest records, and surfaces the customer. Bounded by the support agent's Forest role. The support agent sees the plan, the balances, and the cards on file. Nothing more.

2. The sidebar analyses the ticket contents and surfaces a recommended action, "Replace the card", based on what the customer wrote.

3. The support agent clicks Execute. The action runs as a Forest action. It calls your custom code. It writes the change to your Forest record. It fires the audit event.

4. A confirmation surfaces. The new card will ship in a few business days.

5. The support agent replies to the customer in Zendesk and closes the ticket.

No copy-paste. No context switch. No untracked action. One audit trail entry for the whole thing, linked to the ticket ID and the support agent's Forest identity.

Where the Forest Zendesk app goes next

The app is live today with Forest actions triggered manually from the ticket. Here's where the roadmap goes.

Full Forest Workflows inside the ticket

Multi-step orchestrations, dynamic branching, and human-in-the-loop approvals, running from the ticket. Your compliance-heavy processes join the same interface your support team already uses.

Auto-triggers on ticket events

Actions that fire on new tickets, on status changes, on tag updates, under the same permissions and audit trail as manual actions. Your escalation paths automate without a separate rules engine to maintain.

AI agents on the same governance

Your AI agents already plug into Forest through the MCP Server, under the same RBAC and the same audit trail as the humans in Zendesk. As the Forest Zendesk app grows, the boundary between them stays where it should be: your governance.

Try the Forest Zendesk app on your data

Three ways to jump in.

Install it from the Zendesk Marketplace

Two clicks and your Forest data lands in the ticket sidebar: Zendesk Marketplace.

And our documentation for the Zendesk Forest app is only a click away.

Get a live walkthrough on your setup

Request a demo.

We'll run it against a back-office close to yours and show you what the audit trail looks like on your own data.

Tell us your wishlist

This is version one. If there's a Forest action, a workflow, or an automation you'd want it to run for your team, we want to hear it. Get in touch here. Your wishlist shapes what ships next.

With Forest, your support team and your AI agents work the same regulated back-office, under the same rules, with the same audit trail. Come find us at forest.app.