Airtable for WordPress connects to Airtable via API key (now personal access token) and caches synced records locally so WP templates can render base data without an API round trip per request. That cache typically lives in airtable_sync_records with a per-record JSON column carrying the Airtable fields object, and the plugin's settings sit in wp_options. The default admin shows base mapping, sync status, and a recent-events log.

SleekView reads airtable_sync_records directly. The agent samples the cached fields column and pivots Airtable field types (single-select, multi-select, date, number, attachment, linked-record) into typed SleekView columns. Filters combine field-level conditions across multiple Airtable fields in a single view, which the plugin alone cannot deliver inside WP Admin.

Edits are read-only by default since Airtable is canonical. With write-through enabled, inline edits route through airtable_wp_push which calls Airtable's PATCH endpoint and the cache row refreshes on the next sync tick.

Teams that adopt Airtable as their canonical record store still spend most of their week inside WP Admin and the front-end CMS. The plugin already caches the relevant base data locally so pages render fast, but the cache is invisible to operators because no list view exposes it. That gap turns every triage task into a context switch: open Airtable to update a status, return to WP Admin to keep editing the page that depends on it.

SleekView reads airtable_sync_records directly, pivots the cached fields object into typed columns named after the source base, resolves linked-record IDs to readable names, and routes inline edits through Airtable's PATCH endpoint via the plugin's own client. Airtable stays canonical, the team stops swivelling, and cross-base views become a single screen. The cache the plugin maintains for performance reasons starts pulling double duty as the operational workspace.