Skip to content
● Grav 2.2.19 and 1.7.53.8 are out with security fixes found by Anthropic's OSS Scanner: update your sites. Read more →
Premium / Helpdesk Pro
Premium Plugin · v1.2.3

Helpdesk Pro

A complete helpdesk, running inside your Grav site

Helpdesk Pro is a helpdesk and request tracker that runs inside your own Grav site. Your team works tickets in Admin Next, your clients follow their requests in a client portal on your site, and your knowledge base is ordinary Grav pages you already know how to write. Every ticket, reply and file sits in a database you own, on your server, and backs up with the rest of your site. There's no per-agent monthly bill, so adding a colleague to the desk costs nothing. Clients never need a password: they sign in with a link we email them, or just reply to our emails, because email works both ways. Replies, new requests and follow-ups arrive by webhook from your mail provider or from an IMAP mailbox, thread onto the right ticket, and go back out as clean, branded email that reads like it came from a person.

Grav 2.0+
Documentation

Helpdesk Pro is built for Grav 2 and requires the free API, Login, Email and Form plugins. It is not compatible with Grav 1.7.

Everything you need. Nothing you don’t.

Over 85 distinct features and integrations, out of the box.

The Staff Desk

Run the whole desk from the keyboard

Your team works tickets inside Admin Next, and every screen has its own address, so a filtered list, a board or a ticket is a link you can bookmark or send to a colleague. Press ? anywhere for the shortcut sheet shown here: c starts a new ticket, / jumps to search, g and a letter moves between My work, All tickets, Triage and Notifications, and r or n opens a reply or a note. Shortcuts never fire while you type, and single keys can be turned off per browser.

The keyboard shortcut sheet open over a ticket in the desk
01
My work groups the tickets assigned to you by what they need: needs your reply, in progress, waiting on the client, and recently solved.
02
All tickets with filter chips counted over the whole result, a sort, and a search box that finds a ticket by number, subject, requester name or email address, and the words of its conversation and internal notes.
03
Replies and internal notes in one composer, each with its own draft saved as you type. A note is tinted and labelled so it can never pass for a reply, and it never reaches a client by any route: not the portal, email, search, live updates or the API.
04
A collision guard: if the client wrote in while you were typing, you see the new messages with Send anyway and Edit first before anything goes out.
05
Triage for new requests, oldest first, with three decisions: Accept, Duplicate of… and Decline with a reason. Each decision emails the client the right thing, and single keys move you through the queue.
06
Statuses in six fixed categories (New, Open, Waiting on client, Waiting on us, Resolved, Closed) that you can rename and add to, plus labels, priorities and kinds (support, bug or feature).
07
Projects decide who may submit and read tickets and which staff work them: private, members only, Grav groups, or public. Each has its own default assignee, email alias and triage switch.
08
Project boards with a column per status. Drag a card to change its status with the mouse, or do the whole move from the keyboard with every step announced to screen readers.
09
Merging tickets brings both conversations, files and email threads together on one ticket, and the desk warns you before a merge would let anyone read more than they can today.
10
Saved replies with placeholders like {{client.first_name | there}}, personal or shared, plus saved views and bulk edit of up to 200 tickets at once.
11
New tickets on a client's behalf: find the client by name or email (or type a new address), set the kind, priority and assignee, attach files and choose whether to email them.
12
Keyboard shortcuts throughout (c for a new ticket, / to search, j and k in lists, r to reply, n for a note, ? for the full sheet) that never fire while you type and never clash with Admin Next's own keys.

Email In and Out

Test an email before a real one arrives

Most people who write to a helpdesk just want to use their mail app, so Helpdesk Pro lets them and keeps every conversation on the right ticket. The Email screen shows how mail reaches the desk and when the last message came in. Try an email takes a pasted message and runs it through the same checks a real one gets: the loop guard, who sent it, which ticket it belongs on, and what is left once the signature and quoted history are trimmed. Nothing is saved and nobody is emailed.

