Email troubleshooting

Channel statuses

Status	Meaning
Connecting	Just enabled; monitoring is starting
Connected	Active — the last connection or renewal succeeded
Disconnected	Normal right after creating a Microsoft/Gmail channel, before consent
Authentication error	The provider rejected the credentials — expired/revoked token, wrong password, missing permission
Error	A non-authentication failure — network, provider outage, bad configuration
Disabled	Turned off; nothing is processed

The channel card’s Last error text shows the provider’s exact message — read it first; it diagnoses most issues on its own.

“Account connected, but activation failed”

Consent succeeded but starting the subscription failed right after. Usually permissions (the granted scopes do not actually include Mail.Read/offline_access, or the Gmail API is not enabled on the project) or shared-mailbox access (the signed-in account has no delegated access to the address entered). Fix the permission, then Test connection or reconnect.

“Authentication error” after working fine

• Microsoft — consent revoked in Entra, client secret expired, or the account’s password/MFA state invalidated the token. Reconnect via Connect my Microsoft account.
• Gmail — consent revoked, or the OAuth client deleted/disabled. Reconnect via Connect my Google account.
• IMAP — the password changed or an app password was revoked. Update the channel’s configuration.

A reply isn’t attaching to the right ticket

ServiceOps resolves a reply in this order — never by subject text alone as the primary mechanism:

1. The In-Reply-To header, matched against every email ServiceOps sent or received for your organization.
2. Each entry of the References header, same lookup.
3. ServiceOps’ own ticket marker header, always validated against a real ticket of the same organization.
4. A ticket code in the subject — [INC-000123] — validated against the workspace.
5. Last resort, for senders that emit no threading headers at all (monitoring tools): the normalized subject matched against a still-open ticket’s title, only when sender and mailbox also match. A resolved ticket recurring deliberately starts a new conversation.

If a reply became a new ticket instead: either the subject was edited and the message IDs were stripped by a relay (defeating 1–4), or the previous ticket was already resolved/closed (rule 5 treats that as new, on purpose).

Duplicate tickets or comments

Should never happen: every inbound message is recorded against a unique per-channel message ID before processing, so redelivered notifications and retried jobs are skipped. A genuine duplicate means the provider assigned two IDs to one physical email — report it with the two ticket numbers.

Email loops

ServiceOps tags every email it sends and records it as its own. An inbound message carrying that tag — or recognized as one of its own sent messages (some mailboxes copy sent mail back into the inbox) — is ignored, not turned into a ticket.

Attachments missing from a ticket

Files over 25 MB and executable types (.exe, .bat, .js, .jar, .ps1, .vbs…) are skipped deliberately; the email itself is still processed. The skipped file is noted, the rest of the message arrives normally.