A Zammad package that lets agents write a reply now and have Zammad send it at a later point in time — the "send later" feature that Zammad itself does not offer (feature request open since 2020).
Status: working prototype. Scheduling a reply from the ticket editor and having it delivered at the chosen time is verified end to end on Zammad 7.1.2. Attachments, recurring schedules and the new Vue desktop view are not supported yet. See docs/ARCHITECTURE.md for the design.
Send later… sits in the dropdown next to Update, above Draft and Macros. Nothing is added to the compose area — the control only appears when it is asked for.
It opens a dialog with a time picker, defaulting to an hour from now, and lists replies that are already waiting so they can be called back.
A reply that has not gone out yet then sits in the thread like any other message, framed to say it is not final, with the time it is due underneath and the two actions that matter on it.
Agents often finish an answer outside business hours, at night or on weekends, but the customer should not receive it at 23:40. Today the only options are keeping a draft and remembering to send it, or building a workaround out of custom fields and scheduler jobs. This package adds the missing piece.
A scheduled reply is not stored as a ticket article. It lives in its own
table until the moment it is due; only then does the package create the real
Ticket::Article, which Zammad delivers through its regular mail pipeline.
That ordering matters: an article created upfront would already appear in the ticket, count towards SLA and fire triggers, long before the customer ever sees it.
- Zammad 7.0 or later — tested on 7.0.2 (Debian package) and 7.1.2 (Docker)
- The classic desktop interface. The new Vue desktop view under
/desktopis not supported — see docs/ARCHITECTURE.md.
The frontend is a CoffeeScript file in Zammad's asset pipeline, like any other package, so it is compiled during installation.
Download the .zpm from the
releases page,
install it, run the post-install step, restart Zammad:
zammad run rake zammad:package:install /path/to/zammad_scheduled_send-0.1.1.zpm
zammad run rake zammad:package:post_install
systemctl restart zammad
post_install is the step the installer itself points to — it runs the package
migrations and compiles the assets. Verified on a Debian package installation
of Zammad 7.0.2.
The restart is not optional. Until the services are restarted the running
processes do not know the new routes, and the package sits there doing nothing —
/api/v1/scheduled_articles answers 404 rather than 403.
The package can also be uploaded under Manage → System → Packages; the same
two steps follow on the server. To build the .zpm from source instead of
downloading it: bin/build-zpm 0.1.1.
On Docker the installation succeeds but the feature stays invisible unless three things are in place. There is no error message for this.
- an image with node — the official one has no JavaScript runtime, so the asset
build cannot run.
Dockerfile.exampleis a working starting point. - the package installed in every Zammad container, not just one
public/assetsshared between the railsserver and the nginx container
Why each of them is needed: docs/ARCHITECTURE.md.
zammad run rake zammad:package:uninstall /path/to/zammad_scheduled_send-0.1.1.zpm
zammad run rake zammad:package:post_install
systemctl restart zammad
This drops the scheduled_articles table, and with it any reply that was still
waiting.
AGPL-3.0-or-later, matching Zammad itself. See LICENSE.