CleanTalk Pro keeps a tidy local schema. The SpamFireWall layer writes every block to wp_cleantalk_sfw_logs with the IP, the country, the rule code, and the timestamp. Local rule snapshots live in wp_cleantalk_sfw, and session tracking sits in wp_cleantalk_sessions. The cloud side owns the global rule set, but the rows that actually fire on this site live on this site.

SleekView reads the three tables as joined grids. Each SFW log row exposes IP, country, rule, action, and request path; sessions expose the user, the IP, and the last activity; the local SFW snapshot lets you see the rules that were active at the moment of the block. Saved views capture filters, columns, and sort, so weekly firewall reviews stop being a rebuild.

Annotation and triage state stay in SleekView so they survive the next CleanTalk sync. Releasing an IP routes through the plugin's own action API, leaving the cloud and the local list consistent. The plugin keeps doing the work it is good at; SleekView gives the people running the site a view that finally fits how their investigations actually run.

CleanTalk's value comes from a cloud-backed rule set, but the rows that fire on any given site are local. The SFW writes every block to wp_cleantalk_sfw_logs, every rule snapshot to wp_cleantalk_sfw, every session to wp_cleantalk_sessions, and those tables are where on-site investigation has to happen. The cloud dashboard is great for global stats; it is poor at answering site-specific questions like which rule fired most this week on this domain or which IP keeps testing the same form.

Site admins, agency operators, and security teams need a local grid that exposes those rows with the right columns, lets them pin saved views, and supports inline triage that routes back through CleanTalk's own APIs. Treating the local CleanTalk schema as a grid closes that gap without competing with the cloud. The global rule set still keeps every site safer; the per-site grid finally makes the work visible to the people actually responsible for the site.