Authorization and access to your data
All apps installed from the Zendesk Marketplace technically gain access to your Zendesk data ("your data") through the Zendesk App Framework. However, Playlist Ticket Assignment ("Playlist") also requires access to your data from our servers.
Authorizing with OAuth
Playlist uses Zendesk’s OAuth authorization flow, which requires you to explicitly grant API access to your Zendesk account. Here is a summary of the authorization flow:
- After installing the app, the admin lands on a page asking for authorization. We use signed URLs provided by Zendesk to ensure that the user authorizing API access is indeed a user of your account.
- The admin clicks on "Authorize" to initiate the flow.
- A window pops up, describing the scope of access that will be granted to Playlist, and the admin confirms authorization.
- Once authorized, our server generates and signs a JSON Web Token (JWT) to identify your account.
- This JWT serves is stored as a hidden, secure setting within the app.
The app (Playlist iframe in Zendesk) will then use the secure flag to include the JWT along with each request to our services. With the secure flag, communication between Zendesk and our services is always server to server, so the token is never exposed to users.
When our service receives a request, it will decode the JWT to validate the user’s identity. If we are able to successfully decode the JWT, the user is authorized and the request is carried out. Otherwise, the request is rejected.
Why does Playlist need server-side API access?
Playlist only reads and writes data where it needs to when using Zendesk’s APIs. Here are few reasons why server-side API access is necessary.
Some features like Round Robin need to be carried out even when agents are not logged in to Zendesk. We also cache information (e.g. agent information, group memberships) on our servers to avoid excessive calls to Zendesk's APIs.
Some admins may want to delegate the administration of Playlist to specific agents. Since Zendesk does not allow agents to update the user profiles of other agents, our service bypasses the restriction and provides "delegated administrators" with the ability to update custom fields managed by Playlist (Playlist Rule Id, Playlist Manager, and Playlist Autoplay).
We use Amazon Web Services as our cloud provider. Our servers are located in the us-west-2 region (Oregon, USA).
All data is encrypted in transit using TLS 1.2 and at rest with Amazon RDS encryption.
Data we collect
Here’s a summary of data that we store on our servers:
|User (agents)||User ID, Name, Role, Custom role ID, custom fields managed by Playlist (Playlist Rule ID, Playlist Manager, Playlist Autoplay)||x||x||Only agents. We never collect information about end-users.
Some agent settings are stored as custom fields on the User object
|Ticket||Ticket ID, Requester ID, Status, Assignee ID, custom fields managed by Playlist||x||x||Custom fields are updated to create an audit trail.|
|Group Membership||User ID, Group ID||x|
|Agent Attribute||Agent ID, Attribute Value ID||x||Only applies to Zendesk Enterprise customers who have opted in to Playlist's skills-based routing solution.|
|Ticket Attribute||Ticket ID, Attribute Value ID||x||Only applies to Zendesk Enterprise customers who have opted in to Playlist's skills-based routing solution|
|Target||All fields||x||x||App automatically creates a target when certain features are enabled (same agent workflow, dedicated support workflow)|
|OAuth Token||Token (encrypted)||x||Token is encrypted before saving to our database|
|App Installation||Enabled, Group restrictions, Role restrictions||x||Only details of your Playlist app installation.|
Admin contact details
We track usage of Playlist so that we can monitor the app’s performance and make improvements to it over time. This data is non-identifiable and we only aggregate information such as the number of tickets automatically assigned by the app.
Please contact us if you have any questions or would like to learn more.