It reads from a synced WordPress post type that your Front API sync layer writes to during normal use. SleekView itself is a WordPress data layer, so it queries WP posts and meta. That keeps the public board fast and avoids per request API calls. Sync cadence is controlled by your Front sync plugin and stays independent of SleekView.

Yes. The Feedback view inherits the same query filters as the SleekView Tables and Charts surfaces. You can restrict by Front tag, inbox, rule, or any custom meta. Most teams expose only Planned, In progress, and Shipped tags on the public board and keep raw inbox traffic hidden entirely behind admin only views all the time.

SleekView tracks upvotes per browser through a signed cookie and per user ID for logged in users. You can also require a WordPress account before voting if your customer base already has one available. Vote totals stay consistent across pageloads and devices for known users, with cookie based dedupe for anonymous voters.

Front analytics live inside the Front admin and stay private to your team. A separate roadmap tool is a different product with its own database and pricing. SleekView Feedback turns the threads you already tagged into a public board, so the conversation history, the tags, and the votes all live in the same WordPress database with no second product.

Yes. Any numeric meta key can act as the vote column, any tag or inbox field can be the status, and any tag or meta can be the category. The SleekView block exposes a dropdown for each role so you map the columns once through the block UI and never touch the underlying template to change which fields drive which pill.

By default upvotes update the synced meta silently to avoid notification spam in busy agent inboxes. You can opt in to firing a custom action on each upvote if you want agents to see live demand inside their workflow, or threshold it to alerts every fifty or one hundred votes for a calmer summary rhythm rather than per click pings.

Yes. SleekView lets you scope the query to one or many tags or inboxes, so you can run a board per product line, per language, or per routing rule. Each board is a separate block on a separate page, all reading from the same underlying synced conversation store with their own filter and field mapping values configured.

Because SleekView Feedback reads whatever query you point it at, you can swap the source from front_conversation to a different post type or table without rebuilding the board. The cards, badges, votes, and filters stay intact. You only re map the column roles in the block settings, and the public URL plus accumulated vote counts stay the same.