The Zendesk App Extension Framework

There are three different ways to change what a support agent sees in Zendesk, and teams routinely reach for the wrong one. This is a plain guide to all three - extending the data, extending the interface, and installing an extension someone else built - and how to tell which one your problem actually needs.

Every request to "add something to Zendesk" sounds the same in a ticket. In practice they divide cleanly into three very different jobs, with three very different costs.

One team wants a purchase-order number from their ERP to show on the order. Another wants a risk score rendered as a colored badge next to each line item, not as a text field. A third wants the returns tool their ops team already uses to be usable without leaving the ticket. Those are a data problem, an interface problem, and a distribution problem. Solving the second with the tools meant for the first is where most Zendesk customization projects go wrong.

Layer one: extending the data

The first layer answers a narrow question: can the agent see this value at all?

agnoStack handles this through its provider model. Commerce Providers bring orders, customers and products from the platform of record. Add-On Providers bring the systems around it - subscriptions, loyalty, reviews, returns, shipping, payments. And when the value lives somewhere with no provider of its own, an Integration Provider carries it in as Order Metadata, Order Insights, Customer Metadata or Customer Timeline Events, with Zendesk Custom Objects available as native storage for records that belong in Zendesk itself.

This is the layer most requests actually need, and it is the cheapest to satisfy. There is no code to maintain and no release to schedule. If the ask is "show me this field", stop here.

Layer two: extending the interface

The second layer answers a different question: can the agent see this value in a form that helps?

A risk score is not a string. A delivery window is not a timestamp. A returns eligibility decision is a yes, a no, and a reason. Rendered as generic key-value rows they are technically present and practically ignored, because an agent scanning a ticket under time pressure reads shape before text.

This is what an app extension framework is for. Rather than adding another field to a list, it lets a purpose-built component render in a defined position in the workspace - a badge on a line item, a panel under the order summary, a control in a step header. The agnoStack application exposes exactly these positions as extension slots: on product rows, on item rows, within the order summary, and in the purchase step header.

The distinction worth internalizing is that layer one changes what data exists and layer two changes what the agent perceives. They are complementary, and layer two is worthless without layer one underneath it.

Layer three: installable extensions

The third layer is distribution. Building a component solves your problem once, for one account, and leaves you owning it forever.

Stackable Extensions are agnoStack's answer to that: extensions that install into those slots rather than being hand-built into the app. The work is underway in the agnoStack codebase today - the slot components exist and render through the Stackable Labs extension host - and it is deliberately narrow at this stage. The current host wires read-only context to an extension; the wider capability set is still being connected, and any extension capability not yet wired fails loudly rather than silently.

Treat that as an honest status report rather than a launch. Stackable Extensions for agnoStack will be announced on the 6.1.0 release page, which is not published yet.

Choosing the right layer

• Need a value visible? Layer one. No code.
• Need it to look like something an agent can act on at a glance? Layer two.
• Need it in more than one account, or maintained by someone other than you? Layer three.
• Need it in front of the customer rather than the agent? None of these - that is a messaging surface, covered in agnoStack’s guide to experiential messaging for Zendesk Messenger.

Most projects that stall picked layer two or three for a problem layer one already solved. The reverse mistake is rarer but more expensive: pushing genuinely visual, decision-support information through a flat field list and concluding that agents "did not adopt it".

Where to go next

If you are still deciding whether to build at all, agnoStack’s guide to developing custom Zendesk Apps covers the build-it-yourself path and when it is warranted. For the customer-facing counterpart of everything above, see Zendesk Messaging Extensions.

Working out which layer your requirement belongs in? Contact agnoStack, schedule a demo, or email info@agnostack.com.