Yes. SleekView reads the AccessAlly request counter and the local tag mirror, both of which exist regardless of which CRM is connected. ActiveCampaign, Ontraport, Drip, Keap, ConvertKit, and the rest of the AccessAlly integrations all push tags through the same mirror, so the board renders the same way on every supported CRM.

They do. AccessAlly mirrors inbound CRM tags into the local accessally tables, and SleekView reads from those rows. A tag applied by an automation in ActiveCampaign or Keap shows up on the board on the next render and counts toward the sort order without any extra wiring on the CRM side or the WordPress side.

Yes. The data source picker lets you filter the underlying query by offering ID, tag value, member level meta, or any custom field stored on the request row. A single offering, a single member level, or a curated set of high-signal courses can each get a dedicated SleekView board on its own WordPress page.

Status pill changes update the AccessAlly request_status column and trigger any configured tag action, so the connected CRM picks up the change through the standard AccessAlly tag sync. The request body, vote total, and member identity stay untouched, so reverting is just another column edit followed by a tag rerun.

Rejected and expired rows drop off the board because SleekView queries only active rows by default. If you want a moderator view that includes rejected, expired, or pending rows, the query filter accepts a status array so operations can triage without exposing the rows to members reading from the public roadmap page.

No. SleekView paginates the underlying query, caches the sorted set per page slug, and only fetches the rows it needs for the current page. A board with over fifty thousand AccessAlly request rows serves in the same time as a board with five hundred because the database does the heavy lifting once and the cache covers every subsequent visitor.

Anonymous voting is off by default because the AccessAlly request counter expects a member ID. You can enable a SleekView session-based fallback that stores guest votes in its own table and merges them on login, useful for public roadmap pages where marketing wants prospective members to influence the upcoming course slate.

The board keeps rendering as long as the AccessAlly tables remain in the database. Deactivating Pro freezes the data at the last write, so the board still serves with stale counts until reactivation. Swapping the CRM keeps the local tag mirror intact, so existing votes and statuses stay correct on the next render.