Best Make Workflow for Keeping CRM and Digital Membership Cards in Sync?

Questions
1

Hi everyone,

I’m working on an automation project for a membership platform that serves museums and other visitor-based organizations.

The goal is to keep member information synchronized between the CRM and digital membership cards without requiring manual updates.

The workflow we’re considering looks something like this:

  1. A member updates their email or phone number in the CRM.
  2. Make detects the change.
  3. The digital membership card is updated automatically.
  4. If the member renews or upgrades their membership, the card reflects the new status.
  5. If the automation fails, the team receives an alert so it can be reviewed quickly.

One question I have is how others handle situations where multiple systems update the same member record within a short period of time. Do you rely on timestamps, webhooks, queues, or another strategy to prevent conflicts?

2

Hey John,

you should never allow multiple systems to update one record at the same time. Have one scenario update the record. Then the other systems can call the same scenario to handle the updates.

Also your explanation doesn’t seem to show different systems updating a record, its just the CRM one, so what’s the problem?

Whenever something is updated (info, subscriptions, etc.) reflect that in the CRM. Then when the CRM is updated, update the card. This way only changes in the CRM will update the card and any CRM worth their money has a built in log where you can track the changes made.

3

I’d treat this less as a synchronization problem and more as an ownership problem.

First decide which system is authoritative for each field. If the CRM owns contact and membership data, updates from other systems should return to the CRM first; the membership card then reflects the CRM state.

For conflicts, I wouldn’t rely on timestamps alone. Use a stable member ID, record the source of each change, and make every update idempotent so retries or duplicate webhooks cannot apply the same event twice.

The right architecture depends on one detail: can the card platform also modify member data, or is it only displaying data received from the CRM?

4

I’d treat the CRM as the system of record, then make every downstream card update idempotent.

A reliable Make pattern is:

  1. Receive the CRM webhook and immediately store the member ID, event ID, changed-at timestamp, and desired card state in a small queue/data store.
  2. Process updates sequentially per member. Before writing, read the latest CRM record again so an older event cannot overwrite a newer change.
  3. Upsert the card by a stable external member ID—not by email—then store the last successfully applied CRM version/timestamp.
  4. Ignore duplicate event IDs and reject any event older than the last applied version.
  5. Route failures to a retry path with attempt count, error detail, and a dead-letter alert after the retry limit.
  6. Run a scheduled reconciliation scenario (for example nightly) that compares active CRM memberships with card status and repairs drift.

If another system must initiate a change, have it write to the CRM first. That keeps one authoritative history and prevents two-way update loops. Webhooks give you speed; the queue/version check gives you ordering; reconciliation gives you eventual consistency when a webhook is missed.