Transactional Emails

Transactional emails are the auto-triggered system emails ClientCove sends in response to events — notifications, password resets, invoice confirmations, contract requests. They're the silent workhorse of the portal, going out around the clock without anyone hitting Send.

What Counts as Transactional

A transactional email has these properties:

• Triggered by an event, not a manual action
• One recipient per email (the person the event affects)
• Service-related content (account, billing, support, security)
• Functionally necessary — opting out would break the service

Examples:

• "You have a new ticket reply"
• "Your invoice was paid"
• "Click this link to reset your password"
• "Your contract is ready to sign"
• "Your file transfer expires tomorrow"

Compare to campaigns:

• "Check out our new feature" — marketing, optional
• "Year-end newsletter" — informational, optional
• "Holiday hours announcement" — informational, optional

ClientCove handles both — see Email Campaigns for the marketing/announcement side.

The Full Notification Type List

ClientCove fires transactional emails for these notification types:

Authentication (~7 types)

Type	Triggered when
Auth Code (2FA)	User logs in with 2FA enabled and needs to enter a code
Magic Link Login	User requests password-less login link
Registration Welcome	New user account is created
Registration Pending Approval	User signs up but admin approval is required
User Invitation	Admin sends an invite to a new user
Forgot Password / Reset	User clicks "Forgot password"
New User Welcome (Admin Created)	Admin manually creates a user account

Activity (~5 types)

Type	Triggered when
New Messages	A new message arrives in a thread the user is in
Task Assignments	A task is assigned to the user
Task Due Soon	Daily check finds a task due soon
Ticket Updates	A ticket the user is involved in is updated
Project Deadlines	A project deadline is approaching

Daily roll-up (~1 type)

Type	Triggered when
Daily Summary	Daily cron sends each user a summary of yesterday's activity

Invoices (~3 types)

Type	Triggered when
New Invoice	An invoice is sent to the client
Invoice Payment Received	A payment is recorded against an invoice
Invoice Overdue Reminder	Overdue cron flags an unpaid invoice

Contracts (~1 type)

Type	Triggered when
Contract Sign Request	A contract is sent to a recipient for signing

File Transfers (~5 types)

Type	Triggered when
Transfer Ready (Files Shared)	An outbound transfer is created
Upload Request	An inbound transfer is created
Upload Complete	Files arrive on an inbound transfer
Transfer Expiring	Transfer is approaching its expiration
Transfer Verification Code	OTP code for transfer email verification

That's 22 distinct notification types. Each one can use its own template, or fall back to a default.

How Template Selection Works

When ClientCove needs to send a transactional email, it goes through this resolution chain:

1. Find a template explicitly assigned to this notification type

   • Look in the Email Designer's templates
   • Check each template's "Notification Types" checkbox list
   • If multiple templates have this type checked, prefer the one with is_default = true
   • If still tied, prefer the most recently updated

2. Fall back to the portal-wide default transactional template

   • Set in Settings → Email Designer → Default Template
   • A single template that wraps any notification without a specific assignment

3. Fall back to the built-in plain template

   • Hard-coded in email-template-renderer.php
   • A clean, minimally branded layout
   • Used only when no defaults are set

This three-tier fallback means email always sends — even if no templates are configured, ClientCove uses the built-in plain template so nothing silently fails.

The Default Transactional Template

The portal-wide default is configured in Settings → Email Designer → Default Transactional Template:

1. Open Settings → Email Designer (or the Settings page)
2. Find the Transactional Emails card
3. Use the Default Template dropdown to pick from your existing templates
4. Save

The dropdown lists all templates created in the Email Designer. Pick the one that should serve as your portal's default look for all notifications without specific overrides.

If the dropdown is empty, you haven't created any templates yet — use the link to Create one in the Email Designer that the form provides.

Why have a default?

Setting a default means you don't have to assign every notification type to a template manually. Build one well-designed default, and 22 notification types instantly look branded. Then incrementally create specialized templates for events that benefit from custom designs (e.g. a richer New Invoice template, a more visual Task Assignment template).

Per-Feature Template Selection

For some features, the template selection happens per-record, not just per-notification-type:

Invoices

The invoice notification email picks the template assigned to:

• new_invoice (for the initial send)
• invoice_payment_received (for the payment confirmation)
• invoice_overdue (for overdue reminders)

If you want a different look for one specific invoice, that's not currently configurable per-invoice — adjust the template that handles that notification type.

Contracts

The contract_sign_request notification fires when a contract is sent. The template assigned to that notification type is used.

