How to restrict a new collaborator's access to historical records and sensitive fields?

re: Field-Level Security: I have a "Salary" column in my base that is highly confidential. I want to ensure that certain team members cannot see this specific field.

I’d recommend using Interfaces for this.  You’d make sure that your users do not have Base access and only have Interface access, and then would ensure that the pages that your users have access to don’t have the Salary field available

The downside to this is that your users won’t be able to create their own fields, views or automations etc which is a pretty big limitation.  To solve for this, you could consider having two bases instead:

1. Base A: Everyone has access to this
2. Base B: Only you (and other relevant people) have access to this.  You’ll sync data from Base A over to this base, and the Salary field will be in this base as well

---

re: Historical Data Restriction: When a new staff member joins the team, I want them to only be able to view records created from their start date onwards. I need to find a way to hide all "historical" records that were created before they joined the base.

Hm I think this is theoretically possible with Interfaces.  Interfaces let you filter records based on whether the logged in user is linked to that record in some form (documentation here: https://support.airtable.com/v1/docs/interface-designer-permissions?highlight=interface#filtering-data-by-current-user)

And so the idea would be to have automations that would run every time a record gets created in your base that would link the newly created record to all the currently active users, which would then allow you to filter on them.  And so if a new user joined today, they wouldn’t be able to access all the records created before he joined, but anything new would be linked to him and thus accessible, does that make sense?

 I don’t know whether this is actually viable though as it’d eat through your automations pretty quickly if you create lots of records.  There’s also a bit of weirdness to deal with with linked records, e.g. if an Invoice was created yesterday but the line items were created today, the new user would be able to view the line items but not the Invoice it was linked to

Hey ​@kethieumau,

I’d highly suggest following Adam’s advice above. It is spot on. Feel free to grab a slot using this link, I’d be happy to show you around if that helps.
 

Mike, Consultant @ Automatic Nation 
YouTube Channel

Hey ​@kethieumau !

Airtable's permission model works at the base/table level, so here's how to implement security for your recruitment process.

Solution for Salary Field:

Option 1: Interfaces (Recommended)

• Create separate Interfaces for different roles
• Use field visibility settings to hide the Salary field from certain user interfaces
• Set interface permissions so users can only access their assigned interface
• Restrict base-level access - give most users "Commenter" or interface-only permissions
• Reserve Creator/Editor base access only for HR leads who need full data access

Option 2: Separate Tables

• Split into Candidates (general info) and Compensation (salary data) tables
• Link via a lookup relationship
• Give different permission levels to each table if you're on Enterprise

Option 3: Enterprise Field Permissions

• Enable field-level permissions on Enterprise plan
• Restrict Salary field to specific collaborators
• Most robust native solution

Solution for Historical Records:

Option 1: Interface Filters (Cleanest Approach)

• Create interfaces with date-based filters: {Created Time} >= [User Start Date]
• Set up user-specific interfaces or cohort-based interfaces
• Users only see records created after their access date

Option 2: Automation-Based Tagging

• Add a Visible To linked field that automatically tags records
• Use automations to assign visibility groups based on creation date
• Filter interfaces by visibility tags

Option 3: Time-Based Views

• Create filtered views showing only records from specific date ranges
• Share specific view links with team members
• Pair with interface-only access to prevent filter modification

Implementation Best Practices:

• Minimize base-level Creator/Editor access - this is your main security lever
• Use Interfaces as the primary access point - most users never need to see the base
• Audit permissions regularly - especially as team members change roles
• Document your security model - so everyone understands access rules

Flow Digital - Airtable Gold Services Partner — We're happy to help!