Field Permissions
How to set field-level permissions in CollabPortals to control visibility and editability of individual fields.
Overview
Field permissions let you control where each individual field in a table appears. While table permissions control broad actions (view, create, edit, delete), field permissions fine-tune exactly which data users see and interact with.
For examples of which fields teams choose to hide, see CRM portals and insurance portals.
The Four Settings
Each field has four switches, and they are independent of each other:
| Setting | Where it applies |
|---|---|
| View | The table, gallery and kanban cards, the calendar, and the record detail page |
| Create | The create form, and the sign-up form if the table is your user table |
| Edit | The edit form |
| Required | Whichever of the create and edit forms the field appears on |
A field with everything off never appears in the portal at all. Use that for internal data (IDs, admin notes, working columns) that portal users don't need.
Configuring Field Permissions
- 1
Open portal settings
Navigate to your portal's configuration page and find the table you want to configure.
- 2
Expand the field list
Click on a table to see all its fields listed with their switches.
Every field in the table, with its four switches. The handle on the left of each row sets the field's position. - 3
Find the field you want
On a table with a lot of fields, type into Filter fields by name above the list to narrow it to the one you are looking for. The filter matches the field name, not the type.
Filtering to one field out of thirteen. Clear the filter to go back to the full list, which is also what dragging needs. - 4
Turn on what each field needs
Switch View, Create, Edit and Required on or off per field. Click the row itself to open the extra settings for that field, such as the linked-record allowlist. Remember to save.
Combinations Worth Knowing
Because the settings are independent, a few useful patterns fall out:
View without Create or Edit
The classic read-only field. It shows in the table and on the record detail page as plain text, with no input control.
Good for: calculated fields, status fields your team manages, reference data.
Create without Edit
A write-once field. The user sets it when they create the record, and it is locked from then on.
Good for: a reference or order number, a submission date, a category that should not move after intake.
Edit without Create
A field assigned after the record exists, so the create form stays short.
Good for: a Status or Owner field your team fills in once the record has been triaged.
Edit without View
The field is collected on the form but does not appear on any read surface.
Good for: a table with First Name, Last Name and a calculated Full Name. Show Full Name on the table and detail page, and collect First and Last on the forms, so the user never sees three name fields at once.
Create or Edit without View is a layout choice, not a way to keep a value secret. The form input still shows the current value to anyone who opens it, so treat a field you let someone edit as one they can read. To keep a value away from portal users entirely, switch everything off: a field with nothing on is never sent to the browser at all.
Turn Required on for fields that are essential to your workflow, like a project name or due date. It applies on whichever forms the field appears on, so a create-only required field is required at intake and never asked for again.
Field Order
Drag a field by the handle on the left of its row to change where it appears. There is one order per table and it drives every surface: the table columns, the gallery, kanban and calendar cards, the record detail page, the create and edit forms, and the sign-up form when the table is your user table.
The field pickers on the Display tab still choose which fields each view shows. They no longer decide the sequence, so a field sits in the same place wherever it appears and you only arrange it once.
Dragging works on the full list. If you have the name filter active, clear it first: reordering a filtered list would move a field past rows you cannot see.
Put the fields people fill in most at the top of the form and the rarely-touched ones underneath. Combined with Create and Edit, you can keep an intake form to three questions while the edit form carries the full record.
Fields you add in Airtable later appear at the end of the order rather than in the middle of it, so a new column never quietly interrupts a sequence you arranged. Drag it where you want it. Fields you delete in Airtable drop out of the order on their own.
New Fields from Airtable
A field you add in Airtable after building your portal starts with everything off. It appears in the field permissions list on the next schema refresh, at the end of the field order, with View, Create, Edit and Required all unticked. Nobody sees it until you say so.
This is the opposite of how fields behave when you first build a portal, where everything the portal can show arrives already on so you are not ticking forty switches by hand. The difference is deliberate: adding a column to a base you use for other things should not quietly publish it to your portal users.
When CollabPortals spots fields it has no settings for, the top of the field list says so and offers to turn them on in one click. That applies the same settings they would have had if they had existed when you built the portal, so ordinary fields become visible and editable and computed fields become visible and read-only.
The prompt only covers the types that would have been on from the start. A newly added linked record field, or one of the types that are opt-in anyway (count, button, AI text, sync source, collaborator, rich text, barcode and duration), is not announced and stays hidden, the same as it would have been on the day you built the portal. Those you turn on yourself by ticking View on the field.
Adding a field in Airtable is safe. If you want your portal users to see it, open the portal's Access tab and either use the prompt at the top of the field list or tick View on the field yourself.
Interaction with Table Permissions
Field permissions work within the context of table permissions:
- If a table's View permission is off, field permissions don't matter, since the entire table is hidden
- If a table's Edit permission is off, there is no edit form, so a field's Edit setting has nothing to apply to
- If a table's Create permission is off, the same goes for a field's Create setting
Example
| Table Permission | Field Settings | Result |
|---|---|---|
| View: On, Edit: Off | View, Edit | Shows in the table and detail page, no edit form to appear on |
| View: On, Edit: On | View, Edit | Shows everywhere, and is editable |
| View: On, Edit: On | All off | Not visible at all |
| View: On, Create: On | View, Create, Required | Required in the create form, read-only afterwards |
| View: On, Edit: On | Edit only | Collected on the edit form, absent from the table and detail page |
Computed Fields
Some Airtable field types are always read-only regardless of permission settings:
- Formula fields
- Rollup fields
- Count fields
- Lookup fields
- Auto number fields
- Created time fields
- Last modified time fields
For these, the Create, Edit and Required boxes are greyed out: their values are calculated by Airtable, so the portal can show them but can never write them. View is the only setting that applies.
Best Practices
- Start restrictive - Begin with fields off and selectively reveal what users need
- Hide internal fields - IDs, internal notes, and admin-only flags should be hidden
- Require key fields - Turn Required on for fields critical to your workflow
- Lock what should not change - Turn Create on without Edit for reference numbers and intake dates
- Review after Airtable changes - When you add fields in Airtable, remember to update their permissions in CollabPortals
Next Steps
- Table Permissions - Set table-level actions
- Role-Based Access Control - Different field permissions per role
- Summary Fields and Record Detail - Pick which viewable fields show on the row vs the detail page, and the order they appear in
- Supported Field Types - How each field type renders