Configure automatic replies and decision chat

Automatic replies select incoming mail with rules and create a response for the selected mailbox. The default delivery mode creates an editable draft. Automatic sending needs a separate setting and permission.

Start with first login and a connected mailbox. The login identity, actor, and mailbox are separate concepts. Microsoft processing needs Microsoft Graph setup. Google processing needs Google setup and its provider-specific runtime. Do not substitute Microsoft folder or notification assumptions for Google behavior.

Configure a reply

1. Open Settings → Automatic replies for the selected mailbox. Create a named definition with matching conditions and response content.
2. Choose fixed or writer response mode, then reply or replyAll addressing.
3. Put mutually exclusive definitions in a group. Choose its conflict policy and priorities.
4. Save the delivery mode and enable automatic replies.
5. Inspect cases in Sorting → Auto reply. Open a case conversation or its draft to review the result.

The shared SortingRuleConfig editor supports positive and negative lists, regex, meaning conditions, and advanced field relationships. One fixed response preserves its stored text. Writer follows its instruction. When multiple definitions apply together, writer combines their content into one response.

The priority group policy selects the highest numeric priority. The ask policy requests a decision when multiple candidates match. Ties at the highest priority also request a decision. Winners from separate groups and ungrouped matches can apply together.

Enabling applies to new arrivals. For older mail, use Run automatic replies in the email menu. Ordinary sorting does not send replies.

Writer and knowledge context

Writer uses the tenant writer model/profile and normal model grants, provider admission, budgets, and usage accounting. The parent supplies structured source email IDs, response targets, and allowed knowledge references. The server assembles provider context.

A definition can select libraries or folders. Retrieval needs both search permission and permission to use content in automatic outgoing email. Read access alone is insufficient. See knowledge libraries for ownership, access control, indexing, and citations.

Unavailable knowledge, a high scam score, or failed assessment requires an owner decision. Scam assessment remains independent of priority badge settings.

Decide by email or chat

For a conflict, the system records the question in a Complexity chat bound to actor, account, and tenant. It creates a separate self-addressed notification draft and uses the normal send scheduler. The direct chat link includes chatId and account. This needs a configured HTTPS application URL.

You can reply to the notification email. The subject's case ID is only a lookup hint. Ingestion also checks the owner mailbox sender and a random mailbox-bound correlation token in the body. Message IDs prevent duplicate decisions. In the Microsoft path, ordered mailbox commands move notification and accepted decision messages into the real Graph ecs-internal folder.

Decision extraction prefers Graph uniqueBody. Otherwise, ingestion accepts only unambiguous new text before an HTML or plain-text quote boundary. Missing, ambiguous, or quote-only input needs another question or a chat decision. Outlook, Gmail, and Yahoo quote containers do not become user instructions.

Email questions and answers appear in case history. The dedicated decision composer accepts plain text without a separate interactive chat model. It accepts neither attachments nor new artifact references. Explicit case metadata selects this path. Normal chat processing does not run a second inference for the same case decision.

The first chat decision permanently mutes further email notifications for the case and cancels notifications not yet dispatched. An already dispatched send remains under reconciliation and cannot be reliably recalled. Continue that case in chat.

Permissions and excluded messages

Action	Required permission
Read settings and cases	mail.automaticReplies.read
Manage definitions, groups, settings, and manual starts	mail.automaticReplies.manage
Send automatically	mail.automaticReplies.send plus explicit send delivery mode
Submit a chat decision	ai.search.complexity.chat and mail.automaticReplies.manage, plus appropriate chat read access
Use knowledge in a response	Feature permissions and current library search/automatic-email access

Automatic-reply management does not require a sorting grant merely because both features use the same rule editor. Agent tools add their own tool grants.

Ownership comes from authenticated backend context. Public case-decision accepts chat-origin decisions only. Authenticated ingestion supplies email-origin decisions. Draft, move, and send audit records use agent origin and the case chat ID.

Self-sent, automated/bulk, draft, sent, deleted, junk, and internal-folder messages do not start automatic replies. The backend checks provider headers and the current parent folder before matching. Custom folders need an owner-bound parent and complete system-folder identification. Incomplete provider identity blocks automatic processing. The reserved ecs-internal folder remains excluded even if an earlier manual case created it.

Duplicate protection and recovery

One durable case exists per mailbox and source email. A worker lease reserves work. The worker checks the signed admission receipt and current permissions. Matching/generation, canonical draft creation/save, and send scheduling use separate states.

Background generation has at most three attempts, including process loss. A successful stage transition resets that counter. The case retains canonical operation and schedule IDs. Waiting for provider confirmation does not create another draft or send.

If Graph draft creation started but no remote receipt exists, AUTOMATIC_REPLY_DRAFT_CREATE_UNCERTAIN requests review. The system does not blindly repeat createReply or createReplyAll. A draft revision hash protects human edits from silent replacement.

Errors and recovery

State or symptom	Action
needs-decision	Open the case chat, read the conflict or assessment error, and give a text decision.
draft-ready	Review the existing draft. This is an expected final state in draft mode.
sending or awaiting confirmation	Inspect the operation in Sync Center and provider synchronization. Delay alone is not a reason to resend.
Uncertain creation or changed draft	Find the existing provider draft and operation before another action.
failed	Use case/chat and operation errors to correct permission, provider, or configuration problems. Manual database edits are not recovery.

Normal Complexity Retry after process loss is separate from durable automatic-reply recovery.