How To Allow Editing Of Multiple Records In Salesforce Lightning

How To Allow Editing Of Multiple Records In Salesforce Lightning

For most admins, the correct answer is to enable and govern Salesforce inline editing through list views and reports. For developers, the correct answer is usually an LWC data grid that saves a set of changed rows through UI API or Apex in user mode. Both approaches answer how to allow editing of multiple records in Salesforce Lightning, but they solve different problems.

Salesforce Help documents field editing on the report run page, and Salesforce Developer Docs document inline editing for lightning-datatable. Review the current Salesforce Help page before a production rollout because supported field types and report restrictions can change by release: Salesforce Help: Updating Multiple Report Fields Inline and Salesforce Developer Docs: Display Data in a Table with Inline Editing.

How to enable Salesforce inline editing in Lightning reports

Use reports when users need reporting filters, summaries, dashboard drill-downs, or cross-object visibility before editing records. This is often better than exporting records to a spreadsheet because users remain inside Salesforce and the save operation still goes through the platform security model.

Admin setup for report field editing

1. Go to Setup.
2. In Quick Find, open Reports and Dashboards Settings.
3. Enable the setting for report field editing, shown in Salesforce Help as Enable Field Editing on the report run page.
4. Open the report, run it, and turn on field editing from the report run page when needed.
5. Hover over a cell. A pencil indicates an editable cell; a lock or warning indicates that the field cannot be edited from that place.

The setting does not grant access by itself. The user still needs edit access to the record, edit permission on the object, editable field-level security, and a page layout/record type combination that allows editing. Validation rules, flows, triggers, duplicate rules, and required fields can still stop the save.

What fields are usually inline editable in reports?

Salesforce has expanded report editing since the first release of report inline editing. Current Salesforce Help should be treated as the source of truth, but admins should test the exact report type, object, field, and record type in a sandbox. Text, number, checkbox, date, picklist, and lookup support depends on the report context and the current release. Formula fields, roll-up summary fields, system fields, and fields made read-only by security or layout rules are not good candidates for report editing.

Report editing limits to check before rollout

Salesforce Help states that report inline editing can have limits such as a maximum number of report columns edited per row and additional restrictions based on field type and report structure. In enterprise orgs, the practical limit is often lower because validation rules, duplicate rules, required dependencies, and record-triggered automation can reject changes that look simple in the grid.

• Do not use reports as a mass update tool. Use them for review-and-correct work, not migration work.
• Avoid editing grouped fields. If the field drives a grouping, summary, formula, or subtotal, test how the report refreshes after save.
• Check lookup columns with blank values. Some report cells are blocked when the lookup column has no existing values in the report results.
• Watch junction objects. Columns directly associated with junction objects are common blockers.

How to allow editing of multiple records in Salesforce Lightning list views

List views are the simplest native route for how to allow editing of multiple records in Salesforce Lightning when users work from an object tab. They are best for focused operational work such as updating Lead Status, Account Rating, Case Priority, or a custom review field.

How inline edit in Salesforce differs between reports and list views

Inline edit in Salesforce list views depends heavily on the list view configuration. Salesforce Help notes that a list view with more than one record type cannot be inline edited. If record types are enabled for the object, create list views filtered to one record type when users need list editing. Reports can be more flexible for filtering and analysis, but reports also have their own field and report-structure restrictions.

Salesforce inline editing permissions checklist

• The user has Edit permission on the object.
• The user can see and edit the field through field-level security.
• The user has record access through ownership, role hierarchy, sharing rules, teams, manual sharing, or another sharing mechanism.
• The field is visible and editable for the relevant page layout and record type.
• The list view is not mixing record types when list view inline editing is required.
• Enhanced list and inline editing settings are enabled where your org still exposes those settings.
• Validation rules, duplicate rules, flows, and triggers permit the new values.

Use a permission set group for the business role that needs this capability. Do not solve inline editing by over-granting profile permissions. In a production org, the better pattern is to create a named permission set such as Sales Operations Inline Edit, document its object and field permissions, and assign it only to users who own the process.

Why inline editing isn’t supported for this cell

The message inline editing isn’t supported for this cell means Salesforce found at least one reason the current user cannot edit that exact cell in that exact context. It does not always mean the whole feature is disabled.

Fix: inline editing isn’t supported for this cell

Start with the field, then the record, then the report or list view. This order avoids wasting time in Setup when the issue is a read-only field or a blocked report column.

Make a field inline editable in reports and list views

