Update Halo Ticket from Email

The Update Halo Ticket from Email action locates an existing Halo ticket from an incoming email sent by a person and adds a new "Email Update" entry to the ticket timeline. The original ticket details (the problem statement) are preserved. The action can also optionally change the ticket's status when the entry is added. It first tries ticket-number matching, then can fall back to Reply-All Storm Catcher when no ticket number is present.

Designed for Person-Originated Email

This action associates the entry with a Halo user based on the sender's email address. It is not the best choice for system-generated emails (monitoring alerts, web form submissions, automated notifications) where the sender address does not represent a real person in Halo. For those scenarios, use Update Halo Ticket with a known ticket ID.

Complete Workflow

This is a complete workflow action. It scans the email for a Halo ticket number and uses MSPintegrations business logic to locate the matching ticket and associated user before adding a new timeline entry. If ticket-number matching fails, it can optionally use Reply-All Storm Catcher to match the ticket from email thread headers. If you already know the ticket ID, use Update Halo Ticket for direct control. Learn more about the difference between workflow actions and single API call actions.

When to Use This Action

Use this action when:

• You want to add reply entries to existing tickets based on incoming human-generated emails
• You need to detect ticket numbers from email subject lines or body content
• You want Reply-All Storm Catcher to match replies that do not include a ticket number
• You want automatic user matching to associate the entry with the email sender

Don't use this action for:

• Creating new tickets: Use Create Halo Ticket from Email to create a ticket from an inbound email, or Create Halo Ticket if you already know the user and client IDs.
• System-generated emails: Monitoring alerts, web form submissions, and automated notifications where the sender address is not a real person's email. The user lookup will not produce useful results. Use Update Halo Ticket with a known ticket ID, or use the individual API Call actions to build a custom workflow.
• Known ticket IDs: If you already know the ticket ID, use Update Halo Ticket instead.

Common Pattern: Pairing with Create Halo Ticket from Email

This action is typically used together with Create Halo Ticket from Email in a two-step pattern:

1. Update Halo Ticket from Email runs first and attempts to find an existing ticket from a ticket number in the email.
2. If no ticket is found, Create Halo Ticket from Email runs next to determine the user and client from the email address and create a new ticket.

This pattern handles both replies to existing tickets and new support requests with a single rule:

Rule: "Process Support Email"
  1. Update Halo Ticket from Email
     - If ticket found: adds Email Update entry, workflow stops (or continues based on your setting)
     - If no ticket found: sets flag and continues to next action
  2. Create Halo Ticket from Email
     - Determines user and client, creates new ticket only if step 1 didn't find one

If your workflow has already determined the Halo user and client by the time it gets to ticket creation (for example, by calling Find Halo User and Client by Email or by looking them up another way), use Create Halo Ticket directly instead of Create Halo Ticket from Email.

One Canonical Sender Email Address

A single Email From Address parameter drives sender attribution for the entire request. You configure one address: MSPintegrations uses it to:

