No. SleekView reads gf_entry and gf_entry_meta directly, so any subset of Gravity Perks works. The column picker scans which meta keys exist in your entry data and exposes them, regardless of which perk wrote them. Add perks later and the new keys appear in the picker without re-configuration.

Gravity Perks Nested Forms stores the parent entry ID in a meta key on each child entry. SleekView surfaces that key as a regular column, so child entries show their parent ID inline and you can filter to a single parent to see all its children. Useful for application/reference workflows where multiple sub-forms attach to a master entry.

Yes. Populate Anything stamps the source object ID and type into gf_entry_meta when configured to do so. SleekView exposes those keys as columns and filters. The exact key names depend on how Populate Anything was configured in the form, so the column picker reads the actual data rather than assuming a fixed schema.

When SleekView updates entries through Gravity Forms' CRUD APIs, the standard Gravity hooks fire, including gform_after_update_entry, which Gravity Perks listens on for downstream effects (counter updates, conditional logic on save). Direct table edits skip hooks by design for back-fill scenarios where notifications or recalculations should not run.

Limit Submissions stores per-form and per-user counters in options or transients depending on the limit type. SleekView surfaces these where they're queryable, so you can audit which forms are near their cap before users hit a hard error. Counter resets still happen on the schedule the perk configures.

For values stored in gf_entry_meta, yes, direct edits go through Gravity's update-meta API where supported. Some perks compute values from other entry data on save, so manual edits to those fields can be overwritten on the next entry update. SleekView flags fields that look perk-managed in the column picker as a soft warning.

GP Easy Pass writes review tokens to entry meta when configured. SleekView exposes those keys as columns; for security you'd typically not want them on a list view, but they're visible on per-entry detail views where the reviewer context is appropriate. Tokens stay in the database; SleekView doesn't transform them.

The picker scopes meta-key discovery to the selected form (or recent entries when across forms) so it stays responsive even on installations with hundreds of forms and millions of meta rows. You can narrow further by date range. Newly added perk keys appear after the next entry is created against that perk.