The Email screen with the inbound mailbox receiving and a dry run of a pasted email
01
Replies by email: clients and staff answer Helpdesk Pro's emails from their mail app and the reply lands on the right ticket. A new email to your support address, or to a project's own alias, opens a ticket.
02
Receive mail the way that suits you: inbound webhooks from Postmark, Mailgun, SendGrid, Amazon SES, Resend and MailerSend (through their Email plugin providers), Cloudflare Email Routing with a small Email Worker, a signed webhook of your own, an IMAP mailbox such as Gmail with an app password, or a Postfix or Exim alias that pipes mail straight into the plugin.
03
Threading that holds up: a reply finds its ticket by the thread headers, a reply address made for that recipient (support+t…@), or a hidden signed reference, and only when the sender is allowed to add to that ticket. A staff member's reply by email posts as them, and a reply to a note email becomes a note.
04
Clean replies: quoted history, signatures and Sent from my iPhone footers are cut from Gmail, Apple Mail, Outlook, Yahoo, Thunderbird and Proton Mail replies, with On … wrote: recognized in twelve languages. HTML-only mail is converted to text, with hidden content and tracking pixels dropped.
05
A loop guard ignores out-of-office replies, bounces, mailing lists and its own mail, and rate-limits each sender. A staff reply that fails DMARC, DKIM and SPF is held for an admin to release.
06
An inbound log of every received email with its state and the full decision trail, Show original, Retry and Release, plus Try an email, a dry run of a pasted email that saves nothing.
07
Client email that reads like personal email: the agent's name, their reply and a View request button, with no ticket numbers and no quoted history. A reply sent with mark solved goes out as one email, not two.
08
Branded HTML email with your logo (and a dark-mode logo), accent and button colors, a font choice and a Markdown footer line. It's 600px wide, readable on a phone, and supports dark mode in Apple Mail, iOS Mail and Outlook.com. The plain-text part carries the same links.
09
Files travel with the reply: pictures show in the email, other files are attached up to a size cap (10 MB by default), and the rest become links that sign the client in and open the file.
10
Proper mail headers: Message-ID threading, RFC 8058 one-click unsubscribe, Auto-Submitted and X-Auto-Response-Suppress, all sent through whatever engine your Email plugin already uses.

The Client Portal

A request form that tries to answer first

The portal is a page on your own site, at /help or wherever you put it, drawn by your theme and written for people who aren't technical. Guests write in with the request form: their name and email, a short summary and the message, any custom fields you ask for, and files dropped in. As they type, the form suggests help articles that match, so plenty of questions are answered before a ticket exists. Nobody sets a password: the email that confirms the request carries a link to follow it.

A signed-in client's Your requests page, with Open, Waiting on you and Closed tabs
01
A help center home with a big search box, the visitor's latest requests, topic cards and popular articles, then Contact us last.
02
Sign-in links instead of passwords: clients type their address and get a link that works once and expires. Only a hash of it is stored, and the link opens a page with a single button, so the corporate mail scanners that open every link in an inbox can't use it up.
03
Signed in from every email: each client email links the request with a sign-in link made for that recipient, so a guest or email-only client lands on their request already signed in.
04
No account needed to write in: guests use the request form, and someone who only ever emails you never gets a Grav account at all. An account is created the first time a person uses a sign-in link.
05
Your requests with Open, Waiting on you and Closed tabs, search, and New reply markers. Each request shows the public conversation, a banner that says what happens next, a reply box with file uploads, and This is solved, Reopen and Stop emails actions.
06
Status names in the client's words (Received, In progress, Waiting for your reply, Solved, Closed). Your internal status names, notes, assignees and priorities never appear.
07
Spam protection on the guest form: the Form plugin's captcha (Cap by default, which runs on your own site and calls no third party), a honeypot, a signed time trap, hourly limits per IP address and per email address, and a blocklist of addresses, domains, IP ranges and words.
08
Works with JavaScript off, as ordinary forms that post and come back. With JavaScript on, the request updates in place and a reply appears without a page load.
09
Looks native on any theme: every color, radius and space comes from --helpdesk-* custom properties that follow your theme's Pico variables when it has them, in light and dark mode and at phone width. Every template can be overridden from your theme.
10
Deep links survive signing in: a client who opens a request link before signing in comes back to that exact request afterwards.
11
Twig functions to bring the portal into the rest of your site: helpdesk_url(), helpdesk_ticket_form(), helpdesk_my_requests() and helpdesk_nav().

Knowledge Base & Search

Search that knows what people mean

People rarely search with the words your articles use, and they don't have to. Here the help center answers can't log in with articles about signing in, thanks to a synonym list and typo correction on the bundled YetiSearch index, which holds tickets and articles together and needs nothing extra installed or running. Every result respects who is asking, so a guest only finds public articles. When nothing fits, Still stuck? opens the request form with their search already filled in.

