Yes. Moving a card calls update_post_meta for the lifecycle key on the graphql_document post, the same function the editor uses on save. The standard WPGraphQL save hooks and any custom code listening to the standard WordPress hooks continue to fire without any extra plugin glue.

SleekView reads the graphql_document post type through standard WP_Query and post meta, which is where WPGraphQL stores persisted queries. You pick the source, choose a lifecycle meta key to group by, and SleekView renders one card per persisted query with the fields you select.

Yes. SleekView ships with role-based permissions, so API leads can have a single page that holds the schema review board and nothing else. Only chosen roles can drag cards, and destination columns can be limited per role so contributors cannot move queries into Active without approval.

Derived states are first-class in SleekView. You can define a workflow_state computed from several fields, such as treating a persisted query as Retired when a sunset flag is true and the post_status is still publish, and SleekView groups queries by that derived value across columns.

Each board has one source so the rules stay clear, but most setups run one board for graphql_document persisted queries and a second board for any WPGraphQL custom CPT on the same dashboard. Column counts at the top of each show waiting work at a glance for the team.

Dragging never deletes data. It calls update_post_meta for the lifecycle key on the graphql_document post, which is the same thing a save in the editor does. Other post meta, the post content with the query body, and the query hash are not touched, so all fields remain as saved.

Yes. Each card can show the time since the persisted query was last modified or since the lifecycle key was last updated, so a query stuck in Draft for a quarter looks visibly different from a fresh one. Sort options can place the oldest cards at the top of every column for stale work.

No. SleekView pages the board, only loads cards for visible columns, and uses indexed queries on the wp_posts table and the post meta key. Sites with hundreds of WPGraphQL persisted queries stay responsive because heavy query bodies are only fetched for cards on screen.