Ticket notification emails

View as Markdown Open in ChatGPT Open in Claude

Outpost emails a ticket’s requester when something happens on their ticket: it is created, a technician replies, or its status changes. You choose which of these emails are sent and write their subject and body. On the MSP plan you set them once as MSP defaults, and every client sends them until you customize that client. This page lists the emails, who receives them, the placeholders you can use, and where to change them.

Where the emails are

Emails	Where	Who can change them
One desk’s emails (Enterprise), or one client’s (MSP)	Tickets > Notifications, or the Notification emails tab of Tickets > Desk settings. On the MSP plan, open the client first.	`ticket:manage`
MSP defaults for every client (MSP)	Inbox > Desk defaults > Notification emails	`ticket:manage`

On a ticket that came in by email, the emails go out through the support mailbox the ticket arrived on. Other tickets’ emails go out through your outgoing email provider. See Email and threading and Configure outgoing email.

The emails

Email	Sent when	On by default
Ticket created	A ticket is opened for the requester in the console or the tray app, from a software request, by promoting a chat, or by an email to a support mailbox.	Yes
Public reply	A technician posts a public reply, or the requester replies by email. Internal notes are never sent.	Yes
Status changed	The status changes, other than resolving or reopening.	No
Resolved	A ticket moves to a solved or closed status.	Yes
Reopened	A solved or closed ticket is opened again.	No

Resolved and Reopened follow the status group, so a status you add in the Solved or Closed group counts as resolved. See Desk settings.

On a parent ticket, a public reply copied to a child, and a child solved or closed with its parent, send the child’s requester the same emails.

Who receives them

Each email goes to:

The ticket’s requester.
Every participant on the ticket with the CC role.

Each address is sent the email once. These are left out:

Whoever made the change. A technician who replies is not sent their own reply, even when they are also a participant. A customer whose email opened or updated the ticket is not sent their own message, but the people on the ticket’s CC list are.
Everyone, CCs included, on a ticket marked Unverified sender, until a technician selects Verify sender. See Sender verification.
A requester shown as Unverified requester, because nobody has confirmed who the endpoint account belongs to. See Tickets.
A requester or participant with no email address.
An address a workflow’s or rule’s Email an address step emails for the same change, so nobody gets two emails about one event.

Email and threading

When a ticket came in through a support mailbox, its emails go out through that same mailbox:

A Microsoft 365 or Google Workspace mailbox sends them itself, so they come from the support address and appear in its sent mail.
An IMAP mailbox sends them through its SMTP server, when one is set.
Otherwise they go out through your outgoing email provider, with the support address as Reply-To.

Every email carries the headers a mail app uses to show one conversation, and the subject carries the ticket’s tag, such as [OUT-1042-7f3a]. The built-in subjects start with {{ticket.number}} in brackets, which becomes the full tag. A subject you write without it gets the tag added at the end. When the customer replies, the reply joins the ticket. A mailbox can hide the tag. See Email threading.

A technician’s public reply goes out as an ordinary email from a person. The other emails, such as Ticket created and the status emails, are marked as automatic, so the customer’s mail system does not answer them with an out-of-office reply.

Edit an email

Each email has its own card:

Field	What it sets
Send this email	Whether the email is sent. Turned off, nobody receives it.
Subject	The subject line, up to 255 characters. Line breaks are removed.
Body	The message, in plain text. Line breaks are kept.

Select Save on the card. A subject or body that uses a placeholder not listed below is refused when you save, and the field says why.

Each email is sent as plain text and as HTML with the same wording. Values such as a reply are inserted as text, so anything that looks like HTML in a reply arrives as written, not as markup.

Placeholders

Use these in a subject or body. The settings page lists them beside the emails.

Placeholder	Prints
`{{ticket.number}}`	The ticket reference, for example `OUT-1042`.
`{{ticket.subject}}`	The ticket subject.
`{{reply.body}}`	The public reply. For Ticket created, the opening message. Empty for the status emails, which have no reply.
`{{status}}`	The status name, such as On hold or a status you added.
`{{portal.link}}`	A link to the ticket in your requester portal. Empty when no portal address is set. See Portal link.

Preview an email

Select Preview on a card to render the subject and body as they are typed, saved or not, against a sample ticket, OUT-1042. The preview warns when a placeholder will print nothing, such as {{reply.body}} in a status email, or {{portal.link}} with no portal address set.

Portal link

{{portal.link}} prints your requester portal address followed by the ticket’s path, so a requester can open their ticket from the email. The built-in emails end with it.

Where you set the address depends on your plan:

Enterprise: select Tickets > Desk settings, then the Notification emails tab. Under Requester portal, enter the Portal address and select Save.
MSP: there is nothing to set. The link goes to your client portal: a client’s own custom domain once it is active, else your custom domain for every client, else your Outpost address. Inbox > Desk defaults, under Requester portal, shows the address with a copy button.

On Enterprise, the address must start with https://. With no portal address, {{portal.link}} prints nothing and the rest of the email is sent as written, and Preview warns that the link is empty.

MSP defaults and per-client emails

On the MSP plan, Inbox > Desk defaults > Notification emails sets the emails every client sends until you customize that client. Each card is labeled with where its text comes from:

Label	Meaning
Product default	The text Outpost ships with.
MSP default	Your MSP defaults. On Desk defaults, Use product default returns an email to the product’s text.
Customized for this client	This client’s own text.

A client’s notification emails show Using MSP defaults until someone saves a change there. That first change makes all five emails the client’s own, and MSP changes to them stop reaching that client. Revert to MSP defaults, then Revert, returns the client to the MSP defaults. See Desk settings.

Content is licensed CC BY 4.0. Code samples are MIT. Outpost and the Outpost mark are trademarks of Outpost Business Solutions, PBC and are not covered by either license.