arXiv subjects

Devam Gupta

Publications and source records attributed to Devam Gupta.

3 recordsLinked to original sources

arXiv2026

SMS Opt-In/Opt-Out Consent Record Architecture in Enterprise CRM Systems: Compliance Patterns for Multi-Tenant Managed Packages

Regulatory frameworks such as the Telephone Consumer Protection Act (TCPA) impose strict consent requirements on enterprise messaging systems: organizations must obtain and record explicit opt-in consent before sending SMS communications, and must immediately honor opt-out requests. While CRM platforms provide rich contact and lead data models, they do not natively model consent state as a first-class record type. This gap becomes architecturally significant in multi-tenant managed packages distributed via enterprise application marketplaces, where the package cannot assume or modify the installing organization's schema. This paper presents a production consent record architecture, generalized from patterns implemented within a CRM-native messaging managed package serving independent enterprise organizations spanning healthcare, financial services, and sales operations. We describe the data model design, keyword-based consent capture, a hash-based uniqueness strategy for deduplication, suppression enforcement at message send time, and the multi-tenant constraints that shaped these design decisions.

cs.SE↗

arXiv2026

Two-Path Status Verification for Outbound Enterprise Messaging Pipelines: Webhook and Scheduled Polling Fallback Architecture

Outbound enterprise messaging pipelines face a fundamental reliability challenge: delivery status callbacks (webhooks) from messaging providers are subject to network failures, endpoint unavailability, and provider-side retry exhaustion, resulting in stale status records in the CRM system of record. A naive single-path architecture that relies exclusively on webhooks leaves a population of messages permanently in an intermediate state when callbacks fail. This paper presents a two-path status verification architecture, generalized from patterns observed in production CRM-native messaging systems built on multi-tenant platform-as-a-service infrastructure. The primary path uses a real-time webhook received by a REST endpoint, which publishes an internal event for asynchronous record update. The fallback path uses a configurable scheduled polling job that detects records still in transitional status after a configurable interval and queries the provider's status API directly to reconcile state. We describe the event-driven primary path, the scheduler-based fallback, deduplication via idempotent upsert, the sync failure detection mechanism, and the platform resource-limit considerations that shape each design decision.

cs.SE↗

arXiv2026

Salesforce Messaging Architecture: Platform Events, Async Sends, and Multi-Tenancy at Scale

Most enterprise messaging integrations function as external connectors. They reside outside the Customer Relationship Management (CRM) platform, receive webhooks, write peripheral logs, and consider the process integrated. Consequently, messages are isolated within the messaging platform while CRM records remain strictly inside the CRM, bridged only by fragile sync jobs, rigid field mappings, and eventual consistency windows. This paper outlines an alternative architectural paradigm: constructing the entire messaging core natively inside the CRM. Within this model, every message is treated as a native CRM record,every outbound path is a platform-native transaction, and all state parameters - including delivery status, opt-in metrics, conversation history, and record ownership - are stored as standard database objects. This structural native alignment allows the system to utilize standard reporting pipelines, operate inside native workflow builders, and trigger platform automation seamlessly. Drawing from a production managed package deployed across independent enterprise organizations spanning healthcare, sales operations, field services, and customer support, this study evaluates the core design patterns, platform scaling mechanics, multi-tenant decoupling constraints, and the boundaries of the platform-native architectural design.

cs.SE↗