No. SleekView reads from the Z Form Pro submission storage with scoped, cached queries. Each upvote increments the mapped number field on the same submission row through the Z Form Pro update path, so the admin entry view, integrations, and public board always agree on every count.

Yes. Any submission whose status field matches your hide list (default: Spam, Pending, Trash) is filtered out of the public board but stays visible in Z Form Pro admin. You can also add a custom submission meta key as an explicit hide flag for one-off exclusions controlled by hand for any entry.

Votes live on a hidden number field on the submission. Deleting the submission removes the votes along with it. For soft delete, set the submission status to Archived and add Archived to the SleekView hide list. The row stays in the database with its vote count preserved fully intact.

Yes. SleekView never touches the Z Form Pro action engine. You change submission status in admin the same way you always have, and any configured email, CRM sync, Zapier action, or webhook fires on that change. The public pill color updates on the next page load based on your color mapping.

Yes. Payment fields write a payment status to the submission, which you can map to a dedicated pill or use to filter the board. You might surface only Paid submissions on the public board, or color pills by payment state. SleekView reads whatever is on the submission, including payment metadata.

Add a hidden number field with a default value of zero. SleekView writes upvote increments to that field on every submission. Existing submissions start at zero and rise as votes come in. A short WP-CLI command can backfill older submissions with a starting count to seed initial activity.

No. Conditional logic and calculations run during submission. By the time the row is saved, only resolved values exist on the submission. SleekView reads those. If a mapped field was hidden by conditional logic on a given submission, the card simply omits the pill or value for that field.

Yes. Multi-page forms gather data across multiple steps but persist a single submission row at the end. SleekView reads that final submission row the same way it reads any single-page form submission. The multi-page navigation, validation, and save-resume logic all keep running unchanged on the form side.