SleekView reads the entry tables directly — gf_entry, gf_entry_meta, and gf_entry_notes. Any add-on storing values in gf_entry_meta (Stripe, PayPal, Mailchimp, ActiveCampaign, Salesforce) is automatically visible because their data lives as meta keys on the entry. The pivot picks them up without per-add-on configuration; you choose which keys to surface as columns.

Yes. SleekView writes back through Gravity's CRUD APIs where the field type supports it (text, email, number, select, checkbox, date), respecting validation rules. For field types Gravity doesn't fully expose programmatically, SleekView falls back to direct table updates with conflict detection — it warns if the entry changed since you opened the row.

SleekView reads the unique meta_key values for entries in your selected form (or across forms) and exposes each as an addable column. The pivot runs at query time using a join, not a one-time export, so newly added fields appear immediately. For huge entry tables you can scope the meta-key discovery to a recent date range to keep the column-chooser responsive.

Yes — that's a primary reason teams switch. Add form_id as a column and either filter on a specific subset of forms or leave it open to see everything. For cross-form views, only meta keys shared across forms become useful columns; SleekView indicates which keys belong to which form so column choices stay sensible.

Yes. gf_entry_notes is supported as a related table — show note count as a column, expand a row to read the note thread inline, or build a notes-only view filtered by user or date for moderation. Notes aren't pivoted into the main entry table because they're one-to-many; they're addressed as a related view.

Checkbox-type fields store one row per selected option in gf_entry_meta with a non-null item_index. SleekView aggregates them into a single readable cell with the selected option labels concatenated. Filters on these fields treat each selection as a value, so "contains Newsletter" works as expected without scripting.

When SleekView routes through Gravity's entry-update API, the gform_after_update_entry action fires per row, which is what feed processors hook into. Whether a specific feed re-fires depends on its own conditional logic — most feeds are configured to run on entry creation only, so an update won't re-trigger them. Test with one row before bulk-applying.

Partial entries are stored in gf_draft_submissions, separate from gf_entry. SleekView can expose that table as its own view to audit incomplete submissions, see which forms get abandoned at which step, or clean up old drafts. The pivot logic doesn't apply because partials store the whole form state as a serialised blob, but per-form abandonment metrics are still easy.