Zendesk
For schools that already run Zendesk. Submissions raised in Plugboard can create and update tickets there, so the device work lives here and the ticket record lives where the rest of the school’s requests already are.
| Category | Ticketing |
| Authentication | API token |
| Reaches | https://yourorg.zendesk.com |
| Needs an agent | No |
| Demo mode | No |
Capabilities
Section titled “Capabilities”ticket.create, ticket.get, ticket.comment, ticket.close
Getting the credentials
Section titled “Getting the credentials”- In Zendesk, go to Admin Center, Apps and integrations, Zendesk API.
- Enable Token access if it is not already on.
- Add API token, describe it as
Plugboard, and copy the token. It is shown once. - Note the email address of the agent whose account the token belongs to.
The token authenticates as that agent, so tickets created by Plugboard are attributed to them. Use a dedicated integration agent account rather than a person, so the attribution stays meaningful and does not stop working when they leave.
Configuring it in Plugboard
Section titled “Configuring it in Plugboard”Admin, Connectors, Zendesk, Configure.
Settings
Section titled “Settings”| Field | Value |
|---|---|
baseUrl |
Your Zendesk URL, for example https://yourorg.zendesk.com |
email |
The agent email the token belongs to |
Credentials
Section titled “Credentials”| Field | Value |
|---|---|
apiToken |
The API token from step 3 |
Save and test.
Running Zendesk alongside Plugboard
Section titled “Running Zendesk alongside Plugboard”Decide which system owns what, and then be consistent, because work that exists in two queues gets done in neither.
The arrangement that works:
- Plugboard owns device work. Repairs, loans, assets, inductions. It is what the product is for and Zendesk has no concept of a loan device.
- Zendesk owns everything else. Switch off
module.ticketsso the built-in queue does not compete. - Submissions create Zendesk tickets, so the school’s overall request record is complete.
Map your Plugboard statuses to Zendesk statuses on the workflow page, so a status change here is reflected there.
Status mapping
Section titled “Status mapping”Each Plugboard status can carry an external status it maps to. Zendesk’s statuses are new, open, pending, hold, solved and closed.
A reasonable mapping:
| Plugboard | Zendesk |
|---|---|
| Received | new |
| In progress | open |
| Awaiting parts | hold |
| With vendor | pending |
| Ready | pending |
| Closed | solved |
Solved rather than closed for the last one, because Zendesk closes solved tickets itself after its own interval, and closing outright prevents a follow-up comment.
Troubleshooting
Section titled “Troubleshooting”| Symptom | Cause |
|---|---|
401 on test |
Token access is disabled, the token is wrong, or the email does not match the token’s owner |
403 |
The agent lacks permission for that operation, usually on a restricted brand or group |
404 on ticket operations |
The ticket was deleted in Zendesk, or the base URL points at the wrong subdomain |
| Tickets created but not updated | The status mapping is empty, so nothing is being pushed |
| Duplicate tickets | Both queues are running. Switch off module.tickets |
Alternatives
Section titled “Alternatives”Web Help Desk, or the built-in ticket queue if you would rather not run a separate system at all.