No. Contacts, automations and OpenGen sends stay in Robly where they belong. SleekView Charts reads only the WP-side plugin storage: settings, mappings and the submission log. Anything the plugin writes locally is fair game for a card, nothing more.

Settings, API token and per-list mappings live in wp_options. Submission audit rows are persisted in a dedicated option array (or custom table on newer plugin versions). SleekView reads each storage path and pivots it into named columns for the chart cards.

Yes. Each dashboard respects a form-slug filter, so a per-form audit dashboard scopes every card to one shortcode and surfaces submissions, list mix and time trend just for that form. Useful for a landing-page form embedded on a single campaign URL.

The cards over local plugin storage work regardless of API state, because they read the WP database directly. Cards that join through an active Robly API call (such as a list-name overlay) gracefully fall back to list ID labels when the key is missing or revoked.

No. Chart queries hit the option store and submission log on read, never on write. Signup forms continue to post through the Robly plugin's own runtime path with no added work, which keeps capture latency unchanged.

Yes. On a multisite or a staging-plus-production setup, the confirmation flag is a single boolean in the Robly settings option. SleekView's multisite roll-up shows that flag as a column on every site, so a staging-on, production-off mismatch surfaces as an obvious split in the chart.

Some Robly plugin versions disable the audit log by default. SleekView shows a friendly empty state on the submission cards in that case, and the settings and mapping cards (which read from wp_options directly) continue to render so the rest of the dashboard stays useful.

Yes. Each saved chart dashboard is scoped by WordPress capability. Marketers see the signup health cards while ops sees the consent flag and per-site rollouts, with each role saving its own filter presets on top of the same Robly dataset.