Help center search results for can't log in, finding articles about signing in
01
Articles are Grav pages that use the Help Article page type. Write them in the Admin Next page editor you already use, with categories, a project, related articles and group access on a Help Center tab.
02
Browse or search: an articles index, a page per topic with its own description and icon, breadcrumbs, More in this topic, previous and next links, reading time and Was this helpful?
03
Still stuck? Ask us: answering No on an article opens the request form with the visitor's last search as the summary, and the form suggests matching articles as they type.
04
Before writing in: the ticket keeps the searches and articles the client went through first, so nobody sends them the article they already read.
05
One search index for tickets and articles on the bundled YetiSearch library (SQLite FTS5 with BM25 ranking). There is nothing to install and no service to run, and the index rebuilds itself if the file goes missing or stale.
06
Synonyms and typo correction, so a search for can't sign in finds the article that says log in. The desk also shows similar tickets on every ticket.
07
Results follow permissions: guests find public articles, clients find their own tickets and the articles they may open, and internal notes live in a separate staff-only index that no client search can reach.
08
Optional semantic search through any OpenAI-compatible embeddings API, off by default.

Rules, Macros & SLA

Saved replies that also do the busywork

Rules and SLA targets run in the background, and saved replies speed up the part people still do by hand. A saved reply fills in names and ticket details through placeholders like {{client.first_name | there}}, stays yours or is shared with the team, and can be offered in one project only. Open Also change the ticket and it becomes a macro: sending it can set the status and priority, assign the ticket to whoever sends it, add or remove labels, move it to another project and change its kind.

A saved reply editor that also sets the status, priority and assignee when it's sent
01
Rules in plain when, if, then form. When a ticket is created, someone replies, a note is added, a field changes, or a ticket has sat in a status for some hours. If it matches all or any of your conditions. Then change the ticket, add a note, notify someone, send the client a saved reply, or post to your team channels.
02
Test against a ticket: a dry run shows which conditions a real ticket meets and what the rule would change, saving nothing.
03
Rules can't run away: a change made by a rule never triggers rules again, a rule never fires twice for the same event, and a failing rule is logged and shown on the rule while the others carry on.
04
A built-in auto-close (off by default): a solved ticket whose client stays quiet gets a friendly nudge, then closes a few days later unless they reply.
05
Macros: a saved reply can also set the priority, assign the ticket, add or remove labels, move it to another project and set its kind. The composer tells you what it will do before you send.
06
SLA policies with first response and resolution targets, matched by project, priority and kind. The first match wins, and one policy can be the default.
07
Business hours with a timezone, several ranges a day, overnight ranges and holidays, with daylight saving handled. Or count around the clock.
08
One SLA clock per ticket that pauses while you wait on the client, stops at resolution and carries on after a reopen. The assignee gets a warning before a target is missed and a notification when it is.
09
Due badges on All tickets (in 2h, 35m late), Breached and Due soon filters, and a Due soonest sort. Clients never see a due time or a breach.

Notifications & Live Updates

Staff hear about what matters to them without drowning in email, and the whole team can follow along in the tools it already watches.

