PublishPress Permissions Pro writes its core access data to wp_ppc_exceptions and wp_ppc_exception_items: each row is a scoped capability tied to a role or user, optionally bound to a specific post, term, or post type. The default Exceptions screen shows rows in a flat list and hides item type, target ID, and inheritance behind tabs, which makes a real access review extremely click-heavy.

SleekView reads both tables and joins to wp_posts for post titles, wp_terms for taxonomy labels, and wp_users for user display names. Role, agent type (role or user), item type, operation (read, edit, delete), and inheritance flag become filterable columns. Auditors filter to one role, scope to one post type, and see exactly which content gets the override.

Inline edits route through PublishPress Permissions's own CRUD helpers, so adding or revoking an exception fires the same hooks the default UI uses. Bulk revoke across a filtered selection is the missing piece for offboarding contractors or rotating access at the end of a project.

Access reviews are one of those tasks that sound simple and become impossible without the right surface. WordPress's role system was designed for blogs, and as soon as a site grows beyond a small editorial team, the per-content, per-user, per-capability exceptions explode. PublishPress Permissions Pro already stores all of that data in wp_ppc_exceptions and wp_ppc_exception_items, with foreign keys into posts, terms, and users.

The pieces are there. What was missing is a working surface where filters compose, sorts mean something, and saved views match the work a compliance reviewer or a site admin actually does. A real grid turns a quarterly access audit from a multi-day click-fest into an afternoon's work.

Offboarding becomes a single filter plus a bulk revoke. New content types become a per-type saved view that anyone on the team can pin. The data has been there all along.