User Switching (by John Blackbourn) lets administrators temporarily switch into any user account, with the original session preserved in a signed cookie. A Pro variant adds an audit trail that records every switch event: originating admin, target user, timestamp, IP address, and the active session afterwards. Depending on the build, that audit data lives in a dedicated table such as wp_user_switching_log or in an option key under user_switching_pro_log.

SleekView reads whichever store the Pro build uses and renders the audit trail as a grid. Originating admin, target user, switch time, IP address, user agent, and switched-back-at timestamp become first-class sortable columns. Filters scope the grid to switches in the last 24 hours, switches by a specific admin, switches into high-privilege accounts, or sessions that have not been switched back from yet.

The plugin itself does not require an audit trail to function; the switch mechanism is cookie-based and works without writes to the log. SleekView surfaces whatever Pro persists, and where the audit feature is not enabled, the grid will explain that the log table is empty rather than invent rows. For sites that do enable Pro, the result is the audit surface that compliance reviews ask for.

Letting an admin switch into another user's account is one of the most useful tools an operator has, and one of the easiest features for a security review to be uncomfortable with. The original User Switching plugin made the mechanism safe by preserving the originating session in a signed cookie and giving every switch a clean switch-back path. The Pro audit feature closes the loop by persisting every event.

The thing the Pro UI does not give you is a queryable workspace for that log. Compliance officers do not want a flat scroll, they want a saved view filtered to switches into administrator roles in the last 30 days, exported as CSV, with originating admin and IP visible. Support team leads do not want a chronological list, they want this week's switches grouped by admin to spot training patterns.

Security leads want to see open (unclosed) switches at a glance so a forgotten support session does not sit live overnight. A grid built on the same audit data the plugin already writes turns each of those questions into a saved view. The plugin still owns the mechanism.

The grid is the audit surface that everyone reviewing the mechanism actually needs.