Only the WordPress-side data the Encharge plugin already writes: event rows from the local event log, form-to-flow mappings from wp_postmeta and settings from wp_options. Encharge people and flow definitions are not duplicated into WordPress.

No. Flows, people and segments stay in Encharge, which is exactly where lifecycle logic should run. SleekView surfaces the WordPress half of the bridge: which event was sent, by which form, to which flow and from which page.

Yes. The Encharge plugin writes bridge mappings to each form plugin's standard postmeta location, and SleekView reads all of them. A mixed-form site still produces one clean dataset with a source_plugin column for grouping.

Yes. Save a view scoped to flow_id and the table narrows to a single flow. The view can be shared with the lifecycle owner for that flow so they open straight into the right slice.

No. SleekView queries the option store and postmeta on read, never on write. Identify calls and form bridges continue to run through the Encharge plugin's runtime path with no added work, so visitor-facing latency stays unchanged.

Yes. The tracking-script enable flag is a boolean in the Encharge settings option. SleekView surfaces it as a column, which makes mismatches between staging and production visible on a multisite roll-up without leaving the table.

Some Encharge plugin versions disable the local event log by default. SleekView shows an empty state on the event rows in that case, and the mapping columns over wp_options and wp_postmeta keep rendering so the view stays useful for audit work.

Yes. Each saved view is scoped by WordPress capability. Lifecycle sees flow_id and event_name while ops sees the tracking-flag column, with each role saving its own filter presets on the Encharge dataset.