01
The bell first, email second: a notification is emailed only when it wasn't read in the desk in time, batched so a busy ticket sends one email, and held while you are active in the desk. A daily digest arrives in each person's own timezone.
02
Three levels per person (everything, only what's aimed at me, nothing), switches per kind of notification, and a mute on any ticket.
03
Team channels: post chosen ticket events to a Slack channel, a Discord channel, a signed webhook of your own, or a team inbox, for every project or just some. Deliveries retry, a failing channel is flagged, and Send a test message shows the endpoint's own answer.
04
Channels stay discreet: a channel message carries the subject, requester, status and a desk link, but never a note, a staff reply or a custom field.
05
Live updates over the Sync plugin: a new reply or note appears in an open ticket without a reload (your half-written draft stays put), lists refresh, and the sidebar badge follows the bell. Polling works everywhere, and Mercure or Ably push updates instantly.
06
Presence: Anna is viewing, Anna is replying… and The client is viewing this request above the composer. Clients never see staff presence.
07
Everything works without Sync: the desk refetches what's on screen when you come back to it, and presence runs on its own heartbeat.

Clients, Organizations & Custom Fields

The details your business runs on

Know who you're talking to, which company they're with, and the details that matter to your business. Custom fields add questions like an order number or a plan, in nine types from text and dates to select lists. Each field decides who sees it: clients fill it in on the request form, clients can only read it, or it stays with staff. A field can be required, shown as a column on All tickets and limited to some projects, and filters, rules and the API all find it by its key.

The custom field editor with its visibility, required and column options
01
Client organizations with email domains. A client with a proven address at one of those domains joins by themselves, and free-mail domains like gmail.com are refused.
02
Shared requests, switched on per organization: colleagues read each other's requests in the portal under My organization. They can't reply unless they're on the request, and they're never emailed about the ones they only read.
03
Custom fields on tickets: text, long text, number, select, multi-select, checkbox, date, URL and email, for every project or just some.
04
Public, read-only or internal: public fields are asked on the request form, read-only fields are shown to the client, and internal fields are for staff only. An internal value never reaches a client through the portal, email, the API, search or live updates.
05
Fields where staff need them: a Fields panel on each ticket, list columns and filters, saved views, rule conditions and a Set a field rule action.
06
People in one place: everyone Helpdesk Pro knows, with their requests and details, and actions to block, send a sign-in link, link or unlink a Grav account, or merge two people into one.

Reports & Satisfaction

Know how the desk is really doing

Reports are counted from what every ticket already records, so they cover your whole history from the first ticket, with nothing to switch on. Choose the last 7 or 30 days, this month, last month or your own range, for one project or all of them, for everyone or one person. Then read tickets created, resolved and reopened, the open backlog day by day, reply and resolution times, SLA results and satisfaction, and breakdowns by channel, assignee, organization and custom field, each of which can be downloaded as CSV.

The Reports screen with ticket totals, tickets by status and the open tickets chart
01
Reports over the last 7 or 30 days, this month, last month or a custom range: tickets created, resolved, reopened and open, the open backlog and created versus resolved charts, median and 90th percentile first reply and resolution times, SLA and satisfaction.
02
Breakdowns by channel, project, assignee, organization and custom field, plus the help center searches that found nothing. Every table and chart downloads as CSV, and every report is a link you can bookmark.
03
Honest numbers: days are your site's days (daylight saving included), deleted and merged tickets are left out, and staff only see the projects they work.
04
Customer satisfaction (off by default): How did we do? with Great, Okay and Not good in the solved email and on the request page. Clients can change their answer and add a comment, and a Not good rings the bell of the staff member it's credited to.
05
Rating links are scanner-safe: opening a link only shows the page, so a mail scanner that follows every link in an inbox records nothing.
06
A Ratings screen and a Rating card on every ticket, plus a Helpdesk widget for the Admin Next dashboard and a Helpdesk report on Admin Next's Reports page.

Privacy, Files & People's Data

Everything you hold about someone

When you run the helpdesk, you're the one holding the data, and a person's page shows exactly what that means. It lists their requests and details, and What Helpdesk Pro holds about them counts every kind of record, from received emails and replies to sign-in links and help center searches: the starting point for a subject access request. The same menu blocks them, merges them into another person, places a legal hold or erases them. All of it lives in one SQLite file on your own server.

A person's page with its actions menu open and what Helpdesk Pro holds about them
01
Your data stays on your server, in one SQLite file under user/data/helpdesk-pro/, with deny-all protection written next to it.
02
Erasure on request, in two modes: anonymize a person, or also remove every message and subject they wrote and delete their files. Their name is taken out of other people's words on the tickets they were on too.
03
Legal holds that stop an erasure, and a person page that shows everything Helpdesk Pro holds about someone, the starting point for a subject access request.
04
Hashes, not secrets: sign-in links, rating links and rate-limit counters are stored only as hashes, and a guest request stores nothing about the visitor's browser or IP address.
05
Private files: attachments are only ever served through access-checked routes, never a bucket or CDN address, and a file on a note is as private as the note. Files can also be kept in a private S3-compatible bucket (Cloudflare R2, Amazon S3, Backblaze B2 or MinIO).
06
Upload rules: size and count limits, an extension allowlist checked against each file's content, and program and script types always refused.
07
Not found, never forbidden: someone who can't read a ticket or file is told it doesn't exist, so nobody can probe which ticket numbers are in use.
08
Deleting a Grav account never deletes a helpdesk record: the person and their tickets stay, because a support history is a business record.

For Developers & AI Agents

The desk in Admin Next is built entirely on Helpdesk Pro's own API, so anything a person can do there, a script or an AI agent can do too.

01
A REST API under /api/v1/helpdesk-pro/ on the Grav API plugin, with paging, ETags, problem-details errors and the same access rules as the desk.
02
132 MCP tools through grav-mcp, so Claude, Cursor and other AI clients can read and work tickets with exactly the permissions of the API key they use. Tools you can't use are never offered.
03
Notes before replies: an AI can draft an internal note for you to review before the client hears anything, and a reply written against a conversation that moved on is refused.
04
Scoped API keys are respected: a key limited to helpdesk-pro.desk can't delete a ticket, even when its owner is an admin.
05
Eight permissions, from working tickets to configuring the desk, granted to your Grav groups in Admin Next.
06
Extension points for add-ons: domain events, custom rule triggers, conditions and actions, extra notification channel types (Teams, Mattermost…), report cards, ticket panels and person data that joins merges and erasure.
07
A background job queue for email, notifications, inbound mail and indexing, with retries and backoff. Jobs a request queues run right after its response, and a catch-up pass keeps email going on a site whose cron isn't set up yet.
08
Fully translatable: portal and email text comes from the plugin's language files.
A help center on your own site

A help center on your own site

Clients land on a help center that looks like the rest of your site, because it is the rest of your site: a Grav page, rendered by your theme, in light or dark. They search first, browse topics if they'd rather, and Contact us is always one click away. When they do write in, they never have to set a password. A sign-in link in every email takes them straight to their request.

Every ticket, the whole story

The ticket screen puts the conversation in the middle and the details beside it: status, priority, kind, assignee, project, who can read it, and the SLA clock with how long is left. Internal notes sit in the same thread, tinted so they can never be mistaken for a reply, and they never reach the client. Replies that came in by email say so, with a Show original link to the email as it arrived.

Every ticket, the whole story
Email that reads like a person wrote it

Email that reads like a person wrote it

Client email carries your logo, colors and footer, the agent's name and the reply, with a proper View request button and no ticket numbers or quoted history. When a reply also solves the request, it goes out as one email with How did we do? underneath. The client can just hit reply: with inbound email on, their answer goes straight back onto the ticket.

A knowledge base made of pages

Articles are ordinary Grav pages with the Help Article page type, so there's no second editor to learn and no separate content store. Each one gets breadcrumbs, related articles, More in this topic and Was this helpful? Answer No and the request form opens already filled in with what you searched for, and the ticket shows staff which articles you read before writing in.

A knowledge base made of pages
Rules you can test before they run

Rules you can test before they run

Rules read like sentences: when a ticket is created, if the subject contains invoice, set priority to High. Conditions cover projects, statuses, labels, channels, requesters, message text, custom fields, organizations, SLA state and ratings. Test against a ticket shows what a rule would do to a real ticket right now, and saves nothing.

SLA clocks that know your hours

Set first response and resolution targets per project, priority or kind, and count them in business hours with your own timezone, several ranges a day and holidays, or around the clock. The clock pauses while you wait on the client. Staff see in 2h or 35m late on every ticket, get warned before a target slips, and your clients never see any of it.

SLA clocks that know your hours

Your helpdesk, on your own site

No per-agent pricing, no support history sitting on someone else's servers, and no second login for your clients to forget. Helpdesk Pro runs on the same host as your Grav site, backs up with it and moves with it. Your staff work in the Admin Next they already use, and your clients deal with your site and your email address, nothing else.

Up and running

  1. Install the plugin along with the API, Login, Email and Form plugins, and enable it.
  2. In Admin Next, add a page with the Help Center page type, for example Help. Its route becomes your help center, and its content becomes the welcome text.
  3. Give your staff api.access and helpdesk-pro.desk (a helpdesk-agents group is a good start). The Helpdesk item appears in the Admin Next sidebar.
  4. Set your support address, and add the Grav scheduler to your crontab.
  5. Write a few articles with the Help Article page type.

When you're ready, turn on inbound email on the Email & Notifications tab of the plugin settings, and your clients can reply straight from their inbox.

A CLI for the operational side

BASH
bin/plugin helpdesk-pro status        # database, schema, job queue and worker health
bin/plugin helpdesk-pro migrate       # apply pending migrations (--status to preview)
bin/plugin helpdesk-pro work          # run one worker pass
bin/plugin helpdesk-pro jobs          # list, retry or cancel background jobs
bin/plugin helpdesk-pro reindex       # rebuild the search index
bin/plugin helpdesk-pro imap:poll     # read the IMAP mailbox now
bin/plugin helpdesk-pro blocklist     # manage blocked addresses, domains and words
bin/plugin helpdesk-pro erase         # erase a person's data

Full setup and configuration documentation lives on the Learn site.

A peek at sites running Helpdesk Pro.

Frequently Asked Questions

The most commonly asked questions about the Helpdesk Pro plugin

Is this a one-time purchase or a subscription?

Helpdesk Pro is a one-time purchase. You get all future updates and new features for free as long as your license stays active. There's no per-agent pricing and no cap on how many staff or clients you have, so your helpdesk doesn't get more expensive as your team grows.

Do my clients need an account or a password?

No. Clients can write in by email or through the request form as a guest, and someone who only ever emails you never gets a Grav account at all. When they want to see their requests, they type their address and we email them a sign-in link. The link in every client email signs them in too.

The first time a client uses a link, Helpdesk Pro creates a Grav account for them with site login only, in the groups you choose. An account that can reach the admin is never signed in this way, and staff never get sign-in links.

Does Helpdesk Pro work on Grav 1.7?

No. Helpdesk Pro is built for Grav 2 and Admin Next, and it needs the API plugin for the desk. If you are still on 1.7, take a look at the Migration chapter on the Learn site.

Do I need a database server?

No. Helpdesk Pro stores everything in one SQLite file, created and migrated the first time it's needed, at user/data/helpdesk-pro/db/helpdesk.sqlite. There's nothing to set up and no MySQL or PostgreSQL option to think about. It backs up and moves with your site like the rest of user/.

Helpdesk Pro writes a deny-all .htaccess next to the database for Apache. On nginx, Caddy or any other server that ignores .htaccess, deny that folder in your server config.

How do replies by email work?

Point your mail provider's inbound webhook at the address Helpdesk Pro gives you under Operations → Email in the desk, or let it read an IMAP mailbox every couple of minutes. Postmark, Mailgun, SendGrid, Amazon SES, Resend and MailerSend work through their Email plugin providers, Cloudflare Email Routing works with a small Email Worker, and a Postfix or Exim alias can pipe mail straight in.

Inbound email needs Email plugin 5.3.0 or later. Until you switch it on, everything else works as normal: client emails say View or reply to your request and link to the portal, and replies land in your support mailbox.

Do I need cron?

You should add the Grav scheduler to your crontab, because it runs the background worker that delivers email, digests, SLA warnings, time-based rules and IMAP polling. Most jobs run straight after the request that queued them anyway, and on a site whose cron hasn't run for a couple of minutes a small catch-up pass keeps notification email going. Treat that as a safety net, not a plan.

How does it look with my theme?

The portal inherits your theme's fonts and colors. Every color, radius and space comes from --helpdesk-* custom properties, and on a Pico-based theme such as Quark2 they follow Pico's own variables, so links and buttons use your theme's primary color with no work at all. One line of CSS (:root { --helpdesk-accent: #8428df; }) sets the accent anywhere else, and every portal template can be overridden from your theme.

Can AI agents work the desk?

Yes. Helpdesk Pro describes its API as 132 MCP tools, and grav-mcp hands them to Claude, Cursor and other AI clients. A tool can never do more than the API key it runs with, and tools that key can't use aren't offered. Ask the agent for an internal note first if you want to review a draft before the client sees anything.

What does Helpdesk Pro need to run?

Grav 2, PHP 8.3 or newer with pdo_sqlite, sqlite3, mbstring and dom, and these free plugins:

  • API for the desk, the REST API and MCP
  • Login for signing in
  • Email for sending mail (5.3.0 or later for inbound email)
  • Form for the request form and its captcha

The Sync plugin is optional and adds live updates. With Sync Mercure (1.2.2 or later) or Sync Ably, updates arrive instantly instead of by polling. Search is bundled, so you don't need YetiSearch Pro.

Can I use Helpdesk Pro on multiple sites?

Per the Grav Premium License, you need a license for each site. Development and staging copies of the same site are covered by the same license. Get in touch if you need bulk pricing.

Helpdesk Pro Changelog

v1.2.3

13 hours ago

    • KahunaCart refund and return requests open a ticket. When a customer asks for their money back on an order, a ticket opens with them as the requester and their own words as the opening message, so you can talk it over in the desk instead of copying their email address by hand. An internal note has the order number with a link to the order screen, what they asked for, the total and how it was paid, and the items, and the order's history links back to the ticket. It skips triage and sends no acknowledgement, since KahunaCart already did. Approving or declining the request on the order screen (or a return being refunded or cancelled) adds an internal note saying so and closes the ticket without emailing the customer: closed rather than resolved, so they don't get a "solved" email and a rating request on top of KahunaCart's refund email. The Store Requests section on the Portal & Access tab, shown only with KahunaCart, turns it off, picks the project and sets the label (store.refund_tickets, store.refund_project, store.refund_label). Closing the ticket needs KahunaCart 1.6.11
    • Smaller stars beside the desk menu's rows

v1.2.2

2 weeks ago

    • Star desk screens into the admin sidebar: a star beside each row of the desk menu puts that screen under Helpdesk in the Admin2 sidebar, one click away from anywhere in the admin. My work, All tickets and Triage show until you star your own, and the pencil at the foot of the Admin2 sidebar offers the same stars. A screen you may not open is never offered. Needs Admin2 2.2.0 and API 1.1.0 for the stars; older admins just don't show them

v1.2.1

2 weeks ago

    • Live updates in the desk and the portal now work with Mercure 1.x hubs as well as 0.x ones, and the hub token travels in a request header instead of the web address (Mercure 1.x needs sync-mercure 1.2.4). Thanks @Gleydar, whose sync-mercure fork this builds on getgrav/grav-plugin-sync-mercure#2

v1.2.0

2 weeks ago

    • Pushover is a notification channel type, beside Slack, Discord, the webhook and email. Paste your user key (or a delivery group's key) and an application token, optionally name a sound, and chosen ticket events arrive on the team's phones and desktops with a link into the desk. A missed SLA or an Urgent ticket gets through quiet hours, a resolved ticket arrives silently. Both keys are secrets like a webhook URL: masked in the desk, kept out of logs, and env:NAME works for each
    • Channels: Generate is offered only for a webhook's signing secret, the one secret you make up yourself. It used to appear beside every secret, including keys a service issues (an add-on type's API token), where a generated value could only fail

v1.1.0

2 weeks ago

    • Desk on a phone opens on the screen, not the menu. Under 900px wide the side menu used to sit above every screen, so each one started with the whole menu to scroll past. It's now a drawer: a bar at the top names the screen you're on (Work · All tickets), and tapping it slides the menu in from the right, clear of the admin's own menu on the left. Picking a row, tapping outside, the × or Escape closes it

v1.0.10

2 weeks ago

    • Desk: a long request title in Triage wraps under itself, left-aligned beside the ticket number, instead of centered under it
    • Desk: a row's ⋯ menu opens above the button when there isn't room below it, so the menu on the last ticket in the list can be reached (it ran off the bottom of the window, and scrolling closed it)

v1.0.9

3 weeks ago

    • Works on hosts that disable getmypid() and gethostname() (a common PHP-FPM hardening). The bundled grav-db-kit 1.0.6 falls back when building lease owners and job worker ids, which failed every lease taken in a web request and the job drain after each request. The temporary directories for an in-memory database are no longer named after the process id either getgrav/grav-premium-issues#625

v1.0.8

3 weeks ago

    • Desk: checkboxes (the ticket list's select column, Select all, and the checkboxes on forms) are their normal size again; they could be drawn huge beside other admin styles

v1.0.7

4 weeks ago

    • Desk: quote from the conversation into your reply. Select words in a message and a small Quote button appears beside the selection; it puts them into the open Reply or Note tab as a markdown quote, keeping paragraph breaks and code blocks, with an empty line after it
    • Desk: each message has Quote (the whole message, starting with "Name wrote:"), Copy the text and Copy a link, shown on hover and on keyboard focus (always on a touch screen). A copied link opens the ticket scrolled to that message (#/t/<id>?m=<message>)
    • Desk: drop files anywhere on a ticket's conversation or composer to attach them, like Attach files or a paste. The composer is outlined with "Drop files to attach" while files are dragged over it; other drags (links, text) are ignored, and nothing happens with attachments switched off
    • Desk: images open full size over the page instead of in a new tab, with the file name, a Download button and previous / next across the images of the same message (arrow keys too); Escape or a click outside closes it
    • Desk: a message with two or more files has Download all, which downloads them one after another
    • Desk: code blocks in the conversation have Copy and Wrap buttons, and show their language when the fence named one
    • Desk composer: Tab and Shift+Tab indent and outdent the lines of a code block by two spaces instead of leaving the editor, and "" (optionally with a language, "php") followed by Enter starts a code block as Space already did
    • Desk: ticket lists (All tickets and My work) show how many replies each ticket has, a small speech bubble and number after the subject. It counts the public messages after the request itself, and a ticket with no replies yet shows nothing; the tooltip also gives the number of internal notes
    • Desk: the ticket conversation reads like a chat. Each message is a rounded bubble with a light tint for whose side it is from (the client on the left on a neutral tint, staff replies on the right on a faint accent tint, notes on the staff side in the note colour with a dashed edge and a "Note · staff only" tag), with a small avatar of the author's initials. Messages by the same person a few minutes apart group, dropping the repeated avatar and name. Works in the light and dark themes
    • Desk: three or more changes in a row (status, labels, assignee…) fold into one line such as "Anna and Rules made 4 changes" that opens in place and stays open through live updates
    • Desk: the ticket's details sidebar starts closed so the conversation has the room, at a readable width. The new Details button in the ticket header opens and closes it and is remembered per browser; while closed it still names the assignee and shows a dot when an SLA target is due soon or overdue. Each sidebar card folds from its title and stays folded
    • Desk: the Triage card of a request waiting in Triage, and the line saying who else is viewing or replying, now sit above the conversation so they are never folded away
    • Desk: files under a message are cards with the file's type (PDF, ZIP, LOG…), name and size; the whole card downloads it
    • Desk composer: files waiting to be sent are cards with their name and size, an image with a preview of itself, and adding or removing one no longer redraws the editor
    • Desk: code in messages and in the composer is set in a monospace font, inline code as a small pill and code blocks in a box that scrolls sideways
    • Desk: the l shortcut opens the folded details sidebar and card to reach the label picker
    • Desk: a quote from the thread starts on its own line in the editor and leaves the caret after it, instead of joining the line the caret was on

v1.0.6

4 weeks ago

    • Client Groups (portal.client_groups) now reaches every client account, not only the accounts Helpdesk Pro creates: a client is added to the groups when they sign in by link or password, open the help center, or are linked to an account by staff, including accounts that already existed (a KahunaCart store customer's own account excepted, since the store manages its own customer groups)
    • Groups are only ever added, never removed. Helpdesk Pro records which configured groups it has already given each account, so a client you take out of a group stays out, and a group you add to the setting later reaches existing clients the next time they visit
    • A client group can never make a client staff: a group that does not exist, or that grants admin, desk or API access (admin.*, api.access, helpdesk-pro.*), is skipped for clients and a warning is logged
    • New setting Staff Groups (desk.staff_groups, on the Desk tab) puts every staff account in the groups you pick, the same way, the next time they use the desk
    • Client Groups and Staff Groups are now a picker of your site's existing groups instead of free text
    • New setting Client Store Groups (portal.client_store_groups, on the Portal & Access tab, shown only when KahunaCart is installed and enabled): the KahunaCart customer groups a store customer holds while they are a helpdesk client. It is granted live through KahunaCart's group-grant event (onKahunaCartCustomerGroupsGranted) with the reason "Helpdesk Pro client", never stored on the account, so it follows the person: unlink, block or erase them and it is gone, and taking a group out of the setting removes it from everyone on the next request. This is the opposite of Client Groups, which only adds. Staff never get it, and a store customer whose account was claimed by a YAML account counts the same way
    • A KahunaCart customer group also gives site.customer_group.<code> page access and can bring group pricing, discounts and the coupon, shipping and product rules a store builds on the group, so pick groups with that in mind. Helpdesk Pro listens to the event only while the setting names a group, looks the customer up with one indexed query per request, logs a failed lookup once and grants nothing, and never throws into the store