DocsAutoResponderProcess

External connections#

This folder documents each external system the AutoResponder pipeline talks to: what it is for, how it is configured, reads vs writes, and how live, read-only, and dry-run modes differ.

Code entry points: orchestration and wiring live in src/auto_responder/main.py. Per-email work uses ContactLookup (lookups) and ActionEngine (determination-driven actions).

Pipeline order (typical run)#

  1. IngestEmail repository: SELECT from the central MSSQL emails table (connection string chooses server/database).
  2. ClassifyAutoResponseDetermination (LLM / rules; not a DB connection).
  3. Resolve contact — Cupola, Hodor, Multipub, Salesforce (ContactLookup), except in dry-run where lookup is skipped and a minimal stub contact is used.
  4. Act — Cupola, Hodor, Multipub, Salesforce, SFMC (ActionEngine), plus notifications and output CSV/JSON.

Active-only policy. Every automated write that changes a person's state is gated on an active CUPOLA row. No auto-add, no auto-reactivate, and email / title updates fall through to Human Review whenever the preferred CUPOLA row is missing or inactive. Determination.OUT_OF_OFFICE is a first-class outcome that never writes to any external system — see the per-connector pages below.

Connection documents#

DocumentSystemProtocol / style
email-repository.htmlCentral inbox storeMSSQL read-only (emails)
cupola.htmlOrg/person (IPv4 system of record)MSSQL
hodor.htmlProspect / order-side (dmorders_thompson area)MSSQL
multipub.htmlSubscription validationMSSQL (often via linked server / OPENQUERY)
salesforce.htmlSalesforce CRMREST (Contacts & Leads)
sfmc.htmlMarketing Cloud suppression listsREST (Data Extension upsert)
graph-outlook.htmlOptional Outlook via Microsoft GraphREST (not used by the default main.py path)
Tarun Multipub uploadTarun Multipub upload microserviceFastAPI POST /multipub/upload (separate auto-responder-tarun-upload process)

Operating modes#

ModeConfigurationEffect
LiveWRITE_OPERATIONS_ENABLED=true, MOCK_ALL_SERVICES_FOR_DEV=falseReal connectors; Cupola / Multipub / Salesforce may fall back to mocks if health checks fail. Hodor stays real but can be graceful-unavailable if SQL is not configured. SFMC uses a real client when credentials and health check succeed.
Simulation (no writes)WRITE_OPERATIONS_ENABLED=falseLive reads for Cupola, Multipub, Salesforce (if initialized), and Hodor when configured. Writes go through ReadOnlyDatabaseWrapper (logged, not executed) for those DBs. SFMC uses MockSFMCClient. Notifier runs with dry_run=True.
Dev mock-allMOCK_ALL_SERVICES_FOR_DEV=trueMock Cupola, Multipub, Salesforce, SFMC; real HodorDatabase class (graceful-unavailable if unset). Email repository is mock by default; set dry_run_use_real_email_repository=true to use the real repository. Contact lookup is skipped; a minimal stub Contact is used so the rest of the pipeline can run.
Hodor manualHODOR_AUTOMATIC_UPDATES=falseHodor reads still run when SQL is configured; writes are not executed. The action engine emails a compiled list of intended Hodor changes to NOTIFICATION_EMAIL_VENU (or NOTIFICATION_EMAIL_VENU if unset). See hodor.html. Independent of WRITE_OPERATIONS_ENABLED.

Annotation: Processing reports label connectors as mock or unavailable when applicable (see main.py and format_lookup_connector_labels).

Freshness: These pages are meant to track the code. Update them when main.py, connectors, or action_engine.py behavior changes.