SleekView sits alongside Views. Both read the same Formidable entries table, so a public-facing View and an internal kanban can share the same dataset. Views remain ideal for read-only directories and dashboards, while the kanban handles triage and workflow editing.

Yes. The board configuration accepts the same filter expressions a View uses, including field comparisons and date ranges. Mirroring keeps the board and the View in lockstep, so changes to one are easy to reflect in the other when the data definition evolves.

Because both read the same wp_frm_items rows, a status change written by the kanban appears in the View on the next reload or AJAX refresh. There is no separate cache layer in between, so the rendering stays consistent across the two interfaces.

Yes. Each drag is a small write keyed by the entry ID, so reviewers editing different cards never collide. If both grab the same card within a second, the later write wins and a toast warns the first reviewer that the card moved underneath them.

Yes. SleekView calls the Formidable permission check used by the entries screen for every move. Reviewers without that capability see the board and the cards but cannot drag, and the writeback API rejects unauthorised moves server side.

If the View is filtered to entries with a complete status, then yes, trashing through the kanban will remove the entry from that View. The record is not deleted, only soft-deleted to the trash status, so dragging the card back restores it in the View on the next reload.

Yes. Any categorical field on the Formidable form can be the grouping axis, like a dropdown for stage, a radio for priority, or a single-select for owner. SleekView reads the distinct values from wp_frm_item_metas and turns them into columns.

The board polls for new entries on a configurable interval and slides new cards into the matching status column without a full page reload. A manual refresh from the toolbar also forces an immediate update after a known submission event.