No, it routes through it. Approval and denial trigger the plugin's existing approval hooks and any email notifications you have configured, just from a table-style UI instead of a per-user detail screen. The actual state lives where it always did, in wp_user_registration_users plus wp_usermeta.

Yes. Profile field changes update the relevant wp_usermeta rows. SleekView uses update_user_meta so all standard filters and actions run, and adds conflict detection so a stale edit will not silently overwrite a change made elsewhere.

SleekView reads the form definition to know which field labels map to which wp_usermeta keys (User Registration writes field values using the field's meta key configured in the form builder). Each known key becomes an addable column, with the pivot running at query time so new fields surface as you add them.

Yes. user_registration_users stores form_id per member, so add it as a column and either filter on a subset of forms or leave it open for a unified directory. Shared field meta keys become useful cross-form columns; per-form-unique keys are still available when you filter to that form.

Yes for the membership and content-protection add-ons that write to wp_usermeta. Membership level, expiration, and access flags become pivotable columns alongside the registration fields. For add-ons that write to their own tables, SleekView can read those tables as joinable sources too.

Yes. Save views and scope them per WordPress role or capability. Membership managers see the pending queue, moderators see suspicious-signup filters, vendor onboarding sees the vendor-form queue with vendor-specific columns.

Filter to one email address and you have a single row covering everything User Registration stored about that person. Export it to CSV for a data-access request; bulk-delete to honor an erasure request through the plugin's deletion hooks plus WordPress' wp_delete_user API.

Yes, when those signups route through a User Registration form. The plugin records form_id and stores the relevant identity meta in wp_usermeta, both of which surface in SleekView. Social-only signups that bypass the plugin entirely will not appear because they are not in user_registration_users.