No. Role changes route through wp_update_user() and capability-aware setters; password resets are deliberately not exposed (use the standard WP password-reset flow for those). Direct writes to wp_users and wp_usermeta are limited to non-sensitive fields, with conflict detection on save to flag mid-edit changes from elsewhere.

WPForms User Registration sends activation emails via its own logic; SleekView doesn't intercept. To resend an activation, use the add-on's resend mechanism (a hook or admin action) or update the user's activation flag directly when manually verifying a signup. The inline edit logs the change.

Yes. WPForms User Registration writes mapped meta to wp_usermeta with custom keys. SleekView's column picker reads which usermeta keys are populated for users who came from this form and surfaces them. Add-ons or custom code that write extra usermeta become available columns without configuration changes.

If signups are configured to use the customer role and the add-on writes the standard Woo customer meta, those keys (billing/shipping address, etc.) become available columns. The cross-join to WooCommerce orders happens via customer_id on the wc_orders table (HPOS) or wp_postmeta on the shop_order CPT; both are addressable as separate SleekView sources.

Yes. Filter to signups where the user account exists but the activation meta is empty, and bulk-update the activation flag. The update goes through the add-on's user-activation hook so subsequent welcome emails and integrations fire normally. Audit log records the bulk action and the operator.

WPForms User Registration's collision behaviour is configurable (block, update, or ignore). SleekView reads the resulting state: collisions blocked appear as entries without a user_id; collisions allowed appear as entries with the existing user_id mapped. The activation status column reflects whatever the add-on decided at submission time.

No. WPForms Lite doesn't store entries in the database (entries go to email only). WPForms User Registration is a Pro add-on and requires entry storage to function. SleekView depends on the same entry tables (wpforms_entries and related), so Pro is the minimum prerequisite.

wp_users and wp_usermeta are indexed on the right columns by core; wpforms_entries is indexed on its primary key. SleekView's join uses these indexes. Tested cleanly through hundreds of thousands of users. If wp_usermeta is unusually large, narrowing the SleekView source to specific meta keys (rather than all) keeps queries fast.