Gravity Forms User Registration extends regular Gravity entries with a registration feed. Each submission lands as a row in gf_entry with its values rolled out across gf_entry_meta. The add-on writes an activation record to gf_addon_feed_activations when double opt-in is enabled, and on activation it creates a row in wp_users linked back to the entry by ID.

The default admin lists entries per form and the add-on shows a pending-activations screen on a different tab. Membership ops who want to see a contact's submission, activation token, registered role and current user status together get three screens and a notepad.

SleekView reads gf_entry directly, joins gf_addon_feed_activations for the token and activation timestamp, and joins wp_users for the assigned role. One row per signup, with columns for name, email, activation status, role and date, sortable on any of them. Bulk activations, role changes and resend actions route through the add-on's API where supported, so notifications and hooks still fire.

User Registration extends Gravity Forms with a thin but critical piece: turning a submission into a WordPress user with the right role. The reading surface around it is split across three places, gf_entry for the submission, gf_addon_feed_activations for the token, wp_users for the resulting account. Membership ops who want to clean stalled signups, audit roles or report on the funnel ends up jumping between tabs and copying IDs.

SleekView reads all three tables through the joins User Registration already implies and renders one row per signup with submission, activation state, role and source on the same line. Inline edits route through the add-on's API so notifications still fire and the feed picks up role changes. The pending-activations screen stays where it is for the per-contact details that suit it.

The list operations that hurt at scale move to a place built for rows.