It reads whatever source you point it at. There is no parallel feedback database. If your currency requests already live in a Gravity Forms entries table, a feedback CPT, or a custom comment type, SleekView reads that table live and writes upvotes back to the same column you mapped.

Yes. SleekView ships with a built-in submit form that writes a new row to whichever post type or table you configured as the source. The form respects your taxonomy for currency tags and uses the same status as the default for new submissions, so the card lands on the board in the correct state.

Tag those rows as Bug in your category column and SleekView renders them with the rose status color by default. Staff can change the status to Investigating, then Shipped once the provider is swapped or a manual override is added. Shoppers see the resolution in the same card thread.

It works with both. SleekView does not care which Aelia plugin generated the data row. You point it at whichever table holds the request, map the columns, and the board renders. Tax-display complaints and currency-switcher requests can live on the same board with different category tags.

Yes. SleekView honors WordPress capabilities and accepts a region attribute on the shortcode. Combine it with the Aelia geolocation API and shoppers in the EU see EUR-related requests by default, while shoppers in Asia see APAC currencies first. Filters above the board let them switch.

SleekView surfaces a similar-cards suggestion when a shopper starts typing in the submit form. If the duplicate slips through, staff can merge two cards in the admin and the vote counts add up. The merged card keeps the earlier date so the chronological audit trail stays intact.

Both modes work. Logged-in mode prevents duplicate votes per account and surfaces vote-by-name in the admin. Guest mode rate-limits by IP and cookie, which is the right default for currency stores that want broad participation without forcing account creation to upvote a currency.

No. SleekView paginates server-side and caches the rendered board per filter combination. On stores with 10k+ request rows the initial page loads under 300ms because only the visible page worth of cards gets hydrated. Filtering by currency uses an indexed query on the meta key you mapped.