The Zendesk App Extension Framework

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 every cart an agent builds to respect a wholesale pricing rule before it becomes an order. A third wants a risk score rendered as a colored badge next to each line item, not as a text field. Those are a data problem, a logic problem, and an interface problem. Solving the second or third 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 logic

The second layer answers a different question: can the agent's workflow apply your rules?

Showing a value is not the same as acting on it. A wholesale account has a floor price. A bundle must not ship without its companion item. A cart that mixes two warehouses needs a note, or needs to be stopped. Agents under time pressure will not enforce any of that by hand, and a field in the order summary does not enforce it either.

Extended Data Hooks are built for this. At key points in agnoStack's own workflows - today the Cart behind Order Creation/CartCollab, with Order and Customer to follow - agnoStack hands the data in flight to your Integration Provider, and whatever comes back is what it carries on with. Your team can validate it, enrich it with lines or attributes, or reject it with a reason the agent sees. The same Integration Provider that feeds layer one does the work, so there is no new system to run.

Extended Data Hooks are in early access for select Enterprise customers and technology platform Partners, with an open-source reference repository to start from.

The distinction worth internalizing is that layer one changes what data exists and layer two changes what agnoStack does with it. Layer two is worthless without layer one underneath it.

Layer three: extending the interface

The third layer answers the last 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.

Stackable App Extensions are what fill those slots: extensions that install into the agnoStack application rather than being hand-built into it, so a component built once can run in any account that authorizes it, maintained by agnoStack, a partner or your own team. Extensions read the host's context through the Stackable Labs extension host, and with Data Modification they can also save what an agent chooses back to the cart and order.

Stackable App Extensions are introduced in agnoStack 6.1.0; the engineering introduction covers how they are built.

Choosing the right layer

• Need a value visible? Layer one. No code.
• Need a rule enforced, or data shaped, before it becomes an order? Layer two.
• Need it to look like something an agent can act on at a glance, in any account that wants it? 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 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". Layer two is the one teams forget exists: a rule that lives in a wiki instead of a hook is a rule agents will break.

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.