How to filter an Airtable calendar feed with views

An Airtable calendar feed should rarely publish every dated record in a table. Views provide a maintainable way to decide which records belong in each feed.

Airtable describes a view as a configuration over the same underlying table. Each view can have its own filters, sorting and hidden fields. Filtering a record out of a view does not delete it from the table.

Use views as publishing contracts

Create one view per calendar audience or workflow. Examples include:

Editorial / Scheduled where status is Scheduled
Client / Acme where client is Acme and visibility is External
Field / North team where assignee belongs to North
Events / Vendors where audience includes Vendor

Choose that view when creating the feed. When a record stops matching its conditions, it stops appearing in the generated calendar on a later refresh.

The underlying behavior is documented in Filtering records using conditions.

Prefer stable business conditions

Good feed filters use fields that reflect an operational decision:

Status is Approved
Calendar visibility is External
Assignee is not empty
Start date is within the planning window

Avoid filters based on temporary manual sorting or visual conventions. A person opening a view should be able to explain why every visible record is publishable.

Separate audiences instead of overloading one feed

Do not create one feed with every field and ask subscribers to ignore irrelevant events. Create separate views and feeds when audiences need different records or different privacy boundaries.

An agency might maintain an internal production view and a client-safe delivery view. The client feed can publish approved dates and asset links without exposing budgets, internal owners or draft notes. See Airtable calendar feeds for agencies.

Hidden fields are not the security boundary

The selected view controls which records the Airtable API returns for the feed, while the mapping controls which fields become event content. Use both:

Filter records at the view level.
Map only calendar-safe fields.
Test the final .ics output as a subscriber.
Treat the private feed URL as a credential.

Do not rely on a field being visually hidden in Airtable as proof that it cannot be exposed elsewhere. The explicit event mapping is the final output contract.

Name views for their audience

Names such as Calendar - Client - Acme or Calendar - Field - Marta make ownership and intent visible. This also reduces the risk of selecting a broad operational view when creating a new feed.

For the difference between Airtable's own calendar-view link and a mapped feed, read Airtable to Calendar vs native Airtable calendar sync.