A field is inline editable only when Salesforce can safely save the change from that grid. For a custom field, confirm the field is not a formula, roll-up summary, auto-number, or encrypted field that your report/list context cannot edit. Then verify FLS, object permission, page layout, and record type access. For picklists, confirm the value is valid for the record type. For lookup fields, confirm the lookup filter does not reject the selected record.

Admins often test with a System Administrator user and assume the feature works for everyone. That test is incomplete. Test with a real permission set assignment and a record the target user owns or can edit through sharing. Then test a record the user can view but not edit to confirm the grid blocks the save.

How to build an inline editable Lightning Web Component

Use a custom LWC when native Salesforce inline editing does not match the process. Common examples include editing child records from a parent workspace, applying custom row errors before DML, saving only selected draft rows, or showing a business-specific confirmation page.

Salesforce Developer Docs describe two common save patterns for lightning-datatable: use UI API updateRecord() for simple record updates, or call Apex for custom save logic. UI API is easier for simple screens, while Apex is better when you need one server transaction, controlled partial success handling, or cross-record validation.

LWC HTML for inline editable rows

<template>
    <lightning-card title="Account Review">
        <lightning-datatable
            key-field="Id"
            data={accounts}
            columns={columns}
            draft-values={draftValues}
            onsave={handleSave}
            hide-checkbox-column>
        </lightning-datatable>
    </lightning-card>
</template>

LWC JavaScript using draft values

import { LightningElement, wire } from 'lwc';
import { refreshApex } from '@salesforce/apex';
import { notifyRecordUpdateAvailable } from 'lightning/uiRecordApi';
import { ShowToastEvent } from 'lightning/platformShowToastEvent';

import getAccounts from '@salesforce/apex/AccountInlineEditController.getAccounts';
import updateAccounts from '@salesforce/apex/AccountInlineEditController.updateAccounts';

const COLUMNS = [
    { label: 'Account Name', fieldName: 'Name' },
    { label: 'Rating', fieldName: 'Rating', editable: true },
    { label: 'Industry', fieldName: 'Industry', editable: true },
    { label: 'Phone', fieldName: 'Phone', type: 'phone', editable: true }
];

export default class AccountInlineEditor extends LightningElement {
    columns = COLUMNS;
    accounts = [];
    draftValues = [];
    wiredAccountsResult;

    @wire(getAccounts)
    wiredAccounts(result) {
        this.wiredAccountsResult = result;
        if (result.data) {
            this.accounts = result.data;
        }
    }

    async handleSave(event) {
        const updates = event.detail.draftValues;

        try {
            await updateAccounts({ updates });

            await notifyRecordUpdateAvailable(
                updates.map((row) => ({ recordId: row.Id }))
            );

            await refreshApex(this.wiredAccountsResult);
            this.draftValues = [];

            this.dispatchEvent(
                new ShowToastEvent({
                    title: 'Records updated',
                    message: `${updates.length} account record(s) saved.`,
                    variant: 'success'
                })
            );
        } catch (error) {
            this.dispatchEvent(
                new ShowToastEvent({
                    title: 'Save failed',
                    message: this.reduceError(error),
                    variant: 'error'
                })
            );
        }
    }

    reduceError(error) {
        return error?.body?.message || error?.message || 'Unknown error';
    }
}

The component stores changes in draftValues until the user clicks Save. After Apex saves the records, notifyRecordUpdateAvailable() tells Lightning Data Service that those records changed outside LDS, and refreshApex() refreshes the wired Apex result. Salesforce Developer Docs state that notifyRecordUpdateAvailable() replaces the older getRecordNotifyChange() approach.

Apex controller using user mode DML

