No. SleekView reads the outcome of webhooks that Ninja Forms (or your Zapier-equivalent add-on) already fired. It's the visibility and audit layer. To replay a failed trigger, use Zapier's own dashboard or the add-on's retry mechanism if it provides one. SleekView's job is identifying which rows need that treatment.

Anything that writes trigger metadata to postmeta on the nf_sub post. That covers Ninja Forms' first-party Zapier integration, third-party webhook actions configured to log status, and bespoke custom-code actions that follow the same convention. The column picker reads the meta keys that are actually present.

Polling triggers don't run through the add-on, Zapier polls the site on its own schedule. There's no per-submission status to read on the WordPress side because the submission was already saved before Zapier saw it. Polling triggers should be audited from Zapier's own task history, not via SleekView.

If the add-on writes the payload to postmeta (some do, in _zapier_payload or similar), SleekView will surface it as a column. For privacy reasons many add-ons deliberately don't store the full payload, only the status. Where the payload is present, SleekView's expandable cell view shows the JSON without overflowing the table layout.

Latency varies: webhooks fire near-instantly when configured async, slightly slower when synchronous. SleekView reads whatever is in postmeta at query time, so a queued or pending row reflects the actual state. Refresh the view to pick up the latest status. This matches the default admin's behaviour, just exposed in a list format.

Yes, _zapier_webhook_url is a regular filterable meta column. Grouping by URL gives a per-Zap volume and failure rate view: which Zaps are running hot, which are dormant, which are failing repeatedly and need attention. Useful when a Zapier account hosts many integrations and the WordPress side is the source of truth for what's wired.

Yes, conceptually. Any webhook action that writes status to postmeta on nf_sub can be surfaced the same way. The column picker doesn't care about the destination service. If you're using a custom webhook plugin, ensure it writes a status meta key on success and failure for SleekView to display.

It stays on the nf_sub post for as long as the submission exists, since it's just postmeta rows linked by post_id. Deleting the submission removes the meta. That makes the audit trail durable and matches the retention policy of the underlying submissions, no separate cleanup needed.