Skip to main content

Email Preferences

Email Preferences let you control how ServiceOps processes incoming emails and creates tickets from them.

To view Email Preferences, navigate to Admin > Support Channel > Emails > Email Preference.

Email Preferences page showing Email to Ticket, Requester Identification, Sending, and Reply Behaviour sections

Email to Ticket​

This section controls whether incoming emails create tickets and which senders are allowed to trigger ticket creation.

SettingDefaultDescription
Enable Email to TicketOnAllow users to create a new request by sending an email. Any user (registered or unregistered) can send an email to generate a request. When enabled, the email subject becomes the Request Subject and the email body becomes the Request Description. For example, if you need to pause ticket creation during maintenance, turn this off. Emails sent during that time will not be picked up and remain on the mail server until polling resumes.
Allow Guest User to Generate RequestOnWhen enabled, guest users can create service requests by sending emails to a configured incoming email address. When disabled, emails from guest users will not create requests even if sent to a valid incoming email address. For example, if an end user emails support@company.com but their address is not registered in ServiceOps, their ticket is still created and they are added as a Guest User. When disabled, their email is silently ignored and no ticket is created.
Allow Ticket Creation when Incoming Server is in CCOnWhen enabled, tickets are created when the system's incoming email address is included in the CC field. For example, if a requester sends an email to their manager but CCs support@company.com, a ticket is created. When disabled, the email is ignored because the incoming email server address was not the primary recipient.
Allow Ticket Creation when Incoming Server is in BCCOnWhen enabled, tickets are created when the system's incoming email address is included in the BCC field. For example, if a requester sends an email to their vendor but BCCs support@company.com, a ticket is created silently. When disabled, the email is ignored.

Requester Identification​

This section controls how ServiceOps identifies the requester from incoming emails and handles CC recipients.

SettingDefaultDescription
Use Reply-To Address to Identify RequesterOnWhen enabled, ServiceOps uses the Reply-To header of the incoming email to identify the requester instead of the From address. Useful when automated systems send emails on behalf of a real user. For example, if a monitoring tool sends an alert from alerts@system.com but sets the Reply-To as john@company.com, John becomes the requester. When disabled, the From address (alerts@system.com) is used instead.
For Forwarded Emails, Consider Original Sender as RequesterOnWhen enabled, if a technician forwards an email to the system, the original sender is designated as the requester for the newly created ticket. For example, if a technician receives a complaint from client@abc.com in their personal inbox and forwards it to support@company.com, the original sender (client@abc.com) becomes the requester. When disabled, the technician becomes the requester.
Recipient Type Treated as CC on TicketsCC UserConfigure whether To and CC email recipients are automatically included in the Cc Emails field of the Request Details Other Info section upon ticket creation. For example, if To User is selected and a requester emails the servicedesk address along with a colleague in the To field, that colleague's email is added as CC on the ticket.
CC Recipient Handling

If To User and CC User are both selected, and a ticket is created with jerry@motadata.com in the To field and john@motadata.com, james@motadata.com in CC, all three addresses are added to the Cc Emails field. The email address configured as an Incoming Email Server is never included in the Cc Emails field.

Incident details page showing the Cc Emails field in Other Info with three recipient addresses populated from the email

Sending​

This section controls which outgoing email server technicians can use when sending notifications from a ticket.

SettingDefaultDescription
Allow Technician to Select Outgoing ServerOnWhen enabled, technicians can select the desired outgoing email server when sending emails from a ticket. The Outgoing Email field appears in the Notification and Work Conversations tab of the Incident and Service Request Details page. For example, a technician handling a ticket can choose a department-specific outgoing server from a dropdown instead of using the default server.

Reply Behaviour​

This section controls how ServiceOps handles email replies to closed tickets and replies from non-assigned technicians.

SettingDefaultDescription
Reply Behaviour on a Closed TicketAdd reply to requestSelect how ServiceOps handles a requester's reply to a closed ticket:

Add reply to request: Appends the reply to the closed ticket without reopening it.

Reopen request and add reply to request: Reopens the ticket if the reply arrives within the configured grace period. When this option is selected, a Grace Period field appears: enter the number of days within which a reply will reopen the ticket. After the grace period expires, a new request is created instead.

Create new request: Always creates a new ticket regardless of when the reply is received.

For example, if a ticket was closed and the requester replies within 3 days saying the issue is not resolved, and the grace period is set to 3 days, ServiceOps reopens the ticket with their message attached. A reply after day 3 creates a new ticket.
When a Non-Assigned Technician Replies via EmailAdd reply mail as collaborationSelect how ServiceOps handles an email reply from a technician who is not assigned to the ticket:

