Email Integration Guide

This guide explains how RebelPSA’s email integration works — the pipeline that turns inbound customer emails into Help Desk tickets, and sends technician replies back out through a connected mailbox. It covers connecting a mailbox, routing rules, how a ticket gets created from an email, and how to read the diagnostics tools when something needs troubleshooting.

At a high level, every connected mailbox flows through the same pipeline, regardless of which email provider is behind it:

• A customer sends an email to a connected support address or replies to an existing ticket thread.
• RebelPSA is notified of the new message — either immediately via a push notification from the mail provider, or by checking the mailbox on a short interval, whichever applies (see Delivery Health: Webhooks vs. Polling).
• The message is matched to an existing ticket (if it’s a reply) or used to create a brand-new ticket (see How Emails Become Tickets).
• The message — and any attachments — is recorded on the ticket’s comment/activity thread with a clear “Email Received” marker.
• Once processed successfully, the message is marked so it won’t be picked up and processed again. It may be moved to a Processed folder, or labeled, depending on the provider.

Outbound replies work in reverse: a technician’s reply is sent through the connected mailbox, recorded on the ticket with an “Email Sent” marker, and threaded so the customer’s reply comes straight back to the same ticket.

Microsoft 365 is the most mature and fully-featured integration. Google Workspace has reached feature parity for the core pipeline (inbound, outbound, routing, diagnostics) and is in final verification. Generic IMAP is supported for mailboxes that don’t fit either of the above.

All mailbox connections start from the same place: the Integrations admin area’s mailbox list, using the Add Mailbox picker to choose a provider. Each provider then opens its own guided setup wizard. This section walks through what each wizard asks for.

Microsoft 365

Connecting a Microsoft 365 mailbox uses an admin-consent, app-based connection — no individual mailbox password is ever stored. In general, the setup flow will ask you to:

• Confirm you have Microsoft 365 admin rights to grant consent for the connection.
• Grant admin consent for RebelPSA to access mail on the mailbox(es) you intend to connect.
• Choose which mailbox address(es) to connect — RebelPSA supports connecting more than one mailbox under a single integration.
• Configure each mailbox: a friendly display name, whether new email should automatically create tickets, and which Service Board new tickets should land on by default.
• Activate the connection. RebelPSA immediately attempts to establish a live push subscription for near-real-time delivery.

Google Workspace

Google Workspace connects using a service account with domain-wide delegation, granted from the Google Workspace Admin Console — this allows RebelPSA to work with shared support addresses (e.g. support@yourcompany.com) without an individual person’s OAuth consent. The setup wizard walks through six steps:

Generic IMAP

For mail systems outside Microsoft 365 and Google Workspace, a generic IMAP connection is available. IMAP connections rely on polling only — there is no push-notification option — so new emails typically appear a little slower than with the two supported providers above.

The mailbox list page shows every connected mailbox across every provider in one place, with its connection status, provider, and delivery method. From here you can:

• Add another mailbox to an existing integration, or start a brand-new one
• Edit a mailbox’s display name, default Service Board, or auto-create-ticket setting
• Enable or disable a specific mailbox without removing the whole connection
• Open that mailbox’s routing rules (Routing Rules: Getting Email to the Right Board) or diagnostics (The Diagnostics & Email Processing Log Pages)

Every ticket needs a Service Board, and routing rules are how a mailbox decides which board an incoming email should land on. Routing rules are configured per mailbox — each mailbox has its own independent set of rules, and rules never carry over from one mailbox to another.

A routing rule typically evaluates conditions such as the sender’s address, subject keywords, or the receiving mailbox itself, and then assigns:

• A target Service Board (required) — where the ticket will live
• A Queue (optional) — an additional focus lens layered on top of the board assignment (see the Help Desk Technician User Guide, Managing Connected Mailboxes, for how queues work)

If no routing rule matches, the mailbox’s configured default Service Board is used. If neither a rule nor a default resolves, ticket creation fails outright rather than silently landing somewhere no one can see — this is intentional, since a ticket with no board is invisible to everyone.

Matching a reply to an existing ticket

Every outbound email — whether an automatic acknowledgement or a technician’s reply — embeds a hidden reference back to its ticket. When a customer replies, RebelPSA recognizes that reference and adds the reply straight to the correct ticket’s activity thread rather than creating a duplicate.

Creating a new ticket from a first-time email

When an email doesn’t match an existing ticket, RebelPSA creates a new one and works out who it belongs to using a four-step resolution chain:

• Match the sender’s email domain to a known company
• Match the sender’s specific email address to an existing contact record
• Match the domain to a customer site
• Fall back to a tenant-wide default

If none of these steps produce a match, the ticket is filed under a system “Unassigned” company placeholder rather than being lost — your organization can review and reassign these to the correct customer. (This fallback behavior is itself a configurable tenant setting.)

Attachments & the original message

• Attachments on an inbound email are automatically pulled into the ticket.
• The original message is retained for a period of time, as part of the ticket record. This is useful if you ever need to check exactly what a customer sent, formatting and all.

Every mailbox can be set as the default sending mailbox for a given Service Board, so replies on that board’s tickets go out from the right address automatically. A technician can override the sending mailbox on an individual reply if needed.

The mailbox resolution order for an outbound reply is:

• The mailbox explicitly chosen in the reply composer, if any
• The Service Board’s configured default sending mailbox
• A platform fallback sender, only used if neither of the above is available

Two safeguards keep the pipeline from creating noise or looping with automated senders:

• Spam detection — messages identified as spam are rejected rather than turned into tickets and are still marked processed so they aren’t retried.
• No-auto-response list — senders on this list (typically automated “no-reply” or notification addresses) have their automatic acknowledgement emails suppressed, so RebelPSA doesn’t reply to a robot. The inbound message can still be processed normally; only the automatic reply is held back.

Both outcomes are visible on a per-message basis in the Email Processing Log (The Diagnostics & Email Processing Log Pages), so you can always see why a particular message didn’t turn into a normal ticket or didn’t receive an acknowledgement.

Microsoft 365 and Google Workspace mailboxes both use a push-notification subscription as their primary delivery method, which typically delivers new mail to RebelPSA within seconds. Polling runs underneath as a safety net in case a push notification is ever missed or a subscription temporarily lapses — a mailbox with a healthy, active subscription is polled far less frequently than one without.

Generic IMAP mailboxes have no push option and rely on polling for all delivery.

Mailbox Diagnostics

The diagnostics page shows the live health of every connected mailbox, including a status chip for its push subscription:

A Re-subscribe action is available per mailbox to force a fresh push subscription without waiting for the automatic renewal cycle. You can also filter the log by delivery method (All / Poll / Push) to see exactly how messages have been arriving.

Sender Diagnostics

A dedicated view for troubleshooting outbound send problems, showing the technical details behind each outbound attempt — the provider’s response, whether the sending address matched what was expected, and delivery status — useful when a customer reports “I never got your reply.”

Email Processing Log

Every inbound message that passes through the pipeline is logged whether or not it resulted in a ticket. The log includes:

• Filters by sender address, date range, and delivery method
• Attempt count, processing duration, delivery method, and attachment count columns
• A detail view per message showing its full attempt history — useful when a message seems to have been retried or stuck
• A daily success-rate panel that turns red if the success rate drops below 95%
• An export option for pulling a filtered set of log rows to a spreadsheet for deeper review