Create Halo Ticket from Email

The Create Halo Ticket from Email action creates a new Halo ticket from an inbound email sent by a person. It looks up the Halo user and client from the configured email address, optionally creates a new Halo user when no match is found, creates the ticket as email-imported, and optionally attaches the email's files. The result is a ticket that looks identical in the Halo UI to one Halo's own inbound-email handler would produce. Halo's API automatically adds a customer-attributed "Opened" entry on the ticket timeline carrying the email body, so the conversation reads as the customer's activity from the start.

Designed for Person-Originated Email

This action associates the created ticket with a Halo user and client based on a person'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 the individual API Call actions directly, where you can specify the client and user explicitly.

Complete Workflow

This is a complete workflow action that orchestrates several building block and API call actions: Find Halo User and Client by Email, Create Halo User, Create Halo Ticket, and Attach Files to Halo Ticket. It wraps all of them into a single configurable action. 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 create a Halo ticket directly from an incoming email with a single action
• You need MSPintegrations to determine the Halo user and client from an email address
• You want the option to create a missing Halo user on the fly

When NOT to Use This Action

• The workflow has already determined the user and/or client: If an earlier action in your workflow already determined the Halo user or client (for example, by calling Find Halo User and Client by Email or by looking them up directly), use Create Halo Ticket directly. Passing the known IDs gives you precise control and avoids re-running the determination logic.
• Replies to existing tickets: Use Update Halo Ticket from Email first to detect and update the existing ticket.
• System-generated emails: Monitoring alerts, web form submissions, and automated notifications where the sender address is not a real person's email. The user/client determination logic will not produce useful results for non-person senders. Use the individual API Call actions where you can specify the client and user explicitly.
• Non-email data sources: This action requires an inbound email context. Use the single API call actions for other sources.

Common Pattern: Pairing with Update Halo Ticket from Email

This action is typically used together with Update 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 create a new one.

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
     - Creates new ticket only if step 1 didn't find one

One Canonical Sender Email Address

A single Email From Address parameter drives every "sender" field on the ticket. You configure one address: MSPintegrations uses it to:

• Look up the matching Halo user and client.
• Mark the ticket as email-imported (Halo records "Logged from email <sender>" in the audit trail).
• Populate user_email and reportedby on the ticket.
• Provide the default value for the ticket's recipient and CC lists so future agent replies from the ticket go to the right people.

When all three of emailfrom, user_email, and user_id are sent together, Halo's API automatically creates a customer-attributed "Opened" entry on the ticket timeline that carries the email body. This action does not post a separate "First User Email" entry to avoid duplicating the email body on the timeline.

The Email From Address does not have to be the email's From header. It supports any text expression, so you can pull the address from:

• The email's From header (the default)
• The email's Reply-To or To header
• A value extracted from the email body or subject, for example when the true sender is embedded in a web form submission or an automated notification

This is useful for web form emails and automated messages where the sending mailbox is a noreply address but the real customer email is inside the body.

Reply Recipient Model

Halo's ticket recipient and CC lists decide who receives email when an agent replies from the ticket. This action builds those lists from three checkboxes plus a per-address Halo user check:

• Add email sender to ticket recipients (default on): adds the Email From Address to the recipient list, so future replies from the ticket go back to the person who sent the email.
• Add email recipients to ticket recipients when they are Halo users (default off): when checked, the system evaluates each address in the Email Recipients to Evaluate field, looks up each one in Halo, and adds the ones that belong to a Halo user to the recipient list. Addresses that do not belong to a Halo user are skipped.
• Add email CC recipients to ticket CC recipients when they are Halo users (default off): same behavior for the Email CC Recipients to Evaluate field, applied to the ticket's CC list.

The Halo user check makes it safe to default the recipient evaluation lists to the inbound email's To and CC lines. Addresses that are not Halo users (the hosted mailbox the email was sent to, distribution lists, external contacts not registered in Halo) are filtered out automatically.

Override the Email Recipients to Evaluate and Email CC Recipients to Evaluate defaults when the inbound email's To and CC lines do not represent the people who should appear on the ticket, for example when processing a forwarded message or an automated system that sends on behalf of other people.

How It Works

This action chains several building-block actions together. You can reproduce the same flow manually by placing those actions in sequence, but using this single action keeps your rule compact.

Step 1: Determine the User and Client

The action determines the client this way:

1. Search Halo for a user whose email address matches the configured Email From Address. If a match is found, the ticket uses that user's client and site.
2. If no user matches and Create User If Not Found is enabled, search for a client by the email's domain. If a domain match is found, the ticket uses that client and its main site.
3. If no client has been determined yet, use the configured Default Client and its main site.
4. If the Default Client field is left empty, the ticket uses Halo's built-in "Unknown" client (ID 1) and "Unknown" site (ID 1).

This guarantees a client is always determined. When Create User If Not Found is disabled, the action skips the domain lookup entirely so that unmatched senders fall through directly to the configured Default Client (or the Unknown client when that field is empty). This is how to route every unmatched email to a single triage client.

