Section — TSA Incoming Email

Section — TSA Incoming Email

What this section captures

The TSA Incoming Email section configures the email-to-ticket parser — the piece of the ITSM tool that watches a shared mailbox (e.g. helpdesk@example.com) and creates a ticket from each new message.

Settings captured here include:

• The mailbox(es) the parser watches.

• The connection protocol (IMAP / POP3 / Microsoft Graph).

• How to extract the sender, subject, and body into ticket fields.

• What category and workflow to assign by default.

• What rule patterns auto-classify the ticket (e.g. subject starts with [VPN] → route to Network group).

Why it matters

Email is still the most common way customers raise tickets. A misconfigured parser either loses emails entirely or creates duplicates — both are painful to diagnose after go-live.

How to fill it in

1. For each watched mailbox, capture the protocol, host, port, and the credential type (basic auth, OAuth, app password).

2. Set the default Category / Type / Item, Group and Workflow for emails that don’t match any rule pattern.

3. Add rule patterns for any subject-line conventions the customer uses (e.g. “Subject starts with [Outage] → Incident / Infrastructure / Critical”).

Approval implications

This section follows the standard four-state approval lifecycle: Draft (editable) → Submitted (locked, awaiting the customer’s Manager) → Manager Approved (locked, awaiting the Partner approver) → Final (fully signed off and locked). A reviewer can reject the section back to Draft, with a reason, at either approval step.

Once Final, the parser configuration is locked. Adding a new rule pattern after go-live requires a reject-back-to-Draft — consider grouping rule pattern changes into batches to avoid churn.