salesforce

Lightning Record Edit Form: Implementation Guide

Building efficient data entry interfaces in Salesforce doesn't require complex Apex controllers or heavy custom code. The lightning:recordEditForm component (or its LWC equivalent, lightning record ed

Lightning Record Edit Form: Implementation Guide
In this story

Building efficient data entry interfaces in Salesforce doesn't require complex Apex controllers or heavy custom code. The lightning:recordEditForm component (or its LWC equivalent, lightning-record-edit-form) provides a declarative, secure wrapper that renders record fields with built-in validation, field-level security enforcement, and automatic error handling.

By leveraging Lightning Data Service under the hood, this component loads, saves, and updates records without requiring manual SOQL queries or DML statements. This guide covers how to implement, structure, and optimize record edit forms to build lightning-fast data entry screens for your users.

Understanding Lightning Record Edit Form

The lightning-record-edit-form is a container component used to create or update records in Salesforce. Unlike standard input components that require manual wiring to server-side code, this form automatically handles data retrieval, saving, field-level security (FLS), and object-level permissions.

When you place this component on a page, it automatically respects the user profile's access rights. If a user doesn't have read access to a specific field, the form hides it. If they lack edit permissions, it renders the field as read-only. This baked-in governance eliminates the risk of accidental data exposure through custom UI components.

Core Structure and Syntax

A basic record edit form requires an object-level object-api-name attribute and one or more input fields wrapped inside. For existing records, you also supply a record-id attribute.

<template>
    <lightning-card title="Edit Account Details" icon-name="standard:account">
        <lightning-record-edit-form record-id={recordId} object-api-name="Account">
            <lightning-messages></lightning-messages>
            <lightning-input-field field-name="Name"></lightning-input-field>
            <lightning-input-field field-name="Phone"></lightning-input-field>
            <lightning-input-field field-name="Industry"></lightning-input-field>
            <div class="slds-m-top_medium">
                <lightning-button variant="brand" type="submit" label="Save"></lightning-button>
            </div>
        </lightning-record-edit-form>
    </lightning-card>
</template>

When building this structure, remember that <lightning-input-field> automatically inherits formatting, picklist values, and validation rules defined in Object Manager. You don't need to manually query picklist options or write custom validation rules for standard data types like email or phone numbers.

Step-by-Step Implementation Guide

Setting up an editable form in a custom Lightning Web Component involves preparing your component files, handling submission events, and providing user feedback.

Step 1: Define the Component HTML Markup

Create your component template and include the form wrapper, input fields, and standard submission buttons. Use lightning-messages inside the form to automatically display platform-level validation errors or missing required fields.

Step 2: Configure the JavaScript Controller

In your JavaScript controller, capture the recordId and objectApiName properties if the component is placed on a record page. Handle custom submission logic or clean up data before it hits the database if necessary.

import { LightningElement, api } from 'lwc';
import { ShowToastEvent } from 'lightning/platformShowToastEvent';

export default class EditAccountForm extends LightningElement {
    @api recordId;
    @api objectApiName;

    handleSuccess(event) {
        const evt = new ShowToastEvent({
            title: 'Success!',
            message: 'Record updated successfully: ' + event.detail.id,
            variant: 'success',
        });
        this.dispatchEvent(evt);
    }
}

Step 3: Configure the Meta XML File

Expose your component to Lightning App Builder so administrators can drag and drop it onto Account, Contact, or custom object record pages.

<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>60.0</apiVersion>
    <isExposed>true</isExposed>
    <targets>
        <target>lightning__RecordPage</target>
    </targets>
    <targetConfigs>
        <targetConfig targets="lightning__RecordPage">
            <objects>
                <object>Account</object>
            </objects>
        </targetConfig>
    </targetConfigs>
</LightningComponentBundle>

For more details on component configuration options, check the official Salesforce Lightning Web Components Developer Guide.

Handling Submissions and Validation Errors

Managing user input accurately requires capturing form events properly. The form triggers specific events during the lifecycle of a save operation:

  • onsubmit: Fires when the user clicks the submit button. You can use this event to intercept the submission, modify field values programmatically using event.detail.fields, or cancel the submission if client-side validation fails.
  • onsuccess: Fires after the record has successfully saved to the database. This is the ideal place to trigger toast notifications or navigate the user to a different view.
  • onerror: Fires when server-side validation rules, triggers, or sharing rules block the save operation.

If a validation rule stops a save, the <lightning-messages> component automatically renders the error message at the top of the form, matching the standard Salesforce UI behavior users expect.

Common Pitfalls to Avoid

Even experienced administrators and developers run into subtle traps when deploying record edit forms. Keeping these anti-patterns in mind will save you hours of debugging:

  • Hardcoding field names incorrectly: Always use proper API names. Typo in a field name results in silent failures or blank inputs rather than helpful compilation errors.
  • Bypassing record context: Forgetting to pass the recordId property in a record page context turns your form into a create form instead of an edit form, attempting to insert a duplicate record.
  • Overloading single forms: Putting dozens of fields on one form creates scrolling fatigue. Break long data entry tasks into logical sections or use multi-step layouts.
  • Ignoring mobile responsiveness: Always test your custom forms inside the Salesforce Mobile App to verify that touch targets and field arrangements render correctly on smaller screens.

Frequently Asked Questions

Can I prepopulate field values in a record edit form?

Yes. You can assign default values to <lightning-input-field> by binding them to JavaScript properties in your component or by modifying the fields object inside the onsubmit event handler before sending data to the server.

Does lightning-record-edit-form support custom validation rules?

Yes. Any active validation rules configured on the object in Salesforce Setup will execute automatically when the user clicks save. Error messages display directly inside the <lightning-messages> container.

How do I reset the form after a user cancels their edits?

You can reset all input fields to their original loaded values by calling the reset() method on the form element programmatically via JavaScript using template queries.

Can I use this component with custom objects?

Absolutely. Just supply your custom object's API name (for example, Project__c) to the object-api-name attribute, ensuring you append the correct namespace if it's part of a managed package.

SB

Written by

Samuel Baker

Samuel Baker approaches each story with intellectual curiosity and a commitment to fairness, earning the trust of readers and sources alike.

More from salesforce