Open Mercato Customer Communications: Messages, Email, and Shared Inbox Boundaries

Evidence and vocabulary

Keep source state, project control and external provider responsibility separate.

• 1. released
• 2. reviewed current develop
• 3. implementation-dependent
• 4. provider or external control
• 5. not established
• 6. documentation drift

Define identity, owner, lifecycle and evidence. Similar words do not establish the same domain.

• 1. message
• 2. conversation
• 3. email
• 4. CRM interaction
• 5. Inbox Ops proposal
• 6. notification
• 7. ticket or case
• 8. campaign
• 9. observed business outcome

Four communication layers

Record fit, authority, privacy, hand-off, failure, reconciliation and stop conditions.

• 1. Internal Messages
• 2. Personal connected mailbox
• 3. Tenant-shared Inbox Ops intake
• 4. Custom or specialist authority

Messages capability and actor state

Participant and actor state supports collaboration. It does not show customer delivery or service-case status.

• 1. sender
• 2. To, Cc and Bcc recipients
• 3. subject and body
• 4. text or Markdown format
• 5. priority
• 6. draft and sent
• 7. thread and parent
• 8. recipient read state
• 9. recipient archive state
• 10. recipient delete state
• 11. source entity
• 12. objects
• 13. file attachments
• 14. actions
• 15. confirmations
• 16. email access tokens
• 17. search projection
• 18. email worker
• 19. events
• 20. notifications

Reviewed provider inventory. A provider outside this list has no reviewed adapter.

Both reviewed email profiles set fileSharing: false, readReceipts: false and deliveryReceipts: false. Gmail and IMAP report a best-effort sent placeholder. It does not prove that a person received, read or acted.

Personal mailbox privacy and lifecycle

A personal Gmail or IMAP channel is strict owner-only. In reviewed v1, an admin or superadmin cannot act on another owner channel. The communication_channels.admin feature is reserved and creates no cross-user override. Participant-gated enrichment also withholds channel payload from same-scope nonparticipants. Assignment is a scoped advisory pointer. It provides no mailbox access, queue membership, workload balancing, supervisor oversight or SLA.

Assign owner, allowed and denied actor, retained data, recovery evidence and exit step.

• 1. connect
• 2. owner-only view and manage
• 3. choose primary
• 4. share one CRM email
• 5. assign a linked conversation
• 6. cover absence or leave
• 7. reconnect after error
• 8. disconnect
• 9. clear credentials
• 10. retain or export synchronized history
• 11. offboard user
• 12. transfer ownership not established

CRM email remains private to its mailbox owner by default and may be shared per email; the reviewed release has no admin override. The CRM guide owns that wider record and timeline decision.

Timing is measured end to end

Measure configured delay, queueing, processing and visible arrival under normal and failure conditions.

1. 1

   provider event

2. 2

   webhook or 60-second scheduler tick

3. 3

   provider fetch or history cursor

4. 4

   queue and ingestion

5. 5

   Messages persistence

6. 6

   CRM or other enrichment

7. 7

   UI cache and notification

8. 8

   measured end-to-end arrival

Reviewed source uses 300 seconds for polling-only channels, a 60-second scheduler tick and a recommended 1,800-second Gmail push fallback. Other docs mention 60 seconds or 5 to 15 seconds. The documented values conflict and provide no service guarantee. Gmail watches must be renewed at least every seven days and push can be delayed or dropped, so cursor recovery and polling fallback remain necessary.

Thread matching and history

Record confidence, duplicate behavior, correction path and reconciliation owner.

• 1. provider conversation id
• 2. HMAC thread token
• 3. RFC message headers
• 4. subject and participant fallback
• 5. new thread
• 6. duplicate
• 7. orphan
• 8. wrongly joined or split
• 9. forwarded, stripped-header or cross-mailbox correction

New IMAP connections bootstrap at the current UID without historical import. An optional idempotent import is bounded to 1 through 365 days and 5,000 messages with concurrency control. Reviewed support covers IMAP only; Gmail support is absent. Reconnect, dead letter, already-synchronized history and cursor recovery are separate states.

Communication state model

Do not promote a technical intermediate state into customer delivery or business correctness.

• 1. message row state
• 2. recipient-specific state
• 3. channel connection state
• 4. provider acknowledgement state
• 5. thread-match confidence
• 6. proposal and action state
• 7. observed business outcome

Gmail and IMAP deployment controls

Gmail requires project OAuth configuration, user consent, refresh-token operations and optional Pub/Sub watch. The current gmail.modify scope is classified by Google as restricted; verification and a security assessment can apply when restricted data is stored or transmitted. Determine with Google which obligations apply to the exact deployment, including verification or a security assessment.

IMAP/SMTP performs live validation, encrypted credential storage, TLS choices and host/DNS pinning against internal-address SSRF. Insecure transport is disabled unless explicitly allowed; an internal-host escape hatch is an operator risk decision. It polls INBOX, sends through SMTP, has no provider push and currently fails outbound attachment attempts.

Google Gmail scope classification · Google watch and push limits

Inbox Ops proposal pipeline

