PublishPress Notifications writes a row per sent alert with the workflow name, recipient user, source post, channel (email, Slack and so on) and timestamp. SleekView reads each of those columns as a chart dimension or filter, so any combination is available without extra data collection.

The notifications log structure is the same in the free and Pro tiers, just with a wider set of channels and workflow conditions in Pro. SleekView reads the same table either way, so a free install gets the same Number, Pie, Bar and Area dashboards as a Pro install would.

Yes. The log carries the channel for each sent notification, so a Pie split across email, Slack and any other configured channel is one of the available cards. Useful for confirming a newly enabled Slack channel actually picks up its share of alerts.

Yes. Notifications join wp_posts for the source post, so adding a filter on post_type or category narrows the whole dashboard to that section. Newsrooms running separate desks each get their own notification view from one configuration.

No. SleekView only reads the existing notifications log; it does not sit on the send path. Reporting runs against the same rows the plugin already writes for its own audit screen, so there is no extra cost at delivery time.

Yes. Filter to a workflow name, group by sent_at with an Area or Line card and pick a Count aggregation. The trend is the fastest way to see whether a workflow is firing the expected number of times after a configuration change.

If the notifications log captures send status (success, failure, retry), yes. SleekView reads whatever columns the log writes, so a Bar of failures per channel becomes a card as soon as that data is captured by the plugin or by a small logging shim.

Yes. Any filtered set behind a chart card exports as CSV with the workflow, recipient, post and timestamp columns. Editorial and legal teams use this for retention audits or to brief a client on exactly which notifications were sent in a particular incident window.