Setting Up Your Airtable Base

How CollabPortals Connects Users to Data

CollabPortals needs to know two things about your Airtable base:

1. Who is this user? It matches the portal user's email to a record in your "user table."
2. What data belongs to them? It follows linked record fields from other tables back to that user record.

If your base doesn't have these two pieces in place, users will be able to log in but won't see any data. This guide walks through exactly how to set things up.

The User Table

Every CollabPortals portal needs a user table: a table where each row represents one person who will use the portal. This table must have an email field.

Common names for this table: "Contacts", "Clients", "Users", "Team Members", "Students", "Vendors."

At minimum, the user table needs:

Field	Type	Purpose
Name	Single line text	Display name for the user
Email	Email	How CollabPortals identifies the user (must be unique per person)

You can have as many other fields as you like on the user table (phone, company, role, notes, etc.). The email field is the only one CollabPortals requires.

Linking Data to Users

Here's the part that trips people up: for CollabPortals to filter a table's records per user, those records need to be linked back to the user table.

The usual way is a direct link: add a "Link to another record" field (the multipleRecordLinks field type) that points to your user table, and link each record to the user it belongs to.

A table can also reach the user table indirectly. If it links to another table that links to your users, a lookup that pulls the user across that chain can act as its ownership field, so you get per-user filtering without adding a second direct link. That is common: Structures link to Cities, Cities link to Members, and a lookup of the City's Members owns the Structure. See Record Ownership for how to point ownership at a lookup.

Linking is the mechanism for per-user filtering, but it is not the only way a table can appear in a portal. A table with no path to the user table at all can still be shown to everyone who can view it, or nested inside a parent record as a related tab. The sections below cover when to use each.

Example: A Project Management Base

Say you have three tables:

Table	What it stores
Contacts	One row per person (the user table)
Projects	Client projects
Tasks	Individual tasks within projects

For a portal user to see their projects, the Projects table needs a linked record field pointing to Contacts:

Projects Table
Project Name	Client (linked to Contacts)	Status
Website Redesign	Alice Smith	In Progress
Brand Strategy	Alice Smith	Complete
Mobile App	Bob Jones	In Progress

When Alice logs in to the portal, CollabPortals sees that her email matches "Alice Smith" in Contacts, then shows her only the projects linked to her record: "Website Redesign" and "Brand Strategy." She never sees Bob's "Mobile App."

What About Tasks?

Tasks usually belong to a project rather than to a person directly. You have two ways to surface them, and the right one depends on how you want users to reach them.

Option 1: Show tasks inside each project. This is the natural fit for one-to-many data: tasks under a project, line items under an order, reports under a property. If your Tasks table links to Projects, you can show a project's tasks as a tab on that project's record. A user opens a project in the portal and finds a "Tasks" tab next to the details, scoped to just that project's tasks. The Tasks table does not need its own link to the user table here: it inherits its scope from the project the user opened. Turn this on with the Show as related tab option on the Project's Tasks field in your portal's table settings.

Option 2: Give tasks their own direct link. If you want a standalone Tasks page in the sidebar that filters per user, where each user sees only their own tasks across every project, the simplest setup is a linked record field on Tasks pointing straight to Contacts. A per-user page scopes on the field you name as the table's ownership field, and a direct link is the most direct one to name.

Option 3: Scope the standalone page through a lookup. If you would rather not add a direct link, a Tasks-to-Projects-to-Contacts chain can scope a standalone Tasks page through an Airtable lookup instead. Add a lookup on Tasks that pulls the Contact across the Project link, then set that lookup as the table's ownership field. See Record Ownership for the walkthrough. A plain chain with no direct link and no lookup ownership field does not scope a standalone page on its own.

Tasks Table
Task Name	Project (linked to Projects)	Contact (linked to Contacts)	Due Date
Design homepage	Website Redesign	Alice Smith	2026-04-01
Write copy	Brand Strategy	Alice Smith	2026-04-15
Build API	Mobile App	Bob Jones	2026-03-30

Common Base Patterns

Simple: Every Table Links to Users

The most straightforward setup. Every table has its own linked record field pointing to the user table.

• Contacts (user table)
  • Projects links to Contacts
  • Invoices links to Contacts
  • Documents links to Contacts

With Cross-Table Links

Tables often link to each other for your own workflows (Tasks to Projects, for example). A table that should filter by user has two ways to scope: give it its own direct link to the user table, or point its ownership field at a lookup that follows the cross-table link to your users.

• Contacts (user table)
  • Projects links to Contacts
  • Tasks links to Projects, then scopes per user either by its own link to Contacts or by a lookup of the Project's Contact
  • Invoices links to Contacts
  • Notes links to Projects, scoped the same way as Tasks

A direct link is the simplest to reason about, and the right default when a table naturally belongs to a person. A lookup ownership field saves you from maintaining a second link when the table already reaches your users through another table, and it never drifts out of sync the way a copied link would. Either way you tell CollabPortals which field decides ownership.

What Happens Without Links

A table with no path to the user table, neither a direct link nor a lookup that reaches it, can still appear in a portal, in one of two ways:

• As a standalone page that shows everyone the same records. Turn the table on and every user who can view it sees every record. This is fine for reference tables (like a "Categories" or "Statuses" table) that everyone should see. There is no per-user filtering, because the table has no path to scope on.
• As a related tab nested inside a parent record. The tab shows only the children of the record the user opened (a project's tasks, an order's line items), following the parent's link. The child table needs no link of its own to the user table.

Setting Up Links in Airtable

If your base doesn't have the right links yet, here's how to add them:

1. 1

   Open the table that needs linking

   Go to the table where records should be filtered per user (e.g., Projects).

2. 2

   Add a Link to another record field

   Click the "+" button to add a new field. Choose "Link to another record" as the field type. Select your user table (e.g., Contacts) as the target.

3. 3

   Link existing records

   Go through your existing records and link each one to the correct user. Click the cell in the new linked record column and select the right person.

4. 4

   Link new records going forward

   When adding new records in Airtable, always link them to the appropriate user. CollabPortals auto-links records created through the portal, but records created directly in Airtable need to be linked manually.

Checklist Before Creating Your Portal

Before you create your portal, confirm:

• You have a table with one row per person and an email field (your user table)
• Every person who needs portal access has a record in the user table with their email address
• Every table that needs a standalone, per-user page has its own linked record field pointing directly to the user table
• Child tables you'd rather show inside a parent record (tasks under a project, line items under an order) link to that parent, ready to surface as a related tab
• Existing records are linked to the correct users
• Reference tables and standalone pages that everyone should see don't contain sensitive data

Common Mistakes

"My users can log in but see no data" The most common cause: the data tables aren't linked to the user table. Add a linked record field and connect the records.

"Users see all records, not just their own" The linked record field exists but the records aren't actually linked to anyone. Open Airtable and check that each record has a value in the linked record column.

"I added a linked record field but it points to the wrong table" The linked record field must point to the user table you selected when creating the portal. If your user table is "Contacts," the link should go to "Contacts," not to some other table.

"Some tables filter correctly but others don't" Each table needs its own direct link to the user table. If Projects filters correctly but Tasks doesn't, check that Tasks has its own "Link to another record" field pointing to Contacts. Linking Tasks to Projects is not enough.

Next Steps

• Creating a Portal - Build your portal once your base is ready
• Table Permissions - Control which tables are visible
• Linked Record Filtering - Restrict dropdown options in linked record fields
• Record Filtering - Limit which rows a portal shows
• Related Tabs and Nested Tables - Surface a linked table as a related tab or a page