Pharma email operations

Status: Current | Last reviewed: 2026-08-14

Pharma email operations combines AWS SES, Salesforce Email-to-Case, an async TrueServe workflow, durable Salesforce analysis records, and the record-backed Agent Assist rail. The implementation supports auto-response and human-review paths without requiring an active conversation.

End-to-end flow

sequenceDiagram
    participant Sender
    participant AWS as SES + email coordinator
    participant SF as Salesforce Email-to-Case
    participant WF as Email Operations workflow
    participant DB as Salesforce analysis records
    participant Rail as Agent Assist rail

    Sender->>AWS: multilingual email + attachments
    AWS->>AWS: claim idempotency lease and reject bounces
    AWS->>SF: forward MIME message
    SF-->>AWS: delivery id becomes EmailMessage.MessageIdentifier
    AWS->>WF: email.received + exact Salesforce id + S3 attachments
    WF->>SF: query EmailMessage with bounded retries
    WF->>SF: set MedTech record type and Working status
    WF->>WF: OCR attachments and apply multilingual policy
    WF->>DB: upsert analysis and item decisions
    alt Tier 1
        WF->>Sender: localized response through tenant email integration
        WF->>SF: create sent EmailMessage and close Case
    else Tier 2 or Tier 3
        WF->>SF: set Escalated and route Case for review
        Rail->>DB: load classification, evidence, decisions, and draft
        Rail->>SF: open host composer through external event
        SF->>WF: translate approved English response
        WF->>Sender: send customer-language reply
        SF->>DB: mark Sent and store delivery id
    end

Ingress and correlation

SES writes each raw message to the encrypted bucket. The coordinator owns both side effects: forwarding the message to Salesforce and publishing the workflow event. A DynamoDB ledger prevents either side effect from being repeated after a partial failure.

The forward uses SES SendRawEmail, so its delivery id is known before workflow publication. The event contains that id in the exact bracketed format stored by Salesforce. It also carries a normalized routing_address; medtech@trueserve.ai selects the dedicated MedTech Case record type without hard-coding a Salesforce record type id. The workflow retries its Salesforce query for the matching EmailMessage because Email-to-Case and workflow ingress are asynchronous. An empty join is an error, not a valid no-op.

The join also selects Parent.CaseNumber. Only that public Case Number is supplied to the response-generation prompt; ParentId and other Salesforce record identifiers are not. The customer-content contract prohibits Salesforce, EmailMessage, analysis, workflow, event, and storage identifiers in subjects or bodies. If the response needs a reference, it uses the Case Number with a localized label.

Transport-generated delivery reports and automatic replies are terminally recorded as suppressed before forwarding. This is required because outbound fixture mail to a non-deliverable address can otherwise return to the same intake alias and create a response loop.

Workflow policy

Email Operations - Multilingual Intake is seeded by 138_pharma_email_operations.sql. Its main stages are:

1. Join the inbound event to the Salesforce Case and EmailMessage.
2. Mark the joined Case Working. MedTech intake also selects the MedTech record type and clears healthcare-provider defaults that do not describe the request.
3. OCR each supported attachment using the tenant AWS integration. A nested attachment failure fails the parent For Each node.
4. Run one structured policy analysis over the body and OCR output. The schema separates the inbound English working translation, English reply draft, and sender-language localized draft.
5. Upsert one TrueServe_Email_Analysis__c by event id and one TrueServe_Email_Decision__c per item.
6. Update Case routing fields and branch by automation tier.
7. Send and close a Tier 1 Case, or move Tier 2/3 to Escalated for review. A Tier 1 delivery failure also moves to Escalated.

The migration may reuse the older Email Processing workflow identity. It therefore replaces version 0 with the same graph it publishes, rather than leaving the legacy draft attached to the new Email Operations versions. After an out-of-band draft replacement in a running environment, reset the workflow collaboration room so a cached Y.Doc cannot restore the old graph.

The workflow's demo policy is deterministic for the supplied D1, C1, and E1 fixtures. Unknown requests route to Tier 3. Production policy should replace the fixture block with governed ERP, contract, and order tools while preserving the output schema.

Durable Salesforce model

TrueServe_Email_Analysis__c is the one-per-inbound-event record. It holds correlation identifiers, classification, route, language, original and translated content, working and localized drafts, evidence, attachment metadata, automation state, and delivery outcome.

For each inbound attachment, the workflow also stores Attachment_Translations_JSON__c: filename, source and target languages, an English summary, and translated OCR text with identifiers, amounts, dates, and row order preserved. The original Salesforce Attachment or File remains the authoritative downloadable artifact. The translation is rendered as text in the communication timeline; the current implementation does not synthesize a second translated PDF.

TrueServe_Email_Decision__c stores item-level claimed/actual values, a descriptive verdict of up to 255 characters, citation, confidence, review state, and ordering. Its external decision key makes workflow retries safe.

