The Zendesk App Builder

Most support teams shouldn't reach for the Zendesk app builder. The ones who should can usually name the exact twenty seconds of agent time they're deleting.

Start free trial All guides

What the Zendesk app builder produces, technically

A Zendesk app is a small web application running in an iframe inside the agent interface, talking to Zendesk through the apps framework. That's the whole model, and understanding it saves a lot of confusion later.

The framework gives you four things worth knowing about.

Locations. Where your app renders: the ticket sidebar, the user or organization sidebar, the top bar, a modal, or nowhere visible at all as a background app that just listens and acts.

Context and events. A client library that reads the current ticket, requester and organization, and subscribes to changes so your app reacts when the agent edits a field.

Actions. Writing back: set fields, add a comment, apply a macro, change assignee. This is what separates an app that removes work from one that displays information.

Secure settings and the proxy. Somewhere to put an API key that's not visible in front-end code, and a way to make the outbound request server-side so credentials never reach the browser.

Apps you build for yourself are installed privately to your own account. There's a command line tool for packaging and uploading them, and Zendesk has been adding lower-code paths for simpler cases, but the underlying model is the same either way.

Build or buy

Buy when a maintained vendor app already exists for the system you are connecting to. The marketplace app for a major SaaS product will be better than the one you write, and more importantly somebody else fixes it when the platform changes. See Zendesk apps and the marketplace for how to vet one.

Build when one of these is true.

The system is yours. Internal admin tools, homegrown billing, a legacy database. Nobody is going to publish an app for it.

The workflow is specific to you. Not "show me the customer", but "show me whether this account is eligible for the migration and let me flag it in one click".

You are consolidating. One panel replacing three is a real win, because sidebar attention is the scarcest resource in the agent interface.

The vendor app shows but doesn't do. If agents still copy a value out of the panel and paste it somewhere else, the step was never removed.

A weak reason to build: the marketplace app costs money and you've a developer. Developer time isn't free, and the app you write has no maintainer after they move team.

What an app costs after launch

This is the part that gets skipped in the planning meeting.

Someone owns it forever. Platform changes will eventually require an update. API keys need rotating. The internal system it queries will change its response shape without telling you, on a Friday. And the person who built it in a fortnight of enthusiasm will change jobs.

A simple test before you start: name the owner. Not the team, the person, and then the person after them. If that sentence is uncomfortable to say out loud, buy something instead or solve the problem with configuration.

Designing an app agents will actually use

One job. An app that does one thing well gets used; an app with tabs gets collapsed and ignored within a month.

Visible without scrolling. The sidebar is short and it's shared with every other app you installed.

Fast, or degraded gracefully. If your backend takes four seconds, show something in four hundred milliseconds and fill it in. Agents won't wait, and an app that makes the ticket feel slow gets uninstalled by popular demand.

Never block the ticket. When the API behind your app is down, the app should say so quietly and let the agent carry on. An app that throws errors over the ticket view has turned a minor outage into a support outage.

Write back to the ticket. What lives only in your app panel is invisible to Explore, invisible to triggers and invisible to anyone reviewing the ticket next year. If a value matters, put it in a custom field.

Try these first

A surprising share of "we need to build an app" turns out to be a macro, a custom field, or a link.

Specifically, a macro or a ticket comment containing a URL with ticket placeholders in it will open your internal tool already filtered to this customer. No app, no maintenance, no framework, and roughly the same number of clicks saved. Try it for a fortnight before writing any code.

FAQ

Frequently asked questions

What does Zendesk app development actually involve?

To build a Zendesk app you write HTML, CSS and JavaScript against the apps framework, then package and install it. A Zendesk custom app private to your account skips the review process the marketplace applies.

Do I need to be a developer to use the Zendesk app builder?

For anything with custom logic, yes: an app is a web application, usually HTML and JavaScript. Simple display-only cases can sometimes be handled with configuration or a link instead.

Can a private app be used only by my account?

Yes. Apps you build and install privately aren't listed publicly and are only available in your Zendesk account.

Where do API credentials go?

In the secure settings, with outbound calls made through the framework proxy so keys never reach the browser. Never in front-end code.

Can I report on data shown in a custom app?

Not directly. Explore reports on Zendesk data, so write anything you want to report on into a ticket or user field.