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 determines the correct Halo user and client from the sender's email address, optionally creates a new Halo user when no match is found, creates the ticket, and optionally attaches the email's files.

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 note, 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

Email Address Flexibility

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

• The email's From header (the default)
• The email's To or Reply-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.

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 runs the same logic as Find Halo User and Client by Email:

1. Search Halo for a user whose email address matches the configured value and fetch that user's client.
2. If no user matches, search for a client by the email's domain.
3. If no domain match exists, use the configured catch-all default client.

This guarantees a client is always determined.

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 address. This is equivalent to running Create Halo User as a follow-up step.

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). This is equivalent to running Create Halo Ticket with those IDs.

The ticket description defaults to the email body, so the email contents become the ticket description by default. You do not need to add a note: the email content is already in 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 Address Resolution

Field	Description	Default
Email Address	The email address MSPintegrations will use to query Halo to determine a matching user and client. This does not have to be the From address: you can use the To address, a Reply-To, or a value extracted from the email body for web forms and automated messages. 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}}
Default Client	The catch-all client used when no existing user or client can be located in Halo. Lock to choose from a dropdown, or unlock to enter a dynamic value.	Unknown (ID 1)
Create User If Not Found	When enabled, creates a new Halo user under the determined client if no user matches the email address.	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/details. Supports text expressions. Includes email metadata and body by default.	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	The ticket impact level. Choose from a dropdown: 1 (High), 2 (Medium), 3 (Low), or 4 (Very Low). Required by some Halo instances.
Urgency	The ticket urgency level. Choose from a dropdown: 1 (High), 2 (Medium), 3 (Low), or 4 (Very Low). Required by some Halo instances.

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.

What happens when no Halo user matches the email address?

If Create User If Not Found is disabled, the ticket is created with the determined client but without a user association (.user is null). If Create User If Not Found is enabled, the action creates a new Halo user under the determined client and associates the ticket with that user.

What happens when no client is matched?

The action falls back to the configured Default Client so that .client is always populated.

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?

No. The email contents become the ticket description by default. If you need to add a separate note after the ticket is created, use Create Halo Ticket Note as a follow-up action.

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