PSA/ee/docs/plans/2026-03-31-inbound-email-reopen-on-reply/PRD.md

PRD — Inbound Email Reopen On Reply

• Slug: inbound-email-reopen-on-reply
• Date: 2026-03-31
• Status: Draft

Summary

Add per-board inbound-email reopen policies for replies against closed tickets. Match ConnectWise-style behavior by allowing boards to opt into reopen-on-reply, configure a cutoff window, and choose a reopen status. Add optional Enterprise Edition AI suppression for short client acknowledgements when the tenant has the AI Assistant add-on.

Problem

Inbound email threading already finds existing tickets and appends comments, but replies against closed tickets do not have a clear lifecycle policy. This creates ambiguity for technicians and customers, especially when a legitimate follow-up should resume work but a trivial "thanks" should not reopen a finished ticket.

Goals

• Reopen closed tickets automatically for valid inbound replies using board-scoped policy.
• Support a configurable cutoff window so old replies create a new ticket instead of reviving stale work.
• Let boards configure an explicit reopen status while falling back to the board's default open status.
• Always reopen for internal-user email replies.
• Optionally suppress reopen for short client acknowledgements using the standard LLM path when EE + AI Assistant are available.
• Keep inbound processing resilient and non-blocking when AI or configuration is unavailable.

Non-goals

• Building a general-purpose AI classifier infrastructure.
• Restoring the exact historical pre-closure status.
• Making reopen policy provider-scoped or tenant-wide.
• Adding new workflow automation surfaces for this v1.
• Building advanced analytics or reporting for reopen decisions.

Users and Primary Flows

• MSP technicians:
  • Need closed tickets to reopen automatically when internal discussion or new customer work resumes.
  • Need stale replies to become new work instead of mutating old tickets.
• MSP admins:
  • Need board-specific control over reopen policy, cutoff, reopen status, and AI suppression opt-out.
• Client contacts:
  • Their substantive replies should reopen active work.
  • Their simple acknowledgements should optionally remain attached without reopening when the board enables AI suppression.

Primary flows:

1. Internal user replies by email to a closed ticket within cutoff -> ticket reopens -> reply comment is added.
2. Client replies by email to a closed ticket within cutoff -> ticket reopens unless AI suppression classifies the reply as a simple acknowledgement.
3. Any threaded reply to a closed ticket after cutoff -> old ticket remains closed -> inbound flow creates a new ticket.

UX / UI Notes

• Add reopen policy controls to board settings because ticket statuses are board-owned.
• Expose AI acknowledgement suppression as a visible board option so admins know the feature exists and can opt out.
• Reopen status picker should use board-owned ticket statuses.
• If AI suppression is unavailable because the tenant lacks AI Assistant, the setting should either be disabled with explanatory copy or treated as inactive at runtime.

Requirements

Functional Requirements

• Board settings must persist reopen-on-inbound-reply configuration:
  • enable/disable
  • cutoff duration
  • optional reopen status
  • AI acknowledgement suppression enable/disable
• When inbound threading matches an existing closed ticket:
  • if reopen is disabled, attach the comment without reopening
  • if reply age exceeds cutoff, route into new-ticket creation instead of attaching to the closed ticket
  • if sender is internal, reopen
  • if sender is client/contact, reopen unless AI suppression is enabled and returns ACK
• Reopen must update status_id, is_closed, closed_at, and closed_by consistently with existing ticket status transition semantics.
• If no explicit reopen status is configured, fallback must use the board's default open status.
• Existing dedupe and token-only self-notification guards must remain intact.
• The AI acknowledgement decision path must be isolated behind a shared interface with an EE implementation injected in EE mode.
• The EE implementation must only call AI when:
  • board AI suppression is enabled
  • tenant has AI Assistant
  • reply is short and plausibly acknowledgement-like
• AI prompt/output must be minimal and return a tiny formatted response such as ACK or NOT_ACK.

Non-functional Requirements

• Inbound email processing must not fail closed because of missing AI entitlement, missing EE code, invalid AI output, or AI runtime errors.
• Fallback behavior for AI failures is reopen normally.
• Logging or stored metadata must be sufficient to explain reopen decisions during debugging.

Data / API / Integrations

• Add board-scoped configuration fields for reopen policy and AI suppression.
• Reuse existing board-owned status selection and TicketModel.getDefaultStatusId(...).
• Reuse existing inbound threading flow in shared/services/email/processInboundEmailInApp.ts.
• Reuse existing AI provider resolution pattern in EE code via @ee/....
• AI suppression uses the existing AI Assistant add-on entitlement (ai_assistant).

Security / Permissions

• Board reopen policy editing follows existing board-settings permissions.
• AI suppression execution must require the tenant AI Assistant add-on before any LLM call.
• CE environments must not import or require EE AI code paths at runtime.

Observability

• Log or persist decision metadata for:
  • reopen enabled/disabled
  • cutoff exceeded
  • reopen target source (explicit status vs board default)
  • AI suppression attempted / skipped / failed
  • AI result (ACK / NOT_ACK)

Rollout / Migration

• Default existing boards to reopen disabled so behavior does not change silently.
• New board settings become active only when configured by admins.
• AI suppression is dormant unless both board config and add-on entitlement are present.

Open Questions

• None blocking design. Future optimization work may replace the standard LLM call with a narrower classifier or heuristic layer once production examples are available.

Acceptance Criteria (Definition of Done)

• Boards can configure reopen-on-inbound-reply behavior, cutoff window, optional reopen status, and AI suppression.
• Closed-ticket inbound replies follow the configured policy for internal and client senders.
• Replies beyond cutoff create new tickets instead of reopening stale ones.
• AI suppression only runs in EE with AI Assistant entitlement and falls back safely on any failure.
• Behavioral integration coverage proves reopen, no-reopen, cutoff, and fallback outcomes.