An association runs on its member records, and the website has to agree with them
The American Chiropractic Association is the largest professional chiropractic organization in the United States. Its mission, in its own words: "To inspire and empower our members to elevate the health and wellness of their communities."
Like most associations, ACA keeps its members in an association management system. Theirs is Cobalt, which runs on Microsoft Dynamics. That database knows who is a member, what kind, which councils and committees they belong to, and whether their dues are current. The website, acatoday.org, is where those same members come for resources, governance documents, and council pages.
The people caught between the two systems are the membership and communications staff. When the website and the database disagree, a member who has paid is told they have no access, and a staff member spends the afternoon working out which system is wrong.
Two systems, and staff in the middle
An association website that keeps its own list of users drifts away from the truth a little every day. Someone joins a council, and the website does not know. Someone lets their membership lapse and the website still lets them in. A member ends up with two passwords, one for the association and one for the site, and forgets the second one.
ACA's structure raises the stakes. Members belong to specialty councils, serve on committees, and sit in the House of Delegates. Each of those groups has material meant only for its own people. Setting that up by hand, member by member, is work nobody at ACA has time for, and it would be wrong again by the following month.
The same is true of directories. A list of committee members typed into a page is out of date the first time the committee changes. A public directory of chiropractors is only useful to a patient if the people in it are still members.
ACA's staff wanted to keep managing members in one place, the database they already use, and have the website follow.
We made the member database the source, and the website the follower
Members sign in with the account they already have. The website hands sign-in to ACA's member database and gets back an answer about who the person is. The site never stores a member's password, so a member has one password to remember and staff have one place to fix an account.
The answer comes with the details that matter. Along with the member's name, the database sends their membership status and the councils and committees they belong to. A council's resource page opens to that council's members and nobody else, with no list for staff to keep on the website.
A closed door explains itself. ACA's communications team specified what each visitor should see when a page will not open, and we built it to their design. Someone who is not a member is invited to join. A member who lacks access to that one page is told so plainly and pointed to their membership record. Nobody is left staring at a vague error, wondering whether to call the office.
Directories come from the records. Committee, council, and custom group directories on the site are drawn from member data, and staff drop one onto a page and choose what it shows. Members who asked not to be listed are left out. On Hands Down Better, ACA's site for the public, the Find a Doctor search refreshes from the member database on a schedule, so a patient looking for a chiropractor nearby finds current members who chose to be listed.
We rehearse changes to the connection. ACA's member database has no practice copy, so a change to sign-in cannot be tried somewhere safe first. So we built a rehearsal: we capture a real sign-in response, run it through every check the new version makes, and fix what fails before installing anything. On the most recent update, that run showed the new version needed one added setting on the database side, which ACA's technology staff arranged. We installed the update on a Sunday night and signed in as four test members of different kinds. Monday was an ordinary day.
Staff manage members in one place, and the website follows
Today a member signs in once, with the account they already had, and sees what their membership entitles them to. If they join a council next month, its pages open to them without anyone touching the website.
The membership and communications staff keep working in the database they know. They add a directory to a page when they need one, and it stays current because the records behind it do. When a page will not open for someone, the message on the screen usually answers the question before it reaches the office.
Our part is the connection itself, along with hosting and upkeep for both sites. We treat anything that touches sign-in as something to rehearse, and we schedule it for hours when members are not there.
What changed
- Members sign in with the association account they already have, and the website stores no passwords
- Council and committee pages open to the right members based on what the member database says
- A member who cannot open a page is told why, with a button that takes them to the fix
- The public Find a Doctor directory refreshes from the member database on its own
- Updates to the sign-in connection are rehearsed first and installed outside business hours
Under the hood
For the developer evaluating us
- 3,000+member accounts created by sign-in
- 43managed forms
- 15custom database tables
- 70+columns read per member record
- 17page layouts staff can build
- 3denied-access messages, by status
- 4test accounts for every change
What We Built
- Single sign-on between the website and the association's member database
- Page and section access driven by membership status, councils, and committees
- Clear messages and next steps for members who cannot open a page
- Committee, council, and custom group directories drawn from member records
- A public Find a Doctor directory that refreshes from the member database
- A rehearsal routine for changes to the sign-in connection
How sign-in works
The site uses SAML 2.0 single sign-on, with ACA's Cobalt system as the identity provider. A member who chooses Sign In is sent to the association's member portal, authenticates there, and returns with a signed response. WordPress creates or updates a local account from that response. No member password is stored in WordPress.
The response carries profile details, membership status, and group memberships. The theme reads those on each visit to decide what the member may open.
Access rules
Any page, and any section within a page, can be limited by membership status, by group (council, committee, or governance body), or both. Both checks must pass. Three denied states have their own message and button: signed out, signed in but not a member, and member without access to that page. Member-only documents are served through authenticated page addresses, and direct file addresses are blocked at the server.
Directories
A custom plugin holds member, committee, and council records in purpose-built tables, loaded from exports of the member database through a guided import that validates the file, processes it in batches, and keeps a log of every run. Three shortcodes place committee, council, and custom group directories on a page, with search, paging, optional fields, and respect for each member's opt-out.
The public Find a Doctor directory
On Hands Down Better, scheduled jobs fetch member data from the Cobalt API, compare it with what the site holds, remove members who are no longer listed, add new ones, and update the rest. Addresses that changed are geocoded again in small batches. The jobs run inside WordPress on a schedule, with no public endpoints.
Rehearsing a sign-in update
Because the identity provider returns only to the production site, the rehearsal happens offline. A captured response from a real sign-in is run through the new version's validation rules in order, so every failure shows up in one pass. Installation happens outside business hours, followed by sign-in tests with accounts for a non-member, a member with no council, and members of two different councils. Automatic updates for the sign-in software are turned off on purpose.
Hosting
Both sites run on managed cloud hosting behind Cloudflare Enterprise, with server-side malware scanning, daily backups, and weekly updates for everything except the sign-in software.
Figures current as of September 26, 2026
