JetFormBuilder Pro stores submissions in two tables: jet_fb_records for the parent submission and jet_fb_records_values for each field value, with payment status and gateway transaction IDs on the parent row. The default JetFormBuilder records screen lists submissions per form with a small set of columns and opens a modal to view field values, which makes cross-form review and bulk status changes slow on busy sites.

SleekView reads jet_fb_records and joins jet_fb_records_values on the fly so each form's fields become proper columns. Filter by status, payment state, gateway, or any field value. Sort by submission date or amount. Inline edit the record status and notes through JetFormBuilder's record API so action triggers tied to status changes fire normally, and post-creation actions stay connected to the right post.

Payment add-ons that JetFormBuilder Pro ships with (Stripe, PayPal, WooCommerce) write gateway IDs and amounts onto the same record row, so a single SleekView table can show form submissions next to their payment state without bouncing between two plugins. Saved views per role let support, finance, and content ops each open their own slice of the records, with column sets that match what they actually need.

JetFormBuilder Pro is built around a structured records table, which is a big improvement over plugins that pile everything into postmeta. The default records screen lists submissions per form with a few columns and a per-record modal, which works fine for low volume. Once the site is doing signups, payments, post-creation, or support intake, the per-form modal gets tiring.

Cross-form review involves jumping between screens. Payment status sits on the parent record but isn't easy to filter alongside form fields. Bulk status changes are awkward.

SleekView treats jet_fb_records and jet_fb_records_values like the structured tables they are. Every field becomes a column on demand, payment state filters next to form fields, post-creation submissions link to their wp_posts row, and status changes go back through JetFormBuilder's API so triggers keep firing. The records table stays the source of truth, and the admin view finally catches up to what JetFormBuilder Pro actually stores.