Case denormalizes intent, region, automation tier, and email status for routing and list views. The dedicated MedTech record type uses TrueServe_MedTech_Process (New, Working, Escalated, and Closed) plus a compact layout containing only the Case number, subject, lifecycle, automation tier, detected language, and email intent. This prevents healthcare-provider defaults such as Complexity, Case Reason, and Case Flag from defining the MedTech journey. The TrueServe_Email_Operations permission set grants access to the custom model, Case fields, and MedTech record type.

MedTech Cases retain the inbound email subject. Both the Case-triggered subject automation and its shared subject-construction subflow exclude the MedTech record type, so workflow record-type changes and later Task updates cannot replace the customer subject with the generic Case-number/origin/reason format.

Agent Assist and approval

The Embecta Case page mounts the generic Agent Assist rail and the invisible trueServeEmailActions host adapter. TrueServe_Context_Email_Operations loads the latest durable analysis and returns props for four Email Copilot components:

Component	Data
Email overview	sender, intent, language, tier, route, status, and confidence in stacked, wrapping fields
Research	item-level claimed/actual/verdict/citation JSON under Integrated System Details tiles
Evidence	one expandable, full-width tile per attachment or matched business record
Reply recommendation	response policy, English draft, target language, recipient, and subject

The rail only reads Salesforce. It performs no model call during page load. The draft-response.open A2UI action is propagated as a generic external event. Before opening trueServeEmailComposer, the Salesforce host adapter reloads the recipient, subject, target language, response guidance, and AI draft from the durable analysis record. The action payload selects the analysis but is not the authoritative store for long draft content. This keeps the catalog and profile independent of Salesforce objects and host actions while ensuring that the modal opens with the stored draft.

The Communications component owns original and translated message display, so the rail does not duplicate a Latest communication card. The composer presents the stored draft in one editable Salesforce Response textarea and explains that delivery is translated automatically. The adapter rejects analyses without a draft instead of opening an empty composer. Selecting Translate & send calls TrueServeEmailService.queueApprovedReply, which stores the approved response, marks the analysis Translating and delivering, enqueues a callout-capable Queueable, and returns so the modal can close immediately. The invisible host adapter polls that durable status while the Reply recommendation renders background progress. The Queueable invokes workflow 25, published by 139_approved_email_translation.sql, to translate the response with the low-latency gpt-4o-mini model and deliver it through SES. Salesforce creates a sent EmailMessage only after both translation and delivery report success, and it rejects another delivery attempt while one is active or when the analysis already has Response_Sent_At__c. TextBody preserves the approved English response; the DCC translated subject/body fields contain the delivered localized content and Email Language is set to English. The analysis changes to Sent, the poller refreshes the Case, and hasUnansweredIncomingEmail=false removes the progress card. A failure changes the durable status to Send failed, retains the error, refreshes the retryable recommendation, and creates no false sent record.

Cases without a TrueServe_Email_Analysis__c continue through the legacy PagerDuty translation adapter.

Communication timeline

trueServeEmailTimeline replaces the standard Activity tab on the Embecta Case page with a communication-first SLDS timeline. It orders EmailMessages by MessageDate with CreatedDate as fallback, oldest to newest. Each expandable item shows:

• Received or Sent direction, participant, subject, and localized timestamp;
• original and translated message bodies side by side;
• the delivered customer-language body first for outbound messages, followed by the English working copy;
• original attachment download links;
• full stored attachment translations for new analyses, or the older OCR evidence summary as a compatibility fallback.

The most recent item opens by default. RefreshView and the component refresh action reload the cached Apex result after a response is sent. The Apex adapter supports both legacy Attachment records used by Email-to-Case and Salesforce Files linked through ContentDocumentLink.

Failure behavior

• Salesforce query, create, update, and upsert nodes support fail_on_empty and fail_on_error; critical steps enable them.
• For Each inspects nested node results and stops immediately when fail_on_error is enabled.
• The coordinator reuses an already-recorded Salesforce delivery id after an event-publication retry.
• Outbound EmailMessage and Salesforce Sent status are committed only after the tenant delivery workflow returns status=ok.
• The loading rail remains a stencil until both the profile catalogs and Salesforce snapshot settle, preventing white or empty flashes.

Demo assets and operations

Build and rehearse from demo/pharma-email. The implemented journey and verified Salesforce Case ids are recorded in the demo plan.

Before a live demo, confirm:

• the Salesforce integration user is active and unfrozen;
• the email trigger rule is active and points to the current published workflow;
• the API token and Email-to-Case target exist in SSM;
• the DynamoDB ledger and workflow event use the same inbound correlation id;
• the dead-letter queue is empty;
• the SES receipt rule accepts medtech@trueserve.ai;
• the embecta-support profile is published with the Email Copilot catalog.

See also

• Email coordinator
• Record-backed Agent Assist
• Salesforce Agent Assist profiles