• Look up the matching Halo user (returned in the result's User variable).
• Send to Halo as the new action's emailfrom.
• Attribute the new timeline entry to the matched user via Halo's who_type=2. When no Halo user matches the address, the action falls back to the raw Email From Address as the display name.

This eliminates the need for a separate "Created By" display name parameter. The action always classifies the new entry as end-user activity (not agent activity) when the Email From Address is set.

How It Works

This action operates in two phases: first it finds the ticket, then it updates it.

Phase 1: Find the Ticket

1. Search for a ticket number: Scan configured fields (subject, body, etc.) for a Halo ticket number using the configured pattern
2. Reply-All Storm Catcher (optional): If no ticket number is found, search the email In-Reply-To and References headers for message IDs that were previously associated with a Halo ticket for the selected connection
3. Query Halo: Verify the ticket exists in Halo
4. Look up sender: Search for a Halo user matching the Email From Address

If no ticket is found, the action sets UnableToLocateExistingTicket to true and continues to the next action (typically Create Halo Ticket from Email).

Reply-All Storm Catcher

Reply-All Storm Catcher handles the common case where someone replies to an existing email thread, but that reply is delivered to MSPintegrations without the Halo ticket tag (for example, because a user hit Reply All on an earlier message in the thread that was never processed through the PSA).

When the ticket-number search returns no match and Reply-All Storm Catcher is enabled, the action reads the Message-ID values from the email's In-Reply-To and References headers and looks them up against MSPintegrations's record of Message-ID to Halo ticket associations for the selected Halo connection. If any of those Message-IDs were previously associated with a ticket on this connection, the action updates that ticket as if the email had contained the ticket number directly.

The other Halo ticket actions (create, update, note, attach files) record these Message-ID associations whenever they successfully operate on a ticket inside an inbound email workflow.

Phase 2: Add the Email Update Entry

Once a ticket is found:

1. Add the entry: Create a new ticket timeline entry with the configured reply content. MSPintegrations sends both a plain text version (note) and an HTML version (note_html) so the Halo UI renders the reply with line breaks preserved.
2. Set the outcome: Tag the new entry with the configured outcome. Defaults to "Email Update", matching Halo's native inbound-email handler.
3. Attribute the entry to the sender: If a Halo user matches the Email From Address, the entry is attributed to that user. If no Halo user matches, the entry is attributed to the raw Email From Address. Either way, Halo classifies the entry as end-user activity (not agent activity).
4. Populate email-source fields: Email From Address, the resolved recipient and CC lists from the three recipient checkboxes, Email Subject, and the inbound email's Message-ID are sent to Halo so the audit trail reads as customer email activity.
5. Update status (optional): Change the ticket status when the entry is added if a Status After Update value is configured.

---

Ticket Number Detection

The action searches the fields you specify for a ticket number delimited by an Email Start Tag and an Email End Tag. These are literal strings (not regex): the action looks for the start tag, followed by one or more digits, followed by the end tag.

Match Your Halo Email Tag Settings

The Email Start Tag and Email End Tag values must exactly match the values configured in your Halo instance under Configuration > Email > General Settings. Halo uses these tags when generating outbound email subjects, and MSPintegrations must use the same tags to correctly extract the ticket number from the incoming email reply.

For example, with the Halo default settings ([ID: and ]), the subject Re: Printer not responding [ID:0002588] yields ticket number 2588.

You can configure the action to search:

• Email subject
• Email body
• Custom parsed values from previous actions
• Any other available variable

If your Halo instance uses custom tags (for example, <TKT- and > producing subjects like <TKT-12345>), set Email Start Tag to <TKT- and Email End Tag to >.

Customer Attribution on the Entry

The new entry is attributed to the customer in the Halo UI through user lookup against the configured Email From Address. When a Halo user matches, that user's name appears as the entry's author. When no Halo user matches, the raw Email From Address appears as the author instead. Either way, MSPintegrations classifies the entry as end-user activity so the ticket timeline shows the customer rather than the API user authenticated by the Halo connection.

Configuration

Connection

Field	Description
Halo Connection	Select the Halo connection to use for this action.

Ticket Matching

Field	Description	Default
Fields to Search for Ticket Number	Inbound email fields the system scans for an existing Halo ticket number, looking for the configured Email Start Tag and Email End Tag (for example [ID:0002598]). Defaults to the email subject, which is where Halo places the tag on outbound replies. Add {{email.body}} if senders quote the tag in the body but strip it from the subject. The run log records each field scanned so misconfigurations are easy to spot.	{{email.subject}}
Email Start Tag	Literal text that appears immediately before the ticket number in Halo outbound email subjects. Must match the value configured in Halo under Configuration > Email > General Settings.	[ID:
Email End Tag	Literal text that appears immediately after the ticket number in Halo outbound email subjects. Must match the value configured in Halo under Configuration > Email > General Settings.	]
Enable Reply-All Storm Catcher™	When enabled, if no ticket number is found, use In-Reply-To and References headers to match a previously associated ticket for this Halo connection.	Enabled

Note Content

Field	Description	Default
Note Text	The reply content in plain text. MSPintegrations also generates an HTML version of this same content so the Halo UI displays the reply with line breaks and paragraph spacing preserved. You do not need to supply HTML. Supports text expressions.	Email headers and body content
Outcome	The outcome to record on the new ticket entry (for example, "Email Update", "Public Note", "Private Note"). Defaults to Halo's "Email Update" outcome to match Halo's native inbound-email handler for reply messages. The list of available outcomes comes from your Halo instance under Configuration > Tickets.	Email Update

Status After Update (Optional)

Field	Description
Status After Update	Optionally change the ticket status when the entry is added. Leave empty to keep the current status.

Email-Source Attribution

Field	Description	Default
Email From Address	The email address of the person whose reply triggered this update. MSPintegrations uses this single value to look up the matching Halo user, send it to Halo as the new entry's emailfrom, and as the fallback display name when no Halo user matches. Leave empty to skip user lookup and email-source attribution. Supports text expressions.	{{email.from.address}}
Add email sender to ticket recipients	When checked, the system adds the Email From Address to the ticket update's recipient list, so the new entry on the ticket reflects that this person was the sender.	Checked
Add email recipients to ticket recipients when they are Halo users	When checked, the system looks at each address in the Email Recipients to Evaluate field, checks whether that address belongs to a Halo user, and adds the ones that do to the ticket update's recipient list.	Unchecked
Email Recipients to Evaluate	The list of email addresses the system checks against Halo for inclusion in the ticket update's recipient list. By default, this uses the addresses on the inbound email's To line. Override this when processing an email whose To line does not represent the people who should be on the ticket update, for example a forwarded message or an automated system that sends on behalf of other people. Provide the addresses as a semicolon-separated list. Supports text expressions. Enabled only when Add email recipients to ticket recipients when they are Halo users is checked.	{{implode email.to glue="; " property_name="address"}}
Add email CC recipients to ticket CC recipients when they are Halo users	When checked, the system looks at each address in the Email CC Recipients to Evaluate field, checks whether that address belongs to a Halo user, and adds the ones that do to the ticket update's CC list.	Unchecked
Email CC Recipients to Evaluate	The list of CC email addresses the system checks against Halo for inclusion in the ticket update's CC list. By default, this uses the addresses on the inbound email's CC line. Override this when processing an email whose CC line does not represent the people who should be CC'd on the ticket update. Provide the addresses as a semicolon-separated list. Supports text expressions. Enabled only when Add email CC recipients to ticket CC recipients when they are Halo users is checked.	{{implode email.cc glue="; " property_name="address"}}
Email Subject	The original email subject. Sent to Halo as the new entry's emailsubject. Leave empty to omit. Supports text expressions.	{{email.subject}}

Workflow Control

Field	Description	Default
Action If No Ticket Matched	What happens if no matching ticket is found. Set to Continue to allow subsequent actions (like Create Halo Ticket from Email) to run.	Continue
Action After Update	What happens after successfully updating the ticket.	Stop All
Error Handling	What happens if the Halo API returns an error.	Exception

Returned Variables

When you configure Store the results in Variable, these variables become available for use in subsequent actions:

Status Flags

Variable	Type	Description
IdentifiedTicketNumber	bool	true if text matching the ticket number pattern was found
LocatedExistingTicket	bool	true if the ticket was found in Halo
UnableToLocateExistingTicket	bool	true if no matching ticket was found (signals Create Halo Ticket from Email should run)
LocatedUser	bool	true if a Halo user matching the sender's email was found
UpdatedTicket	bool	true if the new entry was successfully added to the ticket
UpdatedTicketCausedError	bool	true if adding the entry failed

Retrieved Objects

Variable	Type	Description
Ticket	object	The matched Halo ticket (see properties below)
User	object	The matched Halo user from the sender's email (see properties below)

Ticket Properties

Property	Type	Description
id	number	The ticket ID
summary	string	The ticket summary
details	string	The ticket details
client_id	number	The client ID
client_name	string	The client name
user_id	number	The user ID
user_name	string	The user name
status_id	number	The status ID
status_name	string	The status name
priority_id	number	The priority ID
priority_name	string	The priority name

User Properties

Property	Type	Description
id	number	The user ID
name	string	The user name
emailaddress	string	The user's email address
client_id	number	The client ID
client_name	string	The client name

Example usage: {{custom.myVariable.Ticket.id}}

FAQs

Do I need to supply HTML for the reply body?

No. Configure the Note Text field in plain text. MSPintegrations converts it to HTML internally for Halo's HTML rendering, preserving line breaks and paragraph spacing. The Halo UI displays the HTML version automatically.

What happens if no ticket number is found in the email?

If Reply-All Storm Catcher is enabled, the action checks thread headers first. If that lookup also fails, the action sets UnableToLocateExistingTicket to true and continues to the next action (when Action If No Ticket Matched is set to Continue). This allows Create Halo Ticket from Email to run and create a new ticket.

What ticket number formats are recognized?

The action looks for text in the form <Email Start Tag><digits><Email End Tag>. By default these tags are [ID: and ], matching Halo's out-of-the-box outbound email format (for example, Re: Test from Travis - Ticket Update [ID:0002588] yields ticket 2588). If your Halo administrator has changed these values in Halo's Configuration > Email > General Settings, update the matching fields on this action so they stay in sync.

Where do I find my Halo Email Start Tag and Email End Tag?

In Halo, go to Configuration > Email > General Settings. Look for the Email Start Tag and Email End Tag fields. Whatever values your Halo instance uses there must be entered exactly on this action.

How does Reply-All Storm Catcher pick the ticket?

Every Halo ticket action that runs in an email workflow (create, update, note, attach files) records the email's Message-ID against the Halo ticket ID on the selected Halo connection. When a later email arrives without a ticket number, this action collects all Message-ID values from its In-Reply-To and References headers and looks them up against that record. If any of those Message-IDs belong to a ticket on the selected Halo connection, that ticket is updated.

Can I update tickets without adding a timeline entry?

No, this action always adds a new entry. If you only need to change ticket fields (status, priority, assignee, etc.) without recording a new entry, use Update Halo Ticket instead.

What if the sender's email doesn't match any Halo user?

The action still updates the ticket. The new entry is attributed to the raw Email From Address as the display name (the customer's email shows in place of a user name in the Halo UI), and Halo still classifies it as end-user activity. The LocatedUser flag is set to false and the User object is null.