• rfq
• order
• order_update
• complaint
• shipping_update
• inquiry
• payment
• other

• create_order
• create_quote
• update_order
• update_shipment
• create_contact
• create_product
• link_contact
• log_activity
• draft_reply

A scoped address receives provider-delivered or forwarded email, verifies the inbound path, parses a thread and asks a configured model for categories, participants, discrepancies, actions and draft replies. Authorized people edit, accept or reject proposals. Each accepted action still needs its domain permission and command validation. AI confidence supplies no permission or evidence of execution success or business correctness. Accept-all runs sequentially and stops on failure, so partial state must be reconciled.

Separate current code, project choice, provider control, evidence, failure and owner.

• 1. intake
• 2. authentication
• 3. tenant resolution
• 4. five-minute replay defense
• 5. 2 MB request-body limit
• 6. global and tenant rate limit
• 7. message-id or content-hash deduplication
• 8. protected body access
• 9. model and provider
• 10. prompt and data boundary
• 11. proposal permission
• 12. domain action permission
• 13. edit and concurrency
• 14. atomic send claim
• 15. Resend delivery provider
• 16. audit and events
• 17. retention
• 18. deletion
• 19. recovery and owner

A valid email to a known address supplies content input. It does not prove sender authorization. The route also needs address-abuse, spam, malicious content, prompt injection, model-data, attachment, cost and incident controls. Log-only readers receive a stable redacted shape unless they also have proposal-view access. Translation is a model-costing persistent mutation behind proposal-manage. Reply sending is separately permissioned, requires an accepted draft, uses an atomic claim and Resend, and records success where available. It does not prove delivery, bounce handling or suppression.

Helpdesk, contact-center and marketing boundary

A named project module or external authority must supply and accept this capability. Reviewed communication evidence alone does not prove it.

• 1. ticket or case identity
• 2. requester and organization model
• 3. team queues
• 4. assignment policy
• 5. agent presence
• 6. collision detection
• 7. ownership transfer
• 8. business hours
• 9. SLA clocks
• 10. escalations
• 11. priority policy
• 12. canned replies
• 13. templates
• 14. knowledge base
• 15. customer portal
• 16. CSAT
• 17. voice and telephony
• 18. recording
• 19. SMS
• 20. social messaging
• 21. chatbot
• 22. campaign audience
• 23. segmentation
• 24. marketing consent
• 25. unsubscribe and suppression
• 26. bounce and complaint handling
• 27. deliverability monitoring
• 28. workforce reporting

Decision tree, flow and responsibilities

1. 1

   Name the business outcome and authoritative record

2. 2

   Choose personal, shared operational or service-team ownership

3. 3

   Select the smallest layer that preserves that ownership

4. 4

   Define privacy, provider, failure and reconciliation controls

5. 5

   Stop or integrate when missing service semantics are material

Name trust boundary, stored state, owner and terminal evidence.

• 1. external sender or internal actor
• 2. provider or Messages boundary
• 3. webhook, push or poll
• 4. normalized message and thread evidence
• 5. AI proposal when Inbox Ops is used
• 6. human review and domain permission
• 7. command or provider send
• 8. reconciliation and business outcome

• business owner
• mailbox owner
• team lead
• application owner
• security and privacy owner
• provider administrator
• implementation team
• support and operations owner

Synthetic operating-model scenarios

Use abstract labels to review choice, authority, failure, reconciliation and acceptance.

Manager acceptance pack

Specify actor, layer, provider state, scope, expected state, prohibited outcome, failure injection, evidence, cleanup, reconciliation, owner and pass criterion.

• 1. internal compose
• 2. internal read
• 3. internal reply
• 4. internal archive
• 5. internal actor-scoped delete
• 6. external email mode
• 7. personal Gmail
• 8. personal IMAP
• 9. multiple channels
• 10. primary swap
• 11. wrong owner
• 12. admin attempt on personal mailbox
• 13. reconnect
• 14. push loss
• 15. poll delay
• 16. token expiry
• 17. malformed inbound
• 18. duplicate inbound
• 19. mis-thread
• 20. split thread
• 21. stripped headers
• 22. cross-mailbox thread
• 23. history import day cap
• 24. history import 5000-message cap
• 25. history import concurrency
• 26. outbound attachment attempt
• 27. provider rejection
• 28. no delivery receipt
• 29. shared Inbox Ops intake
• 30. invalid signature
• 31. replay
• 32. rate limit
• 33. dedupe
• 34. inactive inbox
• 35. model failure
• 36. prompt injection
• 37. wrong organization
• 38. log-only body redaction
• 39. proposal permission
• 40. action permission
• 41. accept-all partial failure
• 42. concurrent reply send
• 43. provider send failure
• 44. offboarding
• 45. retention and export
• 46. outage recovery
• 47. local register privacy
• 48. no-JavaScript and print

Stop or integrate

• no accountable communication owner.
• required provider is not established.
• universal admin access to personal mailboxes is mandatory.
• no reconciliation owner.
• no provider-governance decision.
• no privacy or retention decision.
• no shared-queue operating model.
• no service-policy owner.
• specialist capability is required without an authoritative system.