[object Object]

A project manager asks for an editable grid on the Project form so the team can update task status without opening each row. You ship it. Two weeks later the validation rule that blocks completion without a timesheet stops firing, and a field service plugin that fired on column change is silently skipped. The editable grid is convenient, but it does not behave like a form, and that gap eats projects.

What Each Grid Actually Does

A standard sub-grid is a read-only view that opens records in the parent form context. Every row click triggers a full form load with all OnLoad scripts, business rules, plugin pre-images, and security checks. An editable grid renders an inline editing surface that issues a direct update to the Web API when a cell loses focus.

The editable grid does fire OnSave and OnChange events on the grid scope, but it does not run form-level business rules. It does not load Quick View Forms. It does not respect form-specific JavaScript libraries. It is a leaner pipeline by design.

The Decision Matrix

Use a standard sub-grid when:
- Rows have business rules that gate field visibility
- A plugin needs the full pre-image and post-image
- The user needs context from related records
- Volume per parent stays under 250 rows

Use an editable grid when:
- The data shape is flat and tabular
- Fields are simple text, number, optionset, or two-option
- No conditional logic depends on form state
- The user needs to update many rows in one sitting

What Breaks Silently

When you flip a sub-grid to editable, three things stop working without warning. Form-level OnLoad scripts that hide columns conditionally will not run. Calculated fields that depend on related records will display the cached value from the last server save. Lookup filters defined on the form will fall back to the lookup view default, which is rarely what you want.

This is why a good rule is to never enable an editable grid without explicit testing of every business rule that touches that table.

Wiring Events on Editable Grids

The editable grid exposes a small but useful event surface. Hook OnRecordSelect for row-scoped logic and OnSave for validation that must run before the Web API call.

function gridOnSave(executionContext) {
  const eventArgs = executionContext.getEventArgs();
  const formContext = executionContext.getFormContext();
  const status = formContext.getAttribute("statuscode").getValue();
  if (status === 100000003 && !formContext.getAttribute("approvedby").getValue()) {
    eventArgs.preventDefault();
    Xrm.Navigation.openAlertDialog({ text: "Approval required before completion." });
  }
}

Register this as the OnSave handler of the sub-grid in the form designer, not on the parent form, or it will never fire.

Performance at Volume

Editable grids stream rows through the Web API in chunks of 50 by default. A grid showing 500 task rows will issue ten retrieves before paint, plus one update per cell change. Standard sub-grids share the same view caching that powers main grids and feel snappier on first paint.

If your users routinely scroll past row 250, switch to a standard sub-grid with paging or push them to a dedicated view page. The editable grid is not designed for bulk data entry at that scale.

Mobile Behavior Differs

The editable grid renders as read-only on the Field Service mobile app and on phone form factors. If your field technicians need to update rows on a tablet, test on the actual device before committing to the editable pattern. The fallback is a custom canvas page embedded in the model-driven app.

What to do this week

Audit every editable grid in your environment, list the business rules and plugins on the underlying table, and confirm each one still fires on inline edit. Convert the grids that fail back to standard sub-grids and document the choice on the form so the next request does not undo the fix.

[object Object]
Share