How are people handling separate profile tables for different user types with Softr + Airtable?

Data Sources
1

I’m building a platform using Softr with Airtable as the backend and have run into what feels like an architectural limitation.

I have two types of users, each with a completely different profile structure.

My Airtable base currently has:

  • Users – a lightweight table used for authentication and syncing with Softr (name, email, role, etc.)

  • Applicants – a table containing hundreds of applicant-specific fields, formulas and operational data

  • Experts – a table containing hundreds of expert-specific fields

The Users table is intentionally minimal because I don’t want to duplicate all the fields from the Applicants and Experts tables.

The problem starts with onboarding.

When a user signs up, a record is created in the Users table. Depending on where they signed up, they should then complete either an Applicant onboarding or an Expert onboarding.

If the onboarding flow creates a new record, it creates a separate record in the Applicants or Experts table, leaving me with two records that then need to be linked.

If I use Complete Record, the onboarding can only update the Users table (the table synced with Softr), which doesn’t contain the hundreds of fields required for the actual applicant or expert profile.

Ideally, I’d like the architecture to look like this:

User signs up
      │
      ▼
Users table
      │
      ▼
Linked Applicant record
or
Linked Expert record
      │
      ▼
Onboarding updates the linked profile record

This would allow the Users table to remain dedicated to authentication and shared identity information, while the Applicants and Experts tables remain the source of truth for their respective profiles.

Has anyone implemented something similar?

Specifically, I’d be interested in:

  • How you’re handling multiple user types with separate profile tables.

  • Whether you’re using Airtable Automations, Make, or another solution to create and link profile records.

  • Whether you’ve found a way for onboarding to update a linked record instead of only the Users table.

  • Any architecture that avoids duplicating hundreds of fields across multiple tables.

I’d appreciate hearing how others have approached this.

1 Like
2

Hi @Mygrate

Your diagram is achievable. Here’s how I’d structure it:

  1. Create two signup pages, one for Applicants and one for Experts.
  2. Create two onboarding flow pages, one per user type. Onboarding flows can be assigned based on the signup page, so each signup routes to the matching onboarding automatically.
  3. Set each onboarding flow to the “Add new record” flow type, pointed at the Applicants or Experts table. The key is to have linked record fields in both of those tables linked with the Users table, then having those linked record fields in the Onboarding flow as hidden fields sending the logged-in user’s record ID to that field after the form submission. The record gets created there, linked back to the user, with the fields collected during onboarding.
  4. Set each flow to redirect to its respective home page at the end.

This gives you what you described. The Users table stays minimal and dedicated to auth, Applicants and Experts stay the source of truth for their own fields, and nothing is duplicated across tables. You also avoid conditional branching inside a single form, since each user type has its own dedicated flow.

Hope this helps.

1 Like
3

Resolved it with a script..