Title: Allow flexible password reset delivery (email channel, trigger, webhook) and administrator-initiated password resets
-
What is your original issue/pain point you want to solve?
Currently, password reset emails are always sent using Zammad’s internal/system SMTP mechanism. In environments where email delivery is highly customized, integrated with external workflows, or requires specific sender identities, this creates a limitation because administrators cannot control which existing email account/channel is used for password reset communication.
Additionally, administrators currently cannot initiate a password reset process for selected users/agents directly from the administration interface. -
Which are one or two concrete situations where this problem hurts the most?
- Organizations using external automation, compliance, branding, or communication workflows need password reset emails to be sent from a specific mailbox that is already configured in Zammad.
- Organizations integrating Zammad with third-party systems may want to perform additional actions before sending the reset email, such as logging, auditing, MFA workflows, security checks, custom templates, or additional notifications.
- Security incidents may require administrators to force a password reset for one or more users.
- Why is it not solvable with the Zammad standard?
The current implementation appears to always use the internal/system SMTP process for password reset emails. There is no option to:
- Select one of the already configured email channels/accounts as the sender.
- Redirect the reset process through an existing email channel workflow.
- Execute a trigger, webhook, or automation event before the email is sent.
- Completely replace the email delivery with a custom integration.
- Force a password reset request for a selected user from the administration interface.
- What is your expectation/what do you want to achieve?
Ideally, administrators should be able to choose one of the following approaches:
Option A:
Allow password reset emails to be sent using a selected configured email channel/account instead of the system SMTP sender.
Option B:
Expose a dedicated trigger, webhook, or automation event when a password reset link is generated. This would allow administrators to implement their own delivery process using existing integrations.
For example, when a password reset is requested, Zammad could generate the reset token/link and trigger an event. Administrators could then use Zammad triggers, webhooks, or external integrations to send the email themselves using their preferred infrastructure and workflows.
Additionally, I would like administrators to be able to force a password reset for selected users/agents directly from the administration interface.
Example use cases:
- A user reports that they forgot their password and an administrator wants to immediately initiate the reset process on their behalf.
- A security incident requires an administrator to force one or more users/agents to reset their passwords.
- Periodic security procedures require selected operators to change their passwords.
- A newly created operator account should be required to complete a password reset before first use.
Ideally, this action would generate the same password reset flow and token as a standard user-initiated password reset request while respecting the configured delivery method (email channel, trigger, webhook, or custom automation).
If there is any more useful information, feel free to share it all (e.g.: mockup screenshots, if something is UI related, or the API URL/documentation URL for a service you need a connection to).
Example use case:
A company already uses custom email delivery logic and automation around outgoing communication. The password reset process is currently the only email flow that bypasses those existing mechanisms, creating inconsistency and reducing integration possibilities.
In our environment we use Zammad triggers extensively for automation. Having a dedicated password reset event would allow us to fully integrate the process with our existing workflows while maintaining auditability and consistent email delivery policies.
Your Zammad environment:
- Average concurrent agent count: 60
- Average tickets a day: 20
- What roles/people are involved: helpdesk teams, security teams, administrators
Anything else which you think is useful to understand your use case:
I’m adding this as a follow-up to a similar report, since it seems there was never any further update: Password reset emails can't use M365 channel?
This feature would improve flexibility without changing the default behavior. Existing installations could continue using the current mechanism, while advanced environments would gain the ability to integrate password reset delivery with their existing communication and automation infrastructure.
In addition, administrator-initiated password resets would reduce helpdesk effort, improve security response capabilities, and align password management with common functionality available in many identity and service management platforms.
Thank you and have fun.