No. Contacts and journey state stay in Ortto, where the customer record is the single source of truth. SleekView surfaces only the WP-side settings, form mappings and consent flags the plugin stores in your database. The data flow is one direction by design: forms post to Ortto, audits read from WordPress.

In wp_options as a serialized array. The capture-script enable flag, API token, and tracking domain are all there. SleekView pivots the array into named columns so the underlying serialized blob becomes a readable table that legal, ops and engineering can each scan for the rows they own.

When you bridge a form to Ortto, the form-to-list mapping is saved on the form's metadata. The exact location depends on which form plugin you bridge: Gravity has its own meta keys, Fluent has its own, Contact Form 7 stores in postmeta on the form post. SleekView reads the standard locations for all three so a mixed-form site still produces one clean table.

Yes. The next form submission posts to the new list. SleekView writes the mapping back to postmeta, the runtime bridge reads it on submit, and Ortto receives the new list ID. Existing journey enrollments in Ortto are not retroactively moved; the change is forward-only, which is usually what marketers want.

Yes. Ortto kept the same WP-side data shape across the rebrand, only changing branding strings. SleekView reads the current option keys and falls back to legacy autopilot_* keys on older installs that have not been re-saved since the rename. Both shapes appear in the same table without a manual migration step.

Tracking events stream straight to Ortto's cloud through the capture script; they are not queued in WordPress. To audit those, use Ortto's own activity log. SleekView's scope ends at "is the capture script enabled, what consent string fired, and which forms post to which lists."

SleekView shows whether the token is set and its last-rotation timestamp without revealing the secret value. The presence/absence column is the audit signal; the value itself stays masked unless an admin opts into showing it. This keeps screenshots of the audit safe to share with a client.

It does. Filtering for any row whose stored data still uses the legacy autopilot_* keys produces a list of options or postmeta values that have not been touched since the rename. Re-saving each one updates them to the current keys, which is useful before turning off legacy fallback in a future plugin version.