Step 2: Create the User (Optional)

If no user matches and Create User If Not Found is enabled, the action creates a new Halo user under the determined client using the configured Sender Name and Email From Address. This is equivalent to running Create Halo User as a follow-up step.

If Create User If Not Found is disabled and no user matches, the action skips user creation and assigns the ticket to the resolved Default Client (typically the Unknown client) without a user reference.

The Sender Name is parsed into Halo's first name and last name fields. MSPintegrations uses the first whitespace-separated token as the first name and joins the remaining tokens as the last name, so "Mary Jane Watson" becomes first name "Mary" and last name "Jane Watson". The "Last, First" comma form is also recognized: "Watson, Mary" becomes first name "Mary" and last name "Watson". This is more accurate for multi-token last names than Halo's native inbound-email handler, which discards everything after the second token. Records created via this action may therefore have different first name and last name values from records Halo would create from the same email natively.

Step 3: Create the Ticket

The action creates a new Halo ticket using the determined client and user along with the configured Summary, Details, and classification fields (type, status, priority, category, SLA, agent, team).

The ticket description defaults to the email body. You configure Details as plain text. MSPintegrations also generates an HTML version of the same Details value and sends it to Halo so the ticket renders with line breaks and paragraph spacing preserved in the Halo UI. You never need to supply HTML.

The action also passes the configured email-source fields to Halo so the ticket is recorded as email-imported and shows "Logged from email <sender>" in the audit trail instead of attributing the creation to the MSPintegrations API user authenticated by the connection:

• emailfrom, user_email, and reportedby derive from the Email From Address.
• emailtolist comes from the three recipient checkboxes (the To list Halo uses on future agent replies).
• emailcclist comes from the three recipient checkboxes (the CC list Halo uses on future agent replies).
• emailsubject comes from Email Subject.
• internet_message_id is the inbound email's RFC 5322 Message-ID, used by Halo for native threading.

Because emailfrom, user_email, and user_id are all sent, Halo's API automatically creates a customer-attributed "Opened" entry on the ticket timeline carrying the email body. The author is the matched Halo user (or the raw Email From Address when no user matches). The action does not post a separate timeline entry, so the email body appears only once on the ticket.

Step 4: Attach Files (Optional)

If Attach Email Attachments is enabled, the action uploads the email's attachments to the new ticket. If Attach Original Email .eml is enabled, the original email is also uploaded as a single .eml file. This is equivalent to running Attach Files to Halo Ticket as a follow-up step.

If you later need to add a note to the created ticket (for example, an internal handoff note), use Create Halo Ticket Note as a follow-up step.

Step 5: Record the Message-ID for Reply-All Storm Catcher

After the ticket is created, MSPintegrations records the inbound email's Message-ID against the new Halo ticket ID on the selected Halo connection. Update Halo Ticket from Email uses this association to route later replies in the same thread to the correct ticket, even when those replies do not carry the Halo ticket tag in the subject or body.

Configuration

Connection

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

Email-Source Attribution

These fields identify the customer who originated the email and tell Halo the ticket was email-imported. Halo records the new ticket as "Logged from email <sender>" instead of attributing creation to the MSPintegrations API user authenticated by the connection.

Field	Description	Default
Email From Address	The sender's email address. MSPintegrations uses this single value as the canonical sender for the ticket: it queries Halo for the matching user and client, sends it as the new ticket's emailfrom, and populates user_email and reportedby. Supports text expressions.	{{email.from.address}}
Sender Name	The display name to use only if creating a new Halo user. Supports text expressions.	{{email.from.display}}
Add email sender to ticket recipients	When checked, the system adds the Email From Address to the ticket's recipient list, so future agent replies from the ticket go back to the person who sent the email.	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's recipient list.	Unchecked
Email Recipients to Evaluate	The list of email addresses the system checks against Halo for inclusion in the ticket'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, 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'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'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. 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 ticket's emailsubject. Leave empty to omit. Supports text expressions.	{{email.subject}}

Client and User Resolution

Field	Description	Default
Default Client	The catch-all client used when no existing user or client can be located in Halo. Leave empty to assign these tickets to Halo's built-in "Unknown" client and "Unknown" site (both ID 1). Select a different client here to route catch-all tickets to that client and its main site instead.	Empty (Unknown)
Create User If Not Found	When enabled, the action looks up a client by the sender's email domain and creates a new Halo user under that client (or the Default Client when no domain matches). When disabled, the ticket is assigned to the Default Client (or the Unknown client when the Default Client field is empty) without a user reference, and the domain lookup is skipped.	Disabled

Ticket Properties

