Connect Salesforce with Smile.io to sync loyalty points, VIP tiers, and referral activity into CRM records, helping teams personalize campaigns and support faster.
• Customer identity is matched between Smile.io and Salesforce using a stable key (typically email, with optional external IDs) to reduce duplicate contact records.
• Smile.io customer objects are mapped to Salesforce Leads, Contacts, and Accounts based on lifecycle rules, with field-level mappings for opt-in, tier, points balance, and referral status.
• Loyalty events (earn, redeem, adjustment, referral, VIP tier changes) are ingested into Salesforce as Activities, custom objects, or platform events, depending on reporting and automation needs.
• Delta sync logic processes only changed records since the last run, with retry handling for transient API failures and idempotent writes to avoid double-posting points events.
• Ownership rules define the system of record per attribute – Smile.io for points ledger and tier logic, Salesforce for CRM attributes and consent fields – with conflict handling logged.
• Order and customer updates from Salesforce (or Salesforce Commerce Cloud, when present) are linked back to Smile.io via identifiers to attribute points to the right shopper and transaction.
• Validation checks enforce required fields and schema constraints before writes, and sync logs capture payloads, timestamps, and correlation IDs for traceability during support investigations.
.png)
We map Smile.io customer and loyalty objects to Salesforce Contacts or Person Accounts, then push points balance, tier, and key status changes into custom fields for reporting and automation.
Common events include points earned and redeemed, tier upgrades, referral shares, and referral conversions, sent as Salesforce Events, Tasks, or custom objects based on how your teams work.
Yes, Salesforce can call Smile.io APIs to adjust points, create manual rewards, or flag accounts for review, with guardrails and logs to reduce “mystery points” tickets.
We match on email as a default, then add fallbacks like customer ID, phone, or external IDs to prevent duplicates when shoppers use multiple storefronts or emails.
It can be, with queued processing, retries, and rate-limit handling, plus separate routing for multiple stores or regions when needed.






