Preview of the new App Builder for Zendesk
In this article we explore the new Zendesk App Builder EAP which uses generative AI to turn prompts into fully functional sidebar apps in Agent Workspace.
With the rise of Generate AI and LLMs, there's a few new capabilities and product types that become possible all off the sudden.
Writing text, rewriting, spell checking, tone shift etc are the most basic form of AI powered features and are available cross basically any platform now. Zendesk has it as part of their Advanced AI features in both Agent Workspace and the Help Center.
AI Agents are another popular new product type that turns legacy chatbots into modern conversational agents. These agents index company knowledge and leverage Generative AI to offer personalized and contextual conversations for your customers.
And Agent Copilot uses ticket history, intents, procedures and actions to assist agents with writing replies and automation actions in Zendesk and external platforms alike.
The name Copilot however is also used by other companies for a different kind of technology. GitHub Copilot for example is used to write code and assist in development. Similarly you've got Cursor, ChatGPT or a myriad of other tools that pull from the wider internet and allow developers to generate code, build apps and troubleshoot bugs.
I myself use these Copilots daily to clean up data for imports, build simple Zendesk apps, create Cloudflare workers or basically turn idea into working apps. Does the code work? Not always. Are the answers the cleanest fastest code? No. Does it make turning an idea into a prototype of an app fast and easy? Sure!
Cloudset
My thanks to Cloudset for sponsoring Internal Note
Introducing the Zendesk App Builder
Earlier this month Zendesk launched an EAP for their App Builder. It's a new feature that lives inside of Admin Center which allows you to build Zendesk sidebar apps via conversational interactions, similar to how you would talk to GitHub Copilot.
The big difference between ChatGPT or GitHub's Copilot and the Zendesk App Builder (ZAB) is that the ZAB is build specifically for Zendesk, which gives it a whole lot of functionality and benefits right out of the box.
For one, whatever app you build, it'll be styled with Zendesk Garden components and the app fits right into Agent Workspace.
import { ThemeProvider } from '@zendeskgarden/react-theming';
import { Grid, Row, Col } from '@zendeskgarden/react-grid';
import { Alert } from '@zendeskgarden/react-notifications';
import { Table, Body, Head, HeaderRow, HeaderCell, Row as TableRow, Cell } from '@zendeskgarden/react-tables';
import { Skeleton } from '@zendeskgarden/react-loaders';
import { SM, MD } from '@zendeskgarden/react-typography';
import { Button } from '@zendeskgarden/react-buttons';Similarly, the App Builder not only provides you with code, it also shows you a preview of how the app will look in Zendesk complete with relevant sample data.
And lastly, and this might be the biggest benefit of App builder as compared to more generic coding tools, it allows you to test your app in Agent Workspace, and publish the application directly from App Builder.
Building an App with Zendesk App Builder
Building an app with ZAB is pretty straightforward. When you launch the tool you're greeted with a prompt field and a couple of suggestions. These suggestions already set the stage for what kind of apps you can build. You can show information about the current agent, or you can show a list of recent tickets, or you can make API calls to an external tool like Jira and display them next to the ticket.
After sending your initial prompt you're presented with the actual builder interface. This interface has two big sections. On the left is your conversation where a – very friendly – AI Agent interacts with you.
On the right side are your results. A preview tab that shows the app, a code tab with the generated code, and a mock data tab that contains sample data to use in the preview.
And to conclude the interface overview you get a few actions that allow you to test the app in Agent Workspace, install the final version of your app or delete your work.
But, no better way to preview a new feature than to actually use it, so let's dive in!
Application 1: Custom Info App
App Scope
In this first app I'm going to build a "simple" app that shows data of the current requester next to the ticket. It'll show both end-user and organization data, a few recent tickets and will alert the agent if the customer is a VIP user.
Building the app
My initial prompt was pretty straightforward. Note that I just tried to reference ticket fields by name, not bothering for IDs. I really wanted to test how deeply the App Builder understands Zendesk.
I want an app that shows a customer name, organization, email address, user type organization type. Also show their profile picture. If they are a VIP I want an alert. Also show their last 5 tickets (ID, title, status)
For a first draft of a Zendesk app based on that prompt the design is spot on. However, when testing the app it did show some issues. My test user has open tickets, none off which were shown, and there's some issues mapping fields and images. So let's address that.
Note that, once again, I explain what's wrong but I try to stay away from Zendesk APIs and IDs. I assume most users who will use this tool won't have deep understanding of the Zendesk APIs or app tools and will do the same.
The recent tickets do not show up. Also for User-type and Organization Type there's custom fields on the user and organization level for those. My user is a VIP and that did not get picked up, and the profile image does not load.
The App Builder asked me to identify the fields with their name, and then rebuild the app. I was impressed by how nicely the App Builder asked for those pieces of information. Filling in a form, submitting the data and seeing the app rebuild is a nice way to handle this. Better than doing it with just text.
However, even though the preview seemed fine, the app broke completely, refusing to render anything in the actual test in Agent Workspace. Diving into the code I noticed it called the following functions to get the data:
const [userTypeResponse, vipResponse, orgTypeResponse] = await Promise.all([
window.zafClient.get('user.customField:user_type'),
window.zafClient.get('user.customField:vip'),
window.zafClient.get('organization.customField:organization_type')
]);Whereas in tickets you should call requester as the object. So let's see if a slight nudge helps here.
Could you use ticket.requester instead of user? That is the right identifier.
And that fixed it. It did take a bit of technical help, but App Builder rebuild the app and the right API calls (or placeholders) are now used to get the data.
Another round of these nudges helped things forward. The bot each time very politely acknowledge the mistake. Working with ZAB kinda feels like you're doing a collaborative coding session with a junior developer. Not bad.
While we're fixing things. The value for Organization in customerInfo is an array of organizations. Just take the first value if it's there. And the photo is stored in avatarUrl.
Now there's only two things to fix before our app is ready. Get it to show the recent tickets, and I want an alert for the VIP status, not an inline banner.
When looking at the source code I noticed it called a function setLastFivetickets() which was not implemented. Weird.
However, the way the generated code is structured and the fact that all functions and variables are clearly labeled does make it rather easy to troubleshoot these apps. I expect minimized javascript or inhuman code from an App Builder, but I'm glad it renders human-readable output to make bug fixing easier.
To wrap things up I did one final prompt. Again the AI Agent apologized and voila, working app!
You did not implements the "setLastFiveTickets" function and can you replace the check for VIP with an invoke(notify,message)?
The working finished app
Experience
The experience building this app started great. From the get go I had a nice design, it picked up on all the elements in the prompt and the way the app was structured was logical and clean.
During the further iterations some gaps did show up though. It used the wrong objects, it forgot to render the recent tickets and it clearly needed some extra guidance to grasp how Zendesk worked. Something you would expect from a Zendesk App Builder to understand Zendesk objects as basic as requesters, organizations and tickets.
However, thanks to the cleanliness of the code I was able to quickly fix the app and with only ~10 prompts I was able to go from idea to working sidebar app. Overall time to go from idea to app was ~30minutes and that's including making screenshots and notes for this article 🤯.
Especially powerful during the development of the app (if you can call it that) was that I could still test the app live in Zendesk. Yes, this is also doable via zcli apps:server for apps I build via VSCode or other editors, but the fact that this entirely web based tool offers the same capabilities was both impressive and useful.
Application 2: Movie Inspector
As a second project I built a more complicated app that integrates with external services. This means we'll ask the App Builder to not only generate an app that interacts with Zendesk, but also make use of APIs outside of the normal Zendesk scope.
In another article on this website I made use of the amazing omdbapi, an unofficial API that allows you to get movie information from IMDB. For this App we'll make use of the same API and show movie information next to tickets.
Thomas Verschoren
App Scope
We'll ask the App Builder to search Omdb for a movie. Once found, we should show the movie title, poster, genre, director and relevant information next to the ticket.
An Agent should then be able to either store that information on the ticket for future reference. If we ever stored information on the ticket, the app should pick this up and prefill the search query.
And we should be able to use the information and add it to a ticket comment to send to a customer.
Building the app.
When building apps with the App Builder I prefer to divide the development in a few big chunks. That way if something goes wrong you can first fix that part of the app, before adding more complexity.
In the first prompt I prompted as such.
Create an app with a search field. The search field should have a submit button and react to an 'Enter'. Once we search we need to call the Omdb API via https://www.omdbapi.com/?apikey={{api_key}}&t={{title}} to search for the movie. Render the returned result with a big title, and poster above it, and then the movie information like release date, summary, director, genre and actors (if available). Use API Token '123456' for the API call.
What's amazing is that the app just worked. To generate the mock data it used the provided API token, but it properly prompted me for an API key when I pressed test, meaning it never stored that key in the actual code. Nice!
Working first version
This rendered a good first version of the app but it needed a few design tweaks to work
Make the poster have a max height of 200px. Make the text bigger and add the label above the returned values.
Now that we have the working API call, we need to integrate this app with Zendesk itself. This next big prompt adds a few integrations with Agent Workspace. We expect App Builder to pull and set tickets fields on a ticket, and to integrate with the comment field of the ticket.
I have ticket field with ID 7662882404114 on the ticket.
If the field has a value, profile the search field with that value.
Also add two buttons. One button adds the search movie to the ticket field, the other adds the movie information as a comment on the ticket.
Can you add the two buttons next to the poster, and align all left, poster, title and buttons. Also when you add the comment, the confirmation message should have margin below it above the title.
Here too, it worked from the first try. The app showed to extra buttons, it adjusted margins, and when testing in Agent Workspace it correctly added the comment to the ticket, and references the right custom field.
I could've taken this app development further by asking it to use client.invoke('notify', message) function to alert me the comment was placed, or have icons instead of text for the buttons, etc, but for now this seemed like a good place to wrap up testing this type of app.
The only thing left was click publish and install the application in my Zendesk instance. What's nice here was that the app showed inline setting during publishing to set my API key, which was then uploaded and added to the apps in my instance.
Experience
What I liked about this type of app in the App Builder was the way it managed to accurately represent the external API within the preview next to the conversation.
I haven't really touched on it in the first app example, but while previewing the app you don't only get to inspect the actual code being rendered, there's also a Mock Data section where App Builder replaces the actual API calls made in the app and returns mock data that represents the actual data structure the Omdb API uses 🤯. This allowed the preview window to show accurate previews while not making external API calls every time.
window.zafClient = {
request: (options) => {
if (options.url.includes('omdbapi.com')) {
return Promise.resolve({
Response: 'True',
Title: 'Inception',
Year: '2010',
Rated: 'PG-13',
Released: '16 Jul 2010',
Runtime: '148 min',
/.../
});
}
return Promise.resolve({});
}
};Similarly, if your app calls Zendesk APIs (like ticket information, requester data e.a.) this mock data section also returns fake data instead of actual data from your instance, allowing you to test and iterate without affecting your actual data. Pretty nice and it does show the App Builder has deep insight in how Zendesk is structured. (Even though in this EAP sometimes it does not)
I tested this with GET calls like the app we build here, but also made test to POST endpoints and similarly the mock data correctly represented the expected results. I did however see a few POST calls being made to the actual endpoint so be careful when testing, your app does call the endpoint at least once during testing.
Compared to building the first app, this one also went a lot smoother. It immediately grasped the API data returned and rendered it correctly in the apps' preview and code. Maybe this is because it had a valid JSON response to start from? Or maybe it's me learning how to interact with ZAB? Probably a bit of both.
Comparison with other tools
I tried building the first app a second time via ChatGPT to see how it compared.
I gave it the first initial prompt and went from there. Where Zendesk App Builder immediately gives me a working prototype, I had some troubles getting the code to work with ChatGPT. It invented fake Zendesk functions, forgot to include the link to the app framework.js cdn and similar problems.
This function does not exist: client.invoke('document.update', { 'markup': '<p>Error loading data. Please try again later.</p>'});
Same for this one return client.get(`users/${user.id}`)
You’re right! In Zendesk’s App Framework, the correct method to update the document with new content in a sidebar app is client.invoke('document.update') but we need to use a different approach to handle the error in the context of the sidebar. Since we’re building a simple sidebar app, we should be updating the content of the sidebar directly.
After around two dozen back and forth explaining it how the Zendesk App Tools worked, I got to the following, fully functional result. With the big difference that where Zendesk just gave me an app, I had to build one via zcli apps:new first and add the code from ChatGPT.
And I think the results speak to itself. Comparing the two apps clearly shows a winner in UI out of the box. Especially since I didn't bother providing any of the two tools any guidelines on how the app should look like.
Both tools did have their issues with understanding the framework though, and even the platform-native Zendesk App Builder made the same mistakes as ChatGPT when it came to mapping placeholders and object paths.
However, ChatGPT was way weaker and needed to be fed the basic details of the App Framework and even invented non-existing functions..
Missing features and bugs
Looking at the Zendesk App Builder I can clearly see its potential. In a single afternoon I was able to build 6 fully functional apps, two of which were replica's of existing apps I made for customers and one of them of an app I just launched on the Marketplace. (More on that later)
I had to restart the App Builder a couple of times though. Sometimes the apps went completely the wrong way and I could not get logical errors out of the app. But restarting from scratch with a better defined prompt (which included some examples, or exceptions) always brought me to a good result.
There's a few things I would love to see though. One of them is the ability to select a version from the dropdown (each new prompt creates a new version) and just tell the tool "this was better, start from here and rebuild" (Update: this is now possible!)
Similar, since you currently can only build one app at a time, it would be nice to be able to import an app and have the prompts start from there. (Update, if you copy the source code of an app of the initial prompt this sometimes works)
From a prompt and content perspective the major limitation I found is that the tool is good with APIs, but sometimes it needs some help with getting the right context on how users, organizations and objects relate and you have to really define ticket.requester if you want the to use that data instead of just user.
The custom object example above maybe isn't a fair way to judge an EAP since it requires insights in multiple parts of Zendesk that even experienced Zendesk developers struggle to combine.
I do hope that future releases of this App Builder will grasp this multi-feature logic a bit more so users aren't expected to know this logic themselves.
Other features I'd like is the ability to upload a logo when building the app, and have a bit more control over the app settings. I was pleasantly surprised when the app asked for API tokens for the omdbapi, but I'd love settings to be able to e.g. choose between 5 most recent tickets, or 5 unsolved and recent tickets for example. But that setting was something I couldn't get to show up.
Conclusion
There's two ways to judge the App Builder. One way is looking it as a feature that's available today and how it can fit in current workflows.
The other way is to look at it as a start of a new way of working in Zendesk and explore how it will impact work.
Never. Ever. Buy a tech product based on the promise of future software updates. - MKBHD
When looking at the Zendesk App Builder today, in its current EAP state I think it's honest to say this is a good tool to do proof of concept build to explore new app ideas, discuss UI with the customer and quickly go from napkin drawing to functional prototype.
Compared to building and prototyping with GitHub Copilot it is way faster in rendering something Zendesk native. It does however miss the flexibility (or habit?) of being able to control source code yourself while prompting when you get stuck.
I would not yet dare to actually use this for customers or marketplace apps. But I will surely use it to test, iterate and draft new apps before I (or a colleague) developers them properly with full control over the code.
This is not a negative to ZAB. I already see considerable speed gains in those early stages of developing new ideas, and even within my new project, Tripel Hop we're already using ZAB to test out new app concept.
But don't expect app builder to replace your developers or other coding tools today. There's a promise and a vision here but the road's still being build.
Most people overestimate what they can do in one year and underestimate what they can do in ten years.” - Bill Gates
Just as we look at Meta Smart glasses or Apple Vision Pro as something that promises a future of wearable screens, App builder does show a future were building a sidebar app in Zendesk is simple as just telling Zendesk how to do it.
Take Zendesk's AI Agent Advanced as an example. We used to create new intents by writing dozens of training phrases. Now we just write a description of a use case and the AI Agent understands that new intent without any training. Hours of setting up a new AI Agent turned into mere minutes of work.
Similarly, Agent Copilots' procedures turn a written process into suggested replies and best next actions without any custom code. Here too the thought and writing process of "what should an agent do" directly results in actions deeply integrated into the platform.
So where ZAB currently shows a lot of promise, I do see a future where building sidebar apps in Zendesk becomes more "describe an app and get the result" than "find a developer". What's nice here is that it will lower the entry point for getting the most out of Zendesk. Most customers or consultants need help of developers to integrate Zendesk into companies.
Good customers and consultants can describe what they need. And I truly believe that if you're good at describing process and requirements, tools like ZAB, Agent Copilot or AI Agent use cases will become tools used by there profiles, removing the need for developers. Naturally, someone will still need to build these tools, maintain them and make them powerful.
Similarly, what makes developers good at their job is not their ability to code. it's their ability to grasp complex workflows, split them into their building blocks and turn that structure into code (and comments). And guess what, that's still a skill you need for these generative app builders.
I also see a market in extending app builder with prebuilt actions. Built an action that integrates with Shopify and has get, set and post endpoints. That action can then talk to the AI trio of App Builder, AI Agents or Copilot. Developers build the actions, and Zendesk administrators use the AI Trio to build their flows, similar to how we now use the trigger and automation UI to build powerful integrations.
When? Could be a year. Could be five. But clearly it's not an if anymore.
