Xoxoday Loyalife’s API-first, microservices-based architecture supports simultaneous integration with multiple instances of the same system type—such as two CRMs or two PMSs—within a single environment, using unique source identifiers and data orchestration rules to maintain data consistency and prevent conflicts.
Many large enterprises operate with more than one instance of the same system type—two CRM platforms serving separate business units, or two Property Management Systems deployed across different geographies. Xoxoday Loyalife is built to handle exactly this kind of complex integration landscape without requiring custom middleware or manual reconciliation.
Xoxoday Loyalife’s integration layer treats each connected system as an independent node. Rather than assuming a single source of truth per data type, Xoxoday Loyalife assigns a unique source identifier to every integration. Data flowing in from one CRM is tagged and tracked independently from data arriving via a second CRM, even when both carry overlapping customer records, transaction histories, or membership attributes.
How data orchestration prevents conflicts
When two systems contribute similar data—such as customer profile updates or loyalty point balances—Xoxoday Loyalife applies configurable data orchestration rules to resolve overlap cleanly. These rules define which source takes precedence under which conditions: recency-based (the most recently updated record wins), system-of-record-based (one integration is designated primary for a specific data domain), or merge-based (fields are combined from both sources). This keeps member profiles accurate and loyalty calculations consistent regardless of how many upstream systems are active.
A practical example
Consider an organisation running Salesforce as its enterprise CRM and a regional CRM for local operations. Both systems contain customer data, purchase histories, and engagement records relevant to the loyalty programme. Xoxoday Loyalife ingests data from both concurrently, deduplicates member records using source identifiers, and applies the orchestration rules defined during onboarding. Members receive a unified loyalty experience; administrators see clean, conflict-free data across the dashboard. The same logic applies equally to two PMSs, two ERPs, or any other category where your organisation operates parallel instances.
What this means at implementation
During implementation, each integration is mapped with its own source identifier, data schema, and synchronisation frequency. Xoxoday Loyalife handles transformation, deduplication, and conflict resolution automatically within the platform, so engineering teams are not required to build reconciliation layers before data reaches the loyalty engine.
This architecture also future-proofs your setup. If your organisation adds a third CRM through an acquisition or regional expansion, the same framework accommodates the new integration without rearchitecting existing connections or disrupting live synchronisation.
Learn more: [Xoxoday Loyalife Help Centre — General](
API & Integration Architecture
Understand how Xoxoday Loyalife’s API-first, microservices-based design enables flexible, scalable connections to your existing technology stack.
Data Synchronisation & Conflict Resolution
Learn how Xoxoday Loyalife applies source identifiers and orchestration rules to keep member data consistent across multiple integrated systems.