Skip to content
Gravity Tables
editing

How to add inline editing to Gravity Forms entries

Step-by-step guide to enabling click-to-edit cells on a Gravity Tables view, with validation, role gates, audit trail, and the gotchas that come up in production.

· 5 min read · By Fahd Murtaza

Inline editing is the most-requested feature in Gravity Tables history, and also the easiest to misconfigure. This guide covers the entire pattern: turning it on, scoping it correctly, and the production-grade configuration most teams converge on.

The one-line version#

[gravity_table id="42" allow_edit="true"]

That makes every cell editable for any user who can already view the table. Useful for prototypes, dangerous for production. Read on for the configuration you actually want to ship.

Per-column editing, the right default#

Most tables shouldn’t let users edit every column. Common pattern:

[gravity_table id="customers" allow_edit="phone,email,shipping_address"]

Now only those three columns are editable. Every other column renders read-only.

The values in allow_edit can be:

  • Field labels (lowercase, hyphen-separated): allow_edit="phone-number,company-name"
  • Field IDs: allow_edit="3,7,12"
  • Field admin labels (if set): allow_edit="cust_phone,cust_email"

Mix and match freely, Gravity Tables resolves each token against the form’s field map.

Validation respects your form#

Inline edits run through Gravity Forms’ standard validation pipeline. If a field has:

  • Required validation → empty edits are rejected
  • Type validation (email, URL, phone) → invalid formats are rejected
  • Conditional logic → edits respecting the conditions are accepted; edits that violate them are rejected
  • Custom validation hooks (gform_field_validation) → those fire too

Rejected edits show a tooltip with the same message the original form would show, then revert the cell.

Role gates per column#

In production, different roles need different edit permissions:

[gravity_table id="orders" edit_permissions="status:order-manager,priority:order-manager,notes:any"]

Now:

  • The status and priority columns are editable only by users with the order-manager capability
  • The notes column is editable by anyone who can view the table
  • Every other column is read-only

Server-side enforcement: if a customer role user POSTs an edit to the status field, the AJAX handler returns a 403. The client UI also won’t render those cells as editable for them.

Audit trail#

For compliance-heavy use cases (healthcare, finance), enable the audit log:

[gravity_table id="patient-intake" allow_edit="status,notes" audit_log="true"]

Every edit logs:

  • entry_id, which entry was edited
  • field_id, which field
  • old_value, new_value
  • user_id, user_login
  • timestamp (UTC)
  • ip_address
  • user_agent

The log lives in a separate wp_gt_audit table (created on first audit-enabled save). Export via:

Tables → System → Audit log → Export CSV

Or programmatically via the REST API at /wp-json/gt/v1/audit?table_id=42.

The “click to edit” UX#

When allow_edit is on, hovering an editable cell shows a subtle tooltip (“Click to edit”) and a faint outline. Clicking the cell:

  1. Replaces the rendered value with an input control matching the GF field type:
    • Single line text → <input type="text">
    • Email → <input type="email">
    • Phone → <input type="tel">
    • Dropdown / select → <select>
    • Checkbox / radio → matching native control
    • Date → date picker
    • Textarea → expanding textarea
  2. Pre-fills with the current value
  3. Auto-focuses
  4. Saves on blur or Enter, cancels on Escape

The cell briefly flashes green on success, red on validation failure.

Auto-recalculation of dependent fields#

If your form has Calculation or Total fields, they recalculate when their dependencies change:

[gravity_table id="invoices" allow_edit="quantity,unit_price"]

Edit quantity from 5 to 10, and any Calculation field referencing quantity * unit_price will refresh without a page reload. The new derived value writes back to the entry meta, and the table re-renders the affected row in place.

This is one of the bigger UX wins shipped in v4.1.7.

Combined with totals row#

The v4.1.8 totals row sums numeric columns at the bottom of the table. When inline edits land:

  1. The cell’s new value commits
  2. Calculation/Total fields recalculate (per 4.1.7)
  3. The totals row recalculates against the visible-row set

Net effect: edit a quantity, watch the cascade, line total → row recalc → footer totals, all in real time.

The gotchas#

Inline editing on a filter-active table#

If a filter narrows the table to “Active customers in February” and a user edits a customer’s status from “Active” to “Cancelled”, the row would disappear from the filter. Gravity Tables handles this:

  • The edit commits
  • The row briefly shows a “moved out of view” toast
  • A 1-second delay before fading the row out (giving the user a chance to undo)

Configure the delay via edit_disappear_delay="3000" (milliseconds) if 1s feels too fast.

Long values in narrow columns#

By default, an editing input is the column width. For long text values, that’s often too narrow. Use:

[gravity_table id="..." edit_input_min_width="280px"]

Or for textareas:

[gravity_table id="..." edit_textarea_rows="4"]

Mobile editing#

On mobile (≤480px) the table renders as cards. Inline editing on cards taps to expand the field into a full-width inline form, then collapses back. Same validation, same audit log, more screen space.

If your form has long-form fields (descriptions, notes), the mobile card mode is significantly more usable than trying to edit a tiny cell.

A complete production shortcode#

Here’s what most production deployments end up with:

[gravity_table id="customer-orders"
  filter_by_user="true"
  allow_edit="shipping_address,phone,delivery_notes"
  edit_permissions="status:order-manager,priority:order-manager"
  audit_log="true"
  export="csv,pdf"
  allowed_roles="customer,administrator,order-manager"]

What it does:

  • Each customer sees their own orders (per-user filtering guide)
  • Customers can edit shipping address, phone, and delivery notes, but not status or priority
  • Order managers can edit status and priority
  • Every edit is logged for compliance
  • Customers can export their own data
  • Guests see nothing

That’s a customer portal. Two shortcodes if you want a separate admin view. Zero custom PHP.

What this replaces#

Before inline editing in Gravity Tables, the standard pattern was:

  1. Build a frontend form that pre-populated with the entry’s current values (via gform_field_value_* filters)
  2. Wire it to update the original entry on submit (gform_after_submission + GFAPI::update_entry)
  3. Add custom validation
  4. Add custom role checks
  5. Style it to match your theme
  6. Repeat for every editable field configuration

Each of those was a half-day of work. allow_edit="..." collapses all of it into a parameter.