File Transfers

Five separate notification types map to different transfer events:

• transfer_ready — outbound link created
• upload_request — inbound link created
• upload_complete — files arrive on an inbound transfer
• transfer_expiring — approaching expiration
• transfer_verification_code — OTP for email verification

You can assign all five to one template, or split them across multiple templates if you want different designs for "files ready to download" vs "verification code" (which is typically minimal).

Built-In Plain Template

If no Email Designer templates exist and no portal-wide default is set, ClientCove uses a built-in plain template defined in email-template-renderer.php:

• White background
• Single-column layout, 600px max width
• Sans-serif font (Helvetica fallback)
• Simple header with portal name (no logo)
• Plain-text body content
• Minimal footer with company info

The built-in template is functional but unbranded. Create at least one template in the Email Designer as soon as you set up a portal so emails reflect your brand from day one.

Email Sending Infrastructure

ClientCove uses WordPress's wp_mail() function for actual delivery. Out of the box, this routes through PHP's mail() function, which is unreliable — emails often:

• Land in spam
• Get rejected by the recipient's mail server
• Fail silently with no error reported back to the user

For any production portal, you must configure SMTP routing through a proper transactional email provider.

Recommended SMTP Setup

The reliable setup:

1. Install WP Mail SMTP plugin

• Free version handles most needs
• Pro version adds advanced features

2. Configure a transactional email provider

• SendGrid (recommended — same provider used for inbound parse for tickets/tasks)
• Mailgun
• Amazon SES
• Postmark
• SparkPost

Sign up, generate an API key, paste it into WP Mail SMTP.

3. Configure your sending domain

At your domain provider:

• SPF record authorizing SendGrid (or your provider) to send on your behalf
• DKIM record signing your emails
• DMARC record specifying how to handle authentication failures

Each provider has docs walking you through the DNS records.

4. Verify the From address

Most providers require you to verify the email address (or domain) you send from. Add notifications@yourportal.com (or whatever From you use), respond to the verification email, you're good.

5. Test

• Send a test email from WP Mail SMTP's test panel
• Send a test from the Email Designer
• Trigger a real notification (create a test ticket, file a test invoice)
• Verify deliverability to multiple email providers (Gmail, Outlook, Yahoo)

Once SMTP is configured, deliverability typically goes from 60-70% to 98%+.

Sender Identity

The From address on transactional emails is configured globally:

From Email

Set in WP Mail SMTP (or your SMTP plugin). Use a consistent address like notifications@yourportal.com.

From Name

Also set in WP Mail SMTP. Typically your portal name (e.g. "Acme Portal" or "Acme Notifications").

Reply-To

For most transactional emails, you want replies to go to a real human — not bounce into the void. Set Reply-To in your SMTP config to a monitored inbox like support@yourportal.com.

Some templates can override From/Reply-To per email type if you've customized them, but the global config is the default for everything.

Compliance Notes

Transactional emails are generally exempt from anti-spam laws (CAN-SPAM in the US, CASL in Canada, GDPR in Europe) because they're functional — they relate to a service the user actively uses.

However:

• Unsubscribe links are not required on transactional emails, but a "Manage your notification preferences" link is recommended
• Sender identification is still required — every email must clearly identify who sent it
• Honest subject lines — no misleading content
• Honor user preferences — if a user has notifications turned off for a given type in their profile, don't send it

ClientCove respects user notification preferences automatically — events for users who've disabled that notification type don't trigger an email.

For marketing emails (campaigns), the rules are stricter. See Email Campaigns for the full list.

Debugging Failed Emails

When emails aren't arriving:

1. Check the server email log

• WP Mail SMTP has a log of all attempts
• Look for delivery failures (specific error messages)

2. Check spam/junk folders

• Especially for new From addresses without authentication
• Once SPF/DKIM/DMARC are set up, this is much rarer

3. Check the provider dashboard

• SendGrid / Mailgun / etc. shows every email attempted
• Bounces, rejections, and spam reports are itemized

4. Test from the Email Designer

• Send Test Email button — if this works, your SMTP is fine and the issue is event-specific
• If this fails, fix SMTP first

5. Check user notification preferences

• The user might have disabled the specific notification type
• Check their profile under "Notification Preferences"

6. Check the activity log of the source feature

• Invoice activity log shows email send events
• Ticket activity log shows notification fires
• If the log shows "Email sent" but the user didn't get it, problem is downstream (SMTP / spam)
• If the log shows nothing, problem is upstream (event didn't trigger or notification was suppressed)