Field	Description	Default
Summary	The ticket summary/title. Supports text expressions.	{{#if email.subject}}{{email.subject}}{{else}}New email from {{email.from.address}}{{/if}}
Details	The ticket description in plain text. MSPintegrations also generates an HTML version of this same content so the Halo UI displays the body with line breaks and paragraph spacing preserved. You do not need to supply HTML. Supports text expressions.	To: {{email.to.[0].address}} From: {{email.from.address}} Subject: {{email.subject}} {{email.body}}
Ticket Type	The type of ticket (for example, Incident, Service Request).
Status	The ticket status. If not provided, uses the default status for the ticket type.
Priority	The ticket priority level.
Category	The primary ticket category (level 1) for classification and reporting.
SLA	The Service Level Agreement to apply to this ticket.
Agent	The agent/technician to assign the ticket to.
Team	The team to assign the ticket to.
Impact	How widely the issue impacts the customer. Choose from a dropdown: Company Wide, Multiple Users Affected, or Single User Affected. Combined with Urgency, Halo may use this to compute the ticket's priority. Leave empty to skip setting this on the ticket.
Urgency	How quickly the customer needs the issue resolved. Choose from a dropdown: High, Medium, or Low. Combined with Impact, Halo may use this to compute the ticket's priority. Leave empty to skip setting this on the ticket.

Attachments

Field	Description	Default
Attach Email Attachments	When enabled, uploads all attachments from the incoming email to the new ticket.	Enabled
Attach Original Email .eml	When enabled, uploads the original email as a single .eml file to the new ticket.	Disabled

Workflow Control

Field	Description	Default
Action After Creating Ticket	What happens after the ticket is created successfully.	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. Access properties using dot syntax.

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

Variable	Type	Description
.ticket	object	The created Halo ticket (see properties below)
.user	object	The determined or newly-created Halo user (null if no user was determined and none was created)
.client	object	The determined Halo client (always populated)

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/contact ID
user_name	string	The user/contact 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's full name
emailaddress	string	The user's email address
client_id	number	The client ID the user belongs to

Client Properties

Property	Type	Description
id	number	The client ID
name	string	The client name
website	string	The client website/domain

FAQs

What fields are required?

You must provide a Halo Connection. Summary defaults to the email subject (or a fallback if the subject is blank), and Details defaults to a template containing the email's To, From, Subject, and body. All other fields are optional but recommended for accurate ticket routing.

How do I use dynamic values for ticket fields?

Every field that supports text expressions accepts {{variable}} syntax. For example, set Summary to [{{email.from.display}}] {{email.subject}} to prefix the subject with the sender's name.

Do I need to supply HTML for the ticket body?

No. Configure the Details 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 when no Halo user matches the email address?

If Create User If Not Found is disabled, the ticket is assigned to the configured Default Client (or Halo's "Unknown" client when the Default Client field is empty) with no user association (.user is null). The action skips the domain lookup in this case so that unmatched senders consistently land on the same triage client. Halo's auto-created "Opened" timeline entry uses the raw Email From Address as the author. If Create User If Not Found is enabled, the action first tries to match a client by the email's domain, then creates a new Halo user under the matched (or default) client and associates the ticket with that user.

What happens when no client is matched?

The action falls back to the configured Default Client. If the Default Client field is left empty, the ticket is assigned to Halo's built-in "Unknown" client (ID 1) and "Unknown" site (ID 1), which every Halo tenant ships with for exactly this triage purpose.

Does this action work with non-email data sources?

No. This action requires an inbound email. Use Create Halo Ticket and related single API call actions for non-email sources.

Does this action add a note to the ticket?

The action does not post any timeline entries itself. When the ticket is created, Halo's API automatically adds a customer-attributed "Opened" entry that carries the email body. This is the same behavior Halo's own inbound-email handler produces. If you need to add a separate note after the ticket is created, use Create Halo Ticket Note as a follow-up action.

Who does Halo show as the creator of the ticket?

The ticket is recorded as email-imported. Halo's audit trail shows "Logged from email <sender>" using the configured Email From Address, so the customer is credited with creating the ticket rather than the MSPintegrations API user authenticated by the connection. The "Opened" timeline entry Halo creates automatically is also attributed to the customer, so the entire conversation reads as the customer's activity rather than the API user's.

How does this action help Reply-All Storm Catcher?

After this action creates a ticket, MSPintegrations records the inbound email's Message-ID against the new Halo ticket ID on the selected Halo connection. Update Halo Ticket from Email consults that record when a later reply arrives without a ticket tag, using the reply's In-Reply-To and References headers to find the original ticket. Associations are scoped per Halo connection, so entries from one Halo instance are never applied to another.

Related Actions

• Find Halo User and Client by Email: The building-block action this workflow uses to determine the user and client
• Create Halo User: The building-block action this workflow uses when creating a new user
• Create Halo Ticket: The building-block action this workflow uses to create the ticket, and the action to use directly when you already know the user and client
• Attach Files to Halo Ticket: The building block action this workflow uses to attach email attachments
• Create Halo Ticket Note: Add a note to the created ticket if needed
• Update Halo Ticket from Email: Detect and update an existing ticket from an email, typically run before this action