SleekView Kanban for Toolset Types
SleekView Kanban reads any Toolset select field on a custom post type and renders one card per post, grouped into columns by the value you pick. Dragging a card writes the new value through the Toolset API so Views and Access conditions stay in sync.
♾️ Lifetime License available
Why Toolset custom posts need a board
Toolset Types defines custom post types and stores their fields in wp_postmeta under the wpcf- prefix. The default WordPress edit screen lists those posts in a vertical table with no grouping by a Toolset select like wpcf-project_stage or wpcf-ticket_status. Teams that build whole applications on Toolset end up reading status one record at a time.
SleekView Kanban hooks into the Toolset Types API to read field definitions. Any select field on the post type can become the grouping axis, and its registered options become the four columns on the board. Cards show the post title, the featured image, and any other Toolset fields you drop into the card layout, including single image, numeric, date, and email fields.
Dragging a card updates the post meta through Toolset filters, so Views queries that depend on the field re-render correctly and Toolset Access role checks continue to gate writes. If a user lacks the capability that Access requires for the post type, the board loads in read only mode and the drag handles disappear.
Workflow
From Toolset post type to live board in four steps
Connect to a Toolset post type
Pick the status column to group by
Choose what shows on each card
Enable drag and drop writes
Sample board
Sample Toolset ticket board
Comparison
Default Toolset admin versus SleekView Kanban
Default Toolset post list
- Posts list as a flat WP_List_Table with no Toolset field grouping
- Status reads require opening the post editor for each record
- Bulk edit cannot reach Toolset select or radio options
- No drag interaction, no visual signal of where work stalls
- Moving ten tickets through stages means ten reload cycles
SleekView Kanban
- Reads Toolset field definitions through the official Types API
- Cards display image, date, email, and URL Toolset fields natively
- Drag fires update_post_meta and Toolset save hooks together
- Honors Toolset Access role rules for read and write per post type
- Falls back to read only when the user lacks the required Access role
Features
What SleekView Kanban gives you for Toolset Types
Native Toolset field support
Card layouts pull values through the same Toolset Types API your Views and Forms already use. There is no extra mapping table, no shadow registry of fields, and renames in the Toolset editor propagate to the board on next reload.
Toolset Access aware
If Toolset Access restricts editing the post type to a custom role, the board respects the same rule. Users in that role see drag handles and can move cards. Other users see the same board layout but with the drag handles hidden and writes disabled.
Server side filters
Filter cards by any Toolset field through a filter bar that runs WP_Meta_Query on the server. Numeric range filters use the BETWEEN operator, date filters use timestamp comparisons, and text filters fall back to LIKE with leading wildcard control.
Audience
Three Toolset stacks that need a board
Internal ticket queues
A Tickets post type with a wpcf-ticket-status select renders as a triage board. Reporters file tickets through Toolset Forms, support staff drag them across columns, and Toolset Views generate per-status archives on the public site.
Editorial calendars
Article post types with a Toolset workflow status field become a publishing pipeline. Drafts move to review, review moves to scheduled, and Toolset Access keeps junior authors from skipping straight to published.
Internal directories
Toolset directory builds for staff, equipment, or contracts get a status board. Group by a custom availability field and team members can drag rows from booked to free without learning a new admin interface.
The bigger picture
Why Toolset apps need a real reporting view
Toolset Types is a builder for full WordPress applications, not just content sites. Once a team commits to Toolset they tend to model real business processes inside it. Tickets, contracts, projects, courses, properties, and inventory all end up as custom post types with workflow fields.
The default admin works for one record at a time, and Toolset Views handles the public facing rendering, but neither of them gives operators a grouped overview of work in flight. A kanban board fills that exact gap. The status field stays in Toolset, the data stays in wp_postmeta, and Toolset Access keeps gating writes.
The board is a second window onto the same data, optimized for moving records through stages rather than authoring them. Teams that adopt it usually find that they were writing custom plugins to recreate exactly this view, and that the maintenance cost of those plugins disappears once a generic kanban view replaces them.
Questions
Common questions about SleekView Kanban for Toolset Types
It works with both. The integration uses the Toolset Types API that ships in the free plugin. Toolset Access is optional, and the board respects its rules when installed. Toolset Views is not required for the board to work, but the two views can sit side by side on the same data.
Select, radio, and checkbox single value fields are eligible. Multi select checkboxes are not, because a single post could land in multiple columns at once. The board reads choices through the official Types API so column labels match exactly what you set in the field editor.
Yes. The plugin runs the same capability check Toolset Access enforces on the post editor. Users who can edit the post type see drag handles and full board state. Users who cannot see a read only board with a tooltip explaining the missing role.
It does not change them. Toolset Views continues to read wp_postmeta the same way it always has. Card moves write the new value through update_post_meta, so any Views query that filters by the status field updates on next request like a manual save would.
Repeating fields render the first row by default, and you can pick a different row by index. Grouping by a value inside a repeater is not supported because a single post may have many rows with different status values, which would put the same card in several columns.
Post relationships are unaffected. Dragging only writes the value of the grouping field. Parent and child relationships defined in Toolset Types stay in place and any conditional logic that depends on them continues to work without changes.
By default the board reads only published posts, matching the default Toolset Views behavior. You can include any combination of published, draft, pending, and private states with a per board toggle. Trashed posts are excluded and cannot be added back through the board.
Columns stream cards lazily, so the practical limit is whatever Toolset can return per WP_Query call. In production we see boards stay responsive into the hundreds of thousands of posts as long as the status meta key has an index on its meta_value column.
Pricing
More than 1000+
happy customers
Explore our flexible licensing options tailored to your needs. Upgrade your license anytime to access more features, or opt for a lifetime license for ongoing value, including lifetime updates and lifetime support. Our hassle-free upgrade process ensures that our platform can grow with you, starting from whichever plan you choose.
Lifetime ♾️
Most popular
EUR
once
- Unlimited websites
- Lifetime updates
- Lifetime support
...or get the Bundle Deal
and save €250 🎁
The Bundle (unlimited sites)
Pay once, own it forever
Elevate your WordPress site with our exclusive plugin bundle that includes all of our premium plugins in one package. Enjoy lifetime updates and lifetime support. Save significantly compared to buying plugins individually.
What’s included
-
SleekAI
-
SleekByte
-
SleekMotion
-
SleekPixel
-
SleekRank
-
SleekView
€749
Continue to checkout