No. It reads what Memberium has synced locally into WordPress user meta. The source of truth stays in ActiveCampaign and the AC API is never called from SleekView. That keeps the grid fast (no remote calls per row) and means it works whether your AC API is reachable or not. If a contact's local cache is stale, the last-sync column tells you exactly when it was last refreshed.

Inline edits go through Memberium's normal sync layer, so any tag change you make in the grid propagates to ActiveCampaign on Memberium's normal cycle. SleekView itself does not call AC; it just calls the same Memberium functions you would call from PHP. That means audit trails, AC automation triggers and any custom hooks you have wired into Memberium continue to fire.

Yes. Any custom field Memberium stores on the WordPress user — including custom contact fields you set up in AC and pull through the sync — can be promoted as a column. Each column is typed (string, number, datetime) so the right filter operators show up automatically. There is no upper limit on column count, though we recommend pinning the four or five most-used per saved view.

Yes. The same grid pattern works with Memberium for Keap and Memberium for HighLevel. The only difference is the field names — Keap has its own contact ID format, HighLevel its own tag schema. SleekView reads whichever Memberium variant is active and adapts column labels accordingly. Sites running multiple variants can show them in separate views or merged into one.

Yes. Per-role row scoping limits which users a given role can see in the grid (for example, support sees subscribers but not administrators). Column-level read-only flags lock down sensitive fields like AC contact ID or billing tags so support can update notes without accidentally breaking the sync. Both checks run on read and on save.

No. SleekView only loads on its own admin screens. Login, the user profile editor and the front-end of the site never trigger SleekView queries. The grid query runs once when an admin opens the view, with pagination and indexed columns to keep the response fast even on large member bases.

The tags column shows the first few values inline with a count chip for the rest, and a hover popover lists the full set. Filters work against the full array, not just the visible chips. For members with very long tag arrays — common on legacy sites that accumulated tags over years — the grid stays performant because filtering happens at the database level, not in the rendered cell.

Yes. Filter to the cohort you want — say active members with course-a but not course-b — and export the visible rows as CSV with the columns you have promoted. The export honors per-role row scoping and column-level masks so support exports do not leak data they were not meant to see in the grid.