Choose your own app adventure
You may have already read about the Zendesk Apps framework (ZAF) and how you can use it to modify and extend your agent's interface in a number of ways.
But are you aware of all the paths that you can choose when starting your custom code adventure? Know the benefits of each approach, so you can determine what direction is best.
These approaches outline the main ways you can interact with the Zendesk Development Platform. Read from beginning to end, or jump to the area of interest -- each one has a short description along with links to more information.
A client-side app is your custom code packaged up and deployed to all your agents. The app code runs in your agent's browser.
The app's manifest file (a JSON file that tells ZAF about your app at a high level) is the key.
In the manifest file, you tell ZAF about your app's starting HTML page using the
url property -- if you specify an HTML file, it's a client-side app.
Sample client-side app manifest:
See how the manifest references "assets/iframe.html"? Because this is a local resource that isn't served up from a remote server, it makes this app a client-side app.
The manifest file and the
iframe.html file referenced are created when using
iframe.html is a generated name, but you can rename it to whatever you want. This html file is what's initially loaded and is the starting point for your app.
The difference between "client-side app" and "server-side app" is where the assets of your app are located and who stores and manages them (Zendesk, for client-side apps; you, for server-side apps). Server-side apps still let you write custom code and deploy it to all your agents BUT it's now up to you to manage this remote server and the assets that it's serving to your agent's browser.
Along with determining where assets live, server-side apps can push more involved code away from the browser and into an infrastructure you control, made up of technologies that you choose.
In both cases, the app is still downloaded to your agent's browser and displayed there.
Sample server-side app manifest:
See how it references https://myserver.example.com/myappendpoint? Specifying a remote location is what makes it a server-side app. ZAF calls this remote endpoint once and loads whatever is returned by it into an iframe on your agent's desktop.
The upside of a server-side app is that it puts you in complete control of what's served up -- if you have changes you want to push to everyone, you update what the server request returns and all agents get the latest and greatest immediately -- no need to package up and upload a new version of your app. Some app developers use nothing but a remote URL for all their app locations.
The downside of a server-side app is that you are now responsible for maintaining your app's remote endpoint and all the operational concerns that go with it.
The Apps framework lets you drop in custom code into your agent's browser for them to see and interact with. Maybe the app just displays information, maybe it manipulates the information on the screen before saving a ticket, maybe it does things the product cannot currently do -- such as the Zendesk Support's Out-of-Office app.
Apps are a great way to deploy custom functionality.
But do you always need an app to do something custom? You saw this coming -- the answer is 'No'.
The Zendesk development platform has an amazing set of APIs that let you do a lot outside the confines of the Apps framework.
Consider asking if your custom code should even be in the form of an app. If there's no need for direct agent interaction, consider putting your custom functionality on a back-end web server and have it authenticate into your Zendesk instance and call Zendesk APIs from there.
This might be a great option if, for example, you want to do incremental exports of your Zendesk data on a periodic basis and serve it up to other back-end services that you own. You wouldn't want a browser installed "App framework" app for that. You can instead incorporate it into a (possibly already existing) web server on your favorite hosting service and have it call into Zendesk directly, without relying on agent interaction.
An alternative of going with a web hosted solution is setting up a local script in the language of your choice and call the Zendesk API directly from there. Set up the script on a timed/cron job and you now have your automated solution.
Regardless if it's a local script running or something from a web server, it's up to you if you're calling the Zendesk REST APIs directly or using one of the language specific client libraries that conveniently wrap API calls.
- API quickstart
- Common tasks for the Zendesk Support API
- Client libraries -- basically language specific convenience wrappers around the Zendesk API
So-called "Marketing apps" (or "Integration apps") are publicly available integrations with Zendesk and do not have an actual app associated with them.
Marketing "apps" are displayed alongside other apps in the Zendesk Marketplace but don't actually get served up to an agent's interface -- they are third-party hosted services that integrate with Zendesk via API calls versus through a client- or server-side app. This integration between Slack and Zendesk is one example -- all processing is done on a back-end server, so there is no actual app that the agent sees.
Channel framework integrations are special -- they don't get served up like other apps. If you're not already sure if this option is for you, chances are it's not (just sayin').
This functionality is for when you need to monitor, pull, and respond to customer comments posted on a third-party site -- such as Facebook or Twitter. These are just examples -- Zendesk already natively supports these integrations.
While chances of needing to write a new integration with such a third-party social/reviews site are low, this framework exists to help you do that.
Widgets aren't "Apps framework apps" -- but are similar in that they can be customized and add a lot of value to your site. They are bits of embedded code that add extremely useful Zendesk features (live chats, knowledge base search, ticket submission) right on your own web pages. Widgets are very cool and you really should read up on them.
- Using Web Widget to embed customer service into in your website
- Embedding Zendesk into your product
- Advanced customization of your Web Widget
- Web Widget API
If you're building mobile apps and you want to embed things such as Zendesk knowledge base lookup, creating and reviewing submitted tickets, and Chat right in your mobile iOS or Android app, then you need our mobile SDKs.
The Zendesk Marketplace is public and lets you expose your app's goodness to the masses. While a published app can be offered for free (and there are lots of those), there are revenue generating options as well.
If you're developing a public app that uses a service that requires accessing your customer's Zendesk resources, there's a good chance you'll want to use OAuth to authenticate into their Zendesk instances.
OAuth authentication can be tricky -- one of the things needed is you have to set up a Zendesk OAuth Client -- but how do you get all your potential customers to create an OAuth client correctly? That's where "Global OAuth" comes in -- it lets you create a single OAuth client that can be used by all your customers but still ensures security and separation between individual Zendesk instances.
- Do I need a global OAuth client?
- Am I ready for a more advanced authentication option?
- Adding OAuth - Part 1: Setting up an integration
Despite the many resources mentioned above, working out problems with peers in a larger community can be a lot more efficient and rewarding. The Zendesk Support community is a great resource to find and share information. There are specific areas focused on development with long-time users and moderators of the development platform sharing tips and tricks.
It is actively monitored by both Zendesk & community moderators, but the real value comes about when more community members share with each other -- so check it out!