GravityView extends Gravity Forms with public-facing views that publish entries to the front end, gated by an approval column. The approval state lives in gf_entry_meta under the is_approved key, with values typically 1 for Approved, 2 for Disapproved, 3 for Unapproved, and spam handled via the standard status column on gf_entry. Reviewers normally moderate through GravityView's Approve / Disapprove buttons on each entry row.

SleekView Kanban turns that into a board. Group by is_approved and the board renders Unapproved, Approved, and Disapproved columns side by side, with a Spam column drawn from gf_entry.status. Cards show submitter name pulled from form meta, the form name, the date added, and any review-relevant fields (a rating, a category) the team chooses to pin.

Dragging a card calls GravityView_Entry_Approval::update_approved(), the same API the front-end and back-end approval buttons use. Hooks for approval change fire as usual, so any view that filters on approval refreshes automatically, and notifications tied to approval status dispatch as they would from the entries screen.

GravityView is built around publishing form entries on the front end, which means moderation is a real workflow rather than a one-off cleanup. The default approval interface (buttons on each row, filter tabs at the top) is fine for an admin handling one entry at a time. A real moderation team needs to see the queue: how many submissions are unapproved, who has the workload, how many disapprovals share the same reason.

SleekView Kanban turns the is_approved meta into columns, the rest of the entry into card content, and the standard approval API into the drag handler. The plugin keeps owning publishing, the front-end view keeps refreshing on approval, and the moderation team finally has a board that matches the work. Contest moderation, recipe approval, story submissions: all become a queue with state, context, and bulk action in one surface.