No. The board only renders thread metadata such as subject, reply count, recipient count, and pill values. Clicking through into the actual message view goes to the standard Ultimate Member endpoint, which enforces the same permission rules it always has, so private content never leaks to non-recipients.

Yes. The upvote column accepts any meta key on the thread, including a priority score that a moderation rule populates whenever certain words, attachments, or recipient patterns appear. Threads with higher scores rise to the top of the board on the next render.

Yes. SleekView queries threads through the standard Ultimate Member permission layer, which honors role-based access and recipient relationships. A moderator with site-wide capabilities sees all threads, while a role-scoped admin sees only threads they would normally read in the inbox.

Only if you wire it that way. The status pill writes to the meta key you mapped, which can trigger an existing Ultimate Member notification rule or a third-party automation. Sites that prefer silent status changes simply leave that meta key out of their notification rules.

The cache refreshes on configurable intervals and on direct invalidation events, so a deleted thread drops off on the next refresh. Recipient removals do not affect the thread row itself, only the per-recipient join, which means subject metadata stays visible while content access respects the new permission state.

Yes. The data source picker accepts a recipient role filter, so a Members board and a Mentors board can live on separate admin pages with separate sort columns and separate routing pills. Each board queries only the rows involving recipients of the targeted role.

No. SleekView paginates the underlying query, caches the sorted set, and uses indexed columns for the recipient join. A board with hundreds of thousands of thread rows renders at the same speed as a small board because the database does the work once and the cache covers subsequent page loads.

The board fails closed with a clear empty state because the messaging tables are no longer queryable. Reactivating the messaging extension restores the data immediately, and no SleekView reconfiguration is needed because the underlying table names and meta keys remain the same across activations.