Password Resets

The password reset email is one of the most-clicked transactional messages your platform sends. Customising it for clarity, brand fit and trust is a low-effort, high-impact change.

The Default Template

Out of the box the template includes a greeting, a brief explanation, the reset button (with the unique tokenised URL), an expiry note, and a security disclaimer. Tokens used:

• {{user.firstName}} — the user's first name (or “there” fallback).
• {{resetUrl}} — the unique reset link, valid for the configured lifetime.
• {{tokenExpiry}} — the expiry timestamp in the user's timezone.
• {{site.name}} — your platform's name.
• {{requestIp}} — the IP that initiated the reset (optional, useful for security).

Editing the Template

1. Open Architect Panel → Email Templates.
2. Find password_reset and click Edit.
3. Adjust the subject (e.g. “Reset your YourBrand password”).
4. Edit the body. Keep the reset URL prominent — most users glance and click.
5. Send yourself a test before saving.

Best Practices

• Single primary CTA — one clear button, no distractions.
• Show the originating IP/location — deters phishing (“if you didn't request this from {{requestIp}}…”).
• Include a fallback URL in plain text — some email clients suppress buttons.
• Mention the expiry — “This link expires in 30 minutes” reduces support tickets.
• Sign with your domain — signed mail with consistent sender reputation lands in inbox, not spam.

Worked Examples

• Consumer app: Casual tone, friendly opener, branded header image.
• Financial app: Formal tone, includes IP/location, prominent “If you didn't request this, contact support immediately” warning.
• Healthcare: Includes a phone number for verifying authenticity by call.

The Enable Password Resets setting under Site Settings → Password Resets controls whether users can request a password reset themselves. When on, the "Forgot your password?" link appears on the login page and clicking it kicks off the reset flow. When off, the link is hidden and users who forget their passwords have to contact an admin.

Note that this setting only governs self-initiated password resets. Admin-initiated resets — where an admin opens the user's profile and clicks Reset Password — are always available regardless of this setting. The on/off toggle is about whether users have a self-service path.

What users see when enabled

A "Forgot your password?" link appears below the password field on the login form. Clicking it opens a form asking for their email (or username, depending on the login mode). The user enters their identifier, the platform looks it up, and — if it matches a known account — sends a reset email (or SMS, depending on the Password Reset Method setting).

The user clicks the link in the email, lands on a password-change form, enters a new password (twice, for confirmation), and they're done.

What users see when disabled

The forgot-password link is hidden. Users without password access must contact an admin to have their password reset. The admin opens the user's profile, clicks Reset Password, and either sets a new password directly or sends a reset link via email.

This is more secure (no anonymous reset flow to abuse) but less convenient — your support team will get tickets for forgotten passwords.

When to disable

Three concrete scenarios where disabling makes sense:

1. High-security internal apps

For apps where every account is provisioned by an admin (not self-registered), it's natural for password resets to also be admin-only. The support team is small, accounts are few, and the convenience cost of admin-mediated resets is low.

2. Apps where email is the credential being reset

If a user's email account is compromised, an attacker could request a password reset and intercept it. For apps in industries where this is a concrete concern (banking, healthcare), disabling self-reset and requiring identity verification through an admin is safer.

3. Apps using SSO exclusively

For installs where users authenticate through Azure AD, Google Workspace, or another SSO provider, ActiveManage's own password isn't really used. Password resets aren't relevant.

Three real-world configurations

• Consumer SaaS: Enable Password Resets on, Method email, Time Limit 30 minutes, branded template. Self-service, convenient, expected.
• Internal corporate app: Enable on, Method email, Time Limit 15 minutes, restricted to corporate email domain via custom validation. Self-service but tightened up.
• Highly-regulated app: Enable off. Admins handle every reset and verify identity out-of-band before issuing.

Tip: Even with self-service password reset enabled, consider implementing additional friction for high-value accounts — e.g. admins or accounts that have access to financial data. A custom validation that requires multi-step verification for those accounts adds defence-in-depth without inconveniencing the bulk of users.

Password resets can be delivered by email or SMS, controlled by the Password Reset Method setting under Site Settings → Password Resets. Each has trade-offs around cost, security, and user experience.

Email

The default and most common choice. Reset links arrive in the user's inbox; they click through to set a new password.

Advantages:

• Cheap. No per-message cost beyond whatever you already pay for outbound email.
• Familiar. Every user knows how a password-reset email works.
• Reliable. Modern email infrastructure (SPF, DKIM, DMARC) makes delivery near-perfect for legitimate senders.
• Works even when the user's phone is unavailable. Useful if they've lost or upgraded their phone.

Disadvantages:

• Vulnerable if email is compromised. An attacker who has access to the user's email can trigger and intercept password resets.
• Spam filters. Occasionally legitimate reset emails end up in junk folders. Test deliverability after every template change.
• Delivery delays. Most providers deliver near-instantly but occasional 5-10 minute delays happen, especially on first-send to a new recipient.

SMS

Reset links arrive via text message instead. The user receives a short message with a link or a code; they tap through (or enter the code) to set a new password.

Advantages:

• Separate channel from email. If email is compromised, SMS still works.
• Near-instant delivery. Typically arrives within seconds.
• Visible. Users notice SMS notifications more reliably than email.

Disadvantages:

• Per-message cost. SMS isn't free — pennies per message, but it adds up for popular apps.
• SIM-swap vulnerability. An attacker who can convince the user's phone carrier to port their number to a new SIM can intercept SMS. This is a real attack vector for high-value accounts.
• International availability. SMS delivery to some countries is unreliable or expensive.
• Requires a phone number on file. If your registration flow doesn't capture phone numbers, you can't use SMS reset.

Picking the method

For most apps, email is the right default. Three exceptions where SMS is worth considering:

Exception 1: Email is the credential being reset

If users log in with their email address, an attacker who compromises the email can trigger and intercept a reset. Using SMS as the reset channel breaks that link.

Exception 2: Field workers without reliable email

Some apps are used by field staff who don't routinely check email but always have their phone. SMS works better for that population.

Exception 3: High-value B2B accounts

For accounts with admin-level access to your platform, the extra friction and cost of SMS is justified by the higher security. Combine with TOTP-based 2FA for layered defence.

Time limit

Either way, the reset link expires after the configured Password Reset Time Limit (in minutes). Default is around 30 — short enough to limit replay risk if the email or SMS is intercepted, long enough that a user can find and click within a normal workflow.

For SMS specifically, you can usually go shorter (10 minutes) because SMS arrives near-instantly. Email can occasionally take longer to deliver so 30 is a safer minimum.

Tip: Consider supporting both. Some installs let the user pick between email and SMS at reset time, defaulting to whichever was used for their last login. That's the highest-flexibility option but requires custom code to implement — the platform's built-in setting picks one method globally.