Membership Directory Template with Access Rules

A useful membership directory template separates two decisions: whether someone is a current member and whether each field may appear publicly. Membership does not equal consent to publish. Start with the field-visibility matrix below, then build a directory that returns only fields the member has explicitly chosen to display.

Download the sample CSV · Download the form field specification

Membership directory template

AI-generated editorial concept; not a screenshot of a deployed app.

Use this original sample to organize an association roster. The names and details are synthetic.

Treat each column as a field with its own visibility rule. A blank public bio or website stays blank; the app should not substitute an email address or profile detail. In the second row, the person remains an active member even though their public listing is off.

Decide which public fields serve the directory, collect only those fields, and record consent for each publishable field. A person may be a member without appearing in search results.

A Word membership roster can organize private contacts and notes. Use the visibility matrix when creating a public version of that roster.

Build the directory around field permissions

For a web version, a practical starting model is members, profiles, chapters, and visibility_preferences. Keep verified membership status separate from public-listing consent. Store consent at the field level with the member, field name, allowed-to-display value, and change time. If the member turns off a field, stop returning that value in public responses and remove it from public search output.

Use three roles: members edit their own profile and visibility choices; association administrators review membership and correct records; public visitors can read only the approved directory projection. For a public response, explicitly select display name, chapter, bio, and website only when each preference is true. Do not fetch a full private profile and hide restricted fields in the page with CSS or client-side conditions. The public API response itself must omit email, phone, home address, internal notes, and any unapproved field.

Give a member a preview of their public listing and a clear control for each field. Save the preference change and read it back before showing a “saved” state. Keep an audit entry for administrator changes so staff can distinguish a member’s choice from a correction. A public listing should remain unavailable until the member enables it; importing a roster is not permission to publish it.

To build the proposed application, choose Atoms Cloud or Supabase for this project. The Atoms guide documents them as alternative backends for one project and recommends checking that sample data saves and remains visible after refresh, then confirming the record in the connected database. Atoms: Connect Supabase.

Acceptance checks before publishing

Seed the two sample members. As Casey, turn on display for name and chapter but leave email private; refresh and confirm the choice remains. As Taylor, keep listing consent off and confirm no public result exists. Request the public directory data directly and inspect the response: it must contain only opted-in fields and must not include either member’s email or phone. Sign in as one member and try to read or edit the other member’s profile; deny the request. Then sign in as an administrator, update Taylor’s membership status, and verify the update without changing Taylor’s listing preference.

Keep private profiles out of search indexes: only serve and index public pages when the member has enabled the relevant listing and fields. Membership status must come from the association’s records; do not change it from a client-side success screen.

Build prompt

Use this prompt to define the proposed directory and its access checks:

Build an association membership directory with a private member profile and optional public listing.
Use Supabase as the only backend for this project.
Create members, profiles, chapters, visibility_preferences, and audit_entries tables.
Restrict private profile columns as well as rows; public endpoints return a safe projection.
Add member, association_admin, and public_visitor access levels.
Members can edit only their own profile and field preferences.
Admins can verify membership and manage chapters.
Admins cannot silently opt a member into public display.
Keep membership status separate from listing consent.
Record visibility per field, member, value, and changed timestamp.
Default every public field to hidden until that member enables it.
Allow name, chapter, bio, and website as individually optional fields.
Keep email, phone, address, and internal notes private.
Build a public endpoint that selects only opted-in fields.
Never return private fields and hide them only in the client.
Do not expose a member record when listing consent is off.
Add a member preview and save/readback state for preference edits.
Keep an audit entry for administrator changes.
Seed synthetic members Casey Morgan and Taylor Quinn.
Casey opts into name and chapter but keeps email private.
Taylor keeps public listing disabled while remaining an active member.
Test preference persistence after refresh and profile reopen.
Inspect public responses for missing private fields.
Sign in as Casey and deny reads/edits of Taylor's profile.
Test administrator status edits without changing member consent.
Do not add Stripe or dues payments to this version.
Treat all listed behavior as acceptance criteria to implement and test.

For related implementation patterns, see turning a spreadsheet into a web app and building a client portal.