LinkedIn Feed Pro pulls posts from LinkedIn Company Pages and caches the result locally, primarily in wp_options under the plugin's feed keys, with some installs persisting per-post rows in an optional cache table (typical naming: wp_lif_feed_cache or similar). The default admin lists feeds in per-feed config screens with no unified sortable inventory.

SleekView reads the option blobs and the cache table, exposes one row per LinkedIn feed with company-page name, last-sync, item count, and status, and pairs each feed with the shortcode entries that embed it. Filters like 'stale in the last 24 hours' or 'feeds tied to company page X' become first-class chips, useful for maintenance and content audits.

The grid is honest about LinkedIn's caching model. Most installs cache feeds rather than store every post as a row, so per-post history is feed-dependent. SleekView surfaces both feed-level and per-post views and labels each so admins know what they are looking at.

LinkedIn embeds appear on careers pages, about pages, and trust-building sections of B2B sites. They quietly drift out of date when tokens expire or LinkedIn changes its app-review requirements, and the homepage block goes blank without ever raising an admin notice anyone sees. The default LinkedIn Feed Pro admin is built to configure feeds, not to inventory them, and certainly not to surface failures across multiple Company Pages.

SleekView turns the option-key data into a normal sortable table with company page, last sync, status, and shortcode columns. Editorial teams catch broken embeds before a sales call references a missing post on a careers page. Maintenance teams clear the re-authorization queue once a quarter instead of after a customer complaint.

Agencies running feeds for several client Company Pages get one grid instead of five settings tabs. The cache is the same; the visibility into the cache is what changes.