public with sharing class AccountInlineEditController {
    @AuraEnabled(cacheable=true)
    public static List<AccountRow> getAccounts() {
        List<Account> accounts = [
            SELECT Id, Name, Rating, Industry, Phone
            FROM Account
            WITH USER_MODE
            ORDER BY Name
            LIMIT 200
        ];

        List<AccountRow> rows = new List<AccountRow>();
        for (Account accountRecord : accounts) {
            rows.add(new AccountRow(accountRecord));
        }
        return rows;
    }

    @AuraEnabled
    public static void updateAccounts(List<Account> updates) {
        if (updates == null || updates.isEmpty()) {
            return;
        }

        List<Account> recordsToUpdate = new List<Account>();
        for (Account incoming : updates) {
            if (incoming.Id == null) {
                continue;
            }

            recordsToUpdate.add(new Account(
                Id = incoming.Id,
                Rating = incoming.Rating,
                Industry = incoming.Industry,
                Phone = incoming.Phone
            ));
        }

        if (recordsToUpdate.isEmpty()) {
            return;
        }

        Database.SaveResult[] saveResults =
            Database.update(recordsToUpdate, false, AccessLevel.USER_MODE);

        List<String> errors = new List<String>();
        for (Integer index = 0; index < saveResults.size(); index++) {
            if (!saveResults[index].isSuccess()) {
                for (Database.Error error : saveResults[index].getErrors()) {
                    errors.add(
                        'Record ' + recordsToUpdate[index].Id + ': ' + error.getMessage()
                    );
                }
            }
        }

        if (!errors.isEmpty()) {
            throw new AuraHandledException(String.join(errors, ' | '));
        }
    }

    public class AccountRow {
        @AuraEnabled public Id Id;
        @AuraEnabled public String Name;
        @AuraEnabled public String Rating;
        @AuraEnabled public String Industry;
        @AuraEnabled public String Phone;

        public AccountRow(Account accountRecord) {
            Id = accountRecord.Id;
            Name = accountRecord.Name;
            Rating = accountRecord.Rating;
            Industry = accountRecord.Industry;
            Phone = accountRecord.Phone;
        }
    }
}

This Apex pattern uses WITH USER_MODE for the SOQL query and AccessLevel.USER_MODE for DML. Salesforce Developer Docs describe user mode as an access mode for SOQL, SOSL, and database operations. In practice, this keeps the custom grid aligned with user permissions instead of accidentally giving the component system-level edit behavior. Compile and test this class with the API version used by your org; user mode database operations are available in modern Apex API versions and should be validated in the same release used for deployment.

UI API option for smaller screens

For a simple grid with a small number of changed rows, developers can also call updateRecord() from lightning/uiRecordApi. Salesforce Developer Docs state that updateRecord(recordInput, clientOptions) updates one record using the User Interface API. For multiple draft rows, call it for each record and wait for all promises:

import { updateRecord } from 'lightning/uiRecordApi';

async saveWithUiApi(draftValues) {
    const recordInputs = draftValues.map((draft) => ({
        fields: { ...draft }
    }));

    await Promise.all(recordInputs.map((recordInput) => updateRecord(recordInput)));
}

Do not use this pattern for heavy updates. It creates one client-side update call per row. For larger grids or cross-row validation, use Apex with one server request, partial success handling, and clear row-level error messages.

Best practices for inline edit in Salesforce

• Filter before editing. Create list views and reports that show only records the user is expected to maintain.
• Keep editable columns narrow. Fewer editable fields reduce bad data and make validation errors easier to explain.
• Separate review fields from financial fields. Let users edit fields such as Status, Next Step, Priority, or Review Notes. Protect calculated, integration-owned, and finance-controlled fields.
• Test automation side effects. A single grid save can fire record-triggered flows, triggers, assignment rules, duplicate rules, and validation rules across many records.
• Use sandbox testing with real profiles and permission sets. Admin users hide access problems that regular users will hit in production.
• Log failed custom saves. For LWC/Apex grids, capture row ID, field, user, and exception text in a platform event or custom log object if the process is business critical.

When not to use Salesforce inline editing

Salesforce inline editing is not the right tool when the requirement is a governed bulk update, nightly synchronization, complex duplicate remediation, or a migration. Use Data Loader, Bulk API, Flow, or Batch Apex when the change set is large, repeatable, or needs an audit process beyond normal field history.

Also avoid inline editing when users need to change fields owned by an integration. For example, if an ERP updates credit status or a marketing platform owns subscription status, place that field as read-only and expose a request process instead of letting users edit it in a grid.

Deployment checklist for admins and developers

1. Identify the fields users must edit and remove fields that are calculated, integration-owned, or finance-controlled.
2. Confirm the object, field, and record permissions in permission sets.
3. Build one list view or report per process, not one general report for every update.
4. Test the save with real validation rules, duplicate rules, flows, triggers, and required fields enabled.
5. For LWC, write Apex tests for success, partial failure, missing permissions, and validation errors. Salesforce requires at least 75% Apex test coverage for deployment, but production code should test outcomes, not only line coverage.
6. Train users to read row errors and stop editing when they see inline editing isn’t supported for this cell instead of trying the same cell repeatedly.

Related SalesforceTutorial resources

• Salesforce reports and dashboards setup
• Salesforce list views in Lightning Experience
• Lightning Web Components tutorial
• Salesforce Flow automation guide
• Salesforce security model basics

Frequently Asked Questions