Syncing an association management system with the show registration platform

A member rings the registration desk on the Monday of show week, unhappy. She has been charged the non-member rate. She renewed in August, she has the receipt, and she does not see why she is arguing about it in a queue.

Nobody made a mistake. She registered on 12 June, when she had lapsed. She renewed on 14 August. The registration platform copied her status once, in June, and has been holding a flag ever since. An association management system sync that moves membership status as a simple true or false will produce this conversation several dozen times a show, and the fix is a data model question rather than a support question.

What each system believes it owns

The association system holds a member identifier that predates every show you have ever run and will outlive the registration platform you are currently using. Around it sits a membership history: joins, renewals, grace periods, lapses, reinstatements, category changes, each with dates attached. Membership is a state over time, and the association system is built to know what that state was on any given day.

The registration platform holds a registration. One row, one person, one edition, created on a date and largely fixed afterwards. It has somewhere to put a member flag because pricing needs one, and that field is a copy taken at a moment.

Both models are right for their own job. The friction comes entirely from copying a time-varying thing into a field with no time in it.

Personify's own product listing gives a sense of how many of these systems sit around a show: WildApricot, MC Professional, MC Trade and ThreeSixty, alongside a2z Events, which it describes as "an award-winning events management and optimization platform for event planners and show organizers" with "online tradeshow floor plans, event websites, abstract/speaker management, matchmaking tools, personal itinerary builder, mobile apps and more" (Personify, 2026). Where the association platform and the event platform come from the same supplier, some of this is handled for you. Where they do not, and for most organisers running shows on behalf of several associations they do not, the sync is yours to design.

Why does a member status copy go stale within days?

Because membership changes on its own calendar and your show is not on it.

Renewals cluster around anniversary dates or a common renewal month. Lapses happen after a grace period expires, which is a date arithmetic event triggered by nothing at all. Joins spike when somebody wants the member rate for your show, which means the joining happens after the price comparison and possibly after the registration. Category upgrades happen when a small firm hires its fifth employee.

None of those events knows your show exists, and none of them will notify your registration platform. So the copy taken on the day of registration starts decaying immediately, and it decays fastest for the people who registered earliest, who are your most engaged attendees.

Working the drift on 1,000 registrations

Take one show. Registration opens 1 May, doors open 5 October, and you sample 1,000 registrations. For each one, pull the membership status as it stood on the registration date, and pull it again as it stands on 5 October.

At registration, 612 were members and 388 were not. At show open, 588 of the original 612 are still members, because 24 lapsed over the summer. Of the 388 non-members, 47 have since joined. Membership at show open is therefore 588 plus 47, or 635.

Seventy-one records out of 1,000 changed status between registration and show open, which is 7.1 per cent. That is not a rounding error and it is not evenly spread. Of the 24 lapses, 19 belong to people who registered before 1 July, because a longer gap gives more time for a renewal date to pass. The median gap across the whole sample is 84 days, but the May cohort sits at around 157 days and the late September cohort at around 10.

Now count member attendance for the post-show report. You can say 612, which is status at registration. You can say 635, which is status at show open. You can say 588, which is people who were members on both dates. Three defensible numbers, a spread of 47 between the widest pair, and whichever one appears in the pack will be compared next year against whichever one appeared last year.

The direction of the error is worth noticing too. Joins outnumbered lapses here by roughly two to one, 47 against 24, which is what you would expect on a show where the member rate is materially cheaper and joining is easy. That means a report built on status at registration systematically understates member participation, and it understates it more in years when registration opened earlier. A show that moved its launch forward by six weeks will appear to have lost member share against the prior edition, purely because there was more time for the copy to go stale. That is a comparison failure with no data-quality defect anywhere in it.

Store the status twice, with dates on it

The warehouse pattern for this is old and well described. Margy Ross of the Kimball Group described the standard responses to a changing attribute as "type 1 (overwrite), type 2 (add a row), and type 3 (add a column)", with rows linked over time through "the dimension's durable key" (Ross, 2013). Membership status is a textbook type 2 attribute, and the member identifier is the durable key.

In practice that means three things.

Keep a membership status table with one row per status period, carrying the member identifier, the status, a valid-from date and a valid-to date. Everything else is derived from it, so you never have to decide in advance which snapshot somebody will ask for.

On the registration record, store status as of the registration date as a fact, because that is what the price was based on and it must never change afterwards. A price charged in June cannot be retrospectively justified by a status in August.

Compute status as of show open at show open, and use that for entitlement at the door. That is what the member is paying for on the day, and it is the reading that stops the conversation in the queue.

Keeping the copy current has a second reason behind it. The GDPR requires personal data to be "accurate and, where necessary, kept up to date", with "every reasonable step" taken so that inaccurate data is "erased or rectified without delay" (EU, 2016). A membership flag that has been wrong since August, in a system that emails people and prints their badge, is squarely inside that.

What should the sync move, and how often?

Direction. One way, from the association system into the registration platform, for status. Never write status back from a show system. If your event platform can create members, it is now a second authority over a record that outlives it, and the two will disagree inside a season. Reconciling that afterwards is a separate and thankless routine.

Key. The member identifier, carried onto the registration record as its own column. Not the email, which changes. Not the registration platform's contact identifier, which belongs to the platform.

Payload. Status, status effective date, member category, and the paid-through or renewal date. That last field is the one people leave out and the one that lets you predict a lapse before it happens rather than discovering it at the desk.

Cadence. Nightly for most of the year. Hourly in the final fortnight and through show week, when joins and renewals cluster because people are looking at the member rate. A same-day on-demand lookup at the registration desk for the disputed cases, which will be a handful and will each take ten minutes to resolve without it.

Where members arrive through a partner association rather than your own, the identifier problem is different again and counting those registrations without double paying has its own rules. The pricing gap between the two rates, and what it should be, is a commercial question rather than an integration one.

Where this stops

A perfect sync tells you what the association system believes. It does not tell you whether that belief is right, and association data has its own decay: a member who left the industry two years ago and whose direct debit still runs, a company membership held in the name of somebody who has since retired, a chapter whose records were merged in a migration and never reconciled.

The sharper limit is on the person-to-member join itself. Membership is often held by an organisation, with named contacts attached, and the person registering may be a colleague entitled to the member rate through the company without holding a record of their own. That entitlement lives in a relationship, not in a status field, and no sync of a status flag will represent it. Where that pattern is common, the useful key is the organisation's member identifier plus a domain or a named-contact list, and the honest position is that some share of your registrations cannot be classified automatically at all. Say what that share is, in the same way the rest of your integration reporting should carry its own error bars.

This week, take 1,000 registrations from your last edition and pull membership status twice: as of each registration date, and as of the show open date. Count how many changed. That single percentage tells you whether your current sync is adequate, and it takes one query against each system.