The Omnisend WordPress plugin keeps the local footprint thin. A serialized settings array in wp_options holds the API key, brand ID and the global sign-up opt-in default. Per-form embeds register through Omnisend's own form builder and store their state in postmeta on a custom post type. Sync state and webhook health are written into a small set of option keys the plugin checks before showing a status badge in the admin.

The plugin's default UI focuses on the cloud experience: open the Omnisend dashboard to build forms, run campaigns, see analytics. The WP-side audit, which forms ship on which pages, whether opt-in default is on, whether the sync is current, is split across the settings tabs and a connected-state pill, with the form CPT listed as default WordPress tiles.

SleekView reads the forms CPT and the related postmeta into one dataset. Form type (popup, embedded, exit intent, landing page), target audience list, opt-in default, last edit and sync status sit as real columns. Sort by target list to find the audiences carrying the work, filter to forms not edited this quarter to find the stale ones, bulk-trash retired campaigns from the table.

Omnisend is a Shopify-first platform whose WordPress plugin connects the store to the Omnisend cloud. That architecture is correct: the cloud is where automation, segmentation and reporting belong. The trade-off is the WP-side surface, forms, opt-in defaults, sync state, becomes invisible.

Marketing leads who want a one-screen view of "are our lead-capture forms healthy and our sync current" land instead on a connected-state badge and a CPT tile grid. SleekView turns those small but important fields into a real table, so coverage, consent and health become a row per form that updates as the team ships. The data is already in wp_options and the forms CPT, the table surface makes it operational.