Yes. Moving a card calls the same BuddyBoss App helpers the admin log screens use, including the retry helper for failed pushes and the mark-as-sent helper for queued items. Notifications, log counts, and any custom hooks listening to BuddyBoss App push events continue to fire as before.

SleekView reads the BuddyBoss App push log table, the BuddyPress activity table, the notifications table, and any in-app report meta added by BuddyBoss App. You pick the source per board, choose the status field to group by, and SleekView renders one card per row with the fields you select.

Yes. SleekView ships with role-based permissions, so app admins can have a single page that holds the BuddyBoss App board and nothing else. Only chosen roles can drag cards, and destination columns can also be limited per role for safer review work during a busy launch or campaign week.

Custom statuses appear automatically because SleekView reads distinct values from the chosen log column. You can rename column headers, pick colors, and decide whether admins can drag cards between any two columns or only along an approved retry path that matches the push provider rules.

Each board has one source so the rules stay clear, but most teams run two boards side by side, one for push delivery and one for in-app moderation, linked from the same dashboard. Column counts at the top of each board show waiting work at a glance during a launch.

Dragging never deletes data. It changes the state field SleekView is grouping by, which matches what the admin screens do. Retries write a new attempt row through the standard helper, so the original log entry is preserved as part of the audit trail for the launch and the campaign.

Yes. Each card can show the time since the log row was created or last updated, so a failed push that has been sitting for hours looks visibly different from a fresh one. Sort options can also place the oldest cards at the top of every column so stale retries never silently drift out of view.

No. SleekView pages the board, only loads cards for visible columns, and uses indexed queries on the push log table for the status filter. Large apps with millions of log rows stay responsive because heavy fields are only fetched for cards currently on screen during a triage session.