Add reply mail as collaboration: Adds the reply as a collaboration note visible only to the team, not the requester.

Add reply mail as reply: Adds the reply as a direct reply visible to the requester.

For example, if another technician replies to the ticket email thread, selecting Add reply mail as collaboration keeps their message internal and hidden from the requester.
Duplicate Detection

When the same email is scanned repeatedly (via IMAP in Gmail or Outlook), the system detects previously created tickets using the message ID and ignores duplicates.

Guest Requester Setting

For guest users to successfully create requests via email, the Allow Guest Requester to report a Request option must also be enabled in Support Portal Settings.

Use Cases​

Use Case: Route Emails to a Specific Request Type​

Scenario: Emails sent to a dedicated IT Support mailbox should automatically create a Laptop Service Request and route it to the correct team.

Prerequisites:

  • Enable Email to Ticket and Allow Guest User to Generate Request must be enabled in Admin > Support Channel > Emails > Email Preference.

Email Preferences page showing Enable Email to Ticket and Allow Guest User toggles switched on

For the complete configuration of the incoming email server, incoming email rule, and optional workflow, see Incoming Email Rules.

Use Case: Auto-Assign Incidents Created via Email​

Scenario: When an end-user sends an email to create a new incident, ServiceOps should automatically assign it to a technician using round-robin auto-assignment.

Prerequisites:

  • Enable Email to Ticket and Allow Guest User to Generate Request must be enabled in Admin > Support Channel > Emails > Email Preference.
  • A dedicated incoming email server must be configured in ServiceOps.
  • A technician group with round-robin auto-assignment configured must be available.

Configuration Steps:

  1. Enable Email to Ticket: Navigate to Admin > Support Channel > Emails > Email Preference and switch on Enable Email to Ticket and Allow Guest User to Generate Request.

  2. Configure an Incoming Email Server: Navigate to Admin > Support Channel > Emails > Incoming Email Servers and configure an incoming email server (for example, it.incident@example.com) with Technician Group set to Network Team. Ensure the server is enabled.

  3. Configure a Workflow for Auto-Assignment: Navigate to Admin > Automation > Workflows and create a new workflow with the following settings:

    • Name: Auto Assign Incident Via Email
    • Module: Request
    • Workflow Type: Event
    • Trigger: Incident is created
    • If Else Condition: Source In Email
    • Action: Set Auto Assignment Round Robin

    Edit Workflow page for Auto Assign Incident Via Email showing Trigger set to Incident is created, If Else condition checking Source In Email, and Set Auto Assignment action

Outcome: When a user sends an email to the configured incoming address, a new incident is created and automatically assigned to an available technician via round-robin. The Audit Trail confirms the auto-assignment and the Source field in Other Info shows Email.

INC-180 Internet is not Working incident showing Assignee Jerry, Technician Group Network Team, Source Email highlighted, and Audit Trail entry confirming auto-assignment via workflow

Troubleshooting​

Common issues when configuring email preferences.

Emails are received but no tickets are created

Cause: One or more prerequisite settings are disabled or an ignore rule is filtering out the sender.

Fix:

  1. Confirm Enable Email to Ticket is switched on in Admin > Support Channel > Emails > Email Preference.
  2. If the sender is a guest user, confirm Allow Guest User to Generate Request is also enabled, and that Allow Guest Requester to report a Request is enabled in Support Portal Settings.
  3. Check the incoming email server's filter configuration. An Ignore rule may be silently discarding the sender's emails.
  4. Review the Email Audit log at Admin > Organization > Security > Operation Audit for rejection details.
CC recipients are not appearing on the ticket

Cause: The Recipient Type Treated as CC on Tickets setting does not include the relevant recipient type, or the incoming email address is being excluded.

Fix:

  1. Confirm the Recipient Type Treated as CC on Tickets dropdown includes the appropriate type (To User, CC User, or both).
  2. The email address configured as an Incoming Email Server is always excluded from Cc Emails. This is expected behaviour.
  3. Verify the recipients are registered users or that guest user ticket creation is enabled.
Replies to closed tickets are creating duplicate tickets unexpectedly

Cause: Reply Behaviour on a Closed Ticket is set to Create new request, so every reply generates a new ticket.

Fix:

  1. Navigate to Admin > Support Channel > Emails > Email Preference.
  2. Set Reply Behaviour on a Closed Ticket to Reopen request and add reply to request or Add reply to request, depending on whether you want the ticket reopened.
  3. Click Update to save.