Record Edit Form

Use the lightning:recordEditForm component to create a form that's used to add a Salesforce record or update fields in an existing record. The component displays fields with their labels and the current values, and enables you to edit their values.

lightning:recordEditForm supports the following features.

• Editing a record's specified fields, given the record ID.
• Creating a record using specified fields.
• Customizing the form layout.
• Custom rendering of record data.

If you don't require customizations, use lightning:recordForm instead.

To specify editable fields, use lightning:inputField components inside the lightning:recordEditForm component. See the Editing a Record section.

To display record fields as read-only in lightning:recordEditForm, use lightning:outputField components to specify those fields. You can also use HTML and other display components such as lightning:formattedName to display non-editable content.

To display all fields as read-only, use the lightning:recordForm component with mode="readonly" or the lightning:recordViewForm component instead of lightning:recordEditForm.

To understand the different use cases, see Lightning Data Service.

lightning:recordEditForm implements Lightning Data Service and doesn't require additional Apex controllers to create or update record data. This component also takes care of field-level security and sharing for you, so users see only the data they have access to. For more information, see Lightning Data Service.

When possible, let lightning:recordEditForm load and manage the data for you as it implements Lightning Data Service. Using lightning:recordEditForm to create and update records with Apex controllers can lead to unexpected behaviors. Additionally, data provisioned by Apex is not managed and you must handle data refresh by invoking the Apex method again on your own.

To access raw record data or create a form that needs more customization than the lightning:record*Form components allow, use force:recordData. You can use Apex if you are working with an object that's not supported by the User Interface API, or you have to use a SOQL query to select certain records. For more information, see Using Apex in the Lightning Aura Components Developer Guide.

Each Salesforce record is associated with a Salesforce object. For example, a contact record is associated with the Contact object. Record IDs are created with prefixes that indicate the object. The lightning:recordEditForm component requires you to specify the objectApiName attribute to establish the relationship between a record and an object. The object API name must be appropriate for the use of the component. For example, if you include lightning:recordEditForm on a record page for an account, set objectApiName="Account". The component submits changes only if the record ID agrees with the specified object API name. If there's a mismatch, and the component includes lightning:messages, users see an error indicating the API name is invalid.

To use your component in a managed package, include your namespace when using objectApiName, for example, objectApiName="namespace__Custom_object__c".

This component doesn't support all Salesforce standard objects. This limitation also applies to a record that references a field that belongs to an unsupported object.

This component supports the Task object but Task.IsRecurrence and Task.IsReminderSet don't render even when requested.

This component supports the Event object but Event.IsRecurrence, Event.IsRecurrence2, and Event.IsReminderSet don't render even when requested.

External objects aren't supported. The InformalName field is not supported for editing.

For a list of supported objects, see the User Interface API Developer Guide.

If you are working with an unsupported object or if have to use SOQL to query certain records, create your own UI and use Apex to work with Salesforce data. For more information, see Using Apex in the Lightning Aura Components Developer Guide.

To enable record editing, pass in the ID of the record and the corresponding object API name to be edited. Specify the fields you want to include in the record edit layout using lightning:inputField.

Include a lightning:button component with type="submit". When you press the Enter key or click the button, it validates the fields and submits the values.

To display an editable field in the form, use the lightning:inputField component and set the fieldName to the API name of the field. Labels for certain fields can differ from those displayed on a standard record page. For example, the Name field on the opportunity object displays "Name" instead of "Opportunity Name" while the Name field name on the account object displays "Account Name".

To enable record creation, pass in the object API name for the record to be created. Specify the fields you want to include in the record create layout.

Include a lightning:button component with type="submit". When you press the Enter key or click the button, it validates the fields and submits the values.

lightning:recordEditForm renders the fields within the HTML form element and uses a button for form submission.

Customizing the form element for form submission is not supported. We recommend that you use lightning:button with type="submit" as shown in the previous sections. The default type on lightning:button is button, which does nothing unless you include an onclick handler. If you use an HTML button element within lightning:recordEditForm, the default is type="submit".

When you submit the form, the component fires the custom events in this order.

1. click if you use the onclick event handler on the button
2. submit
3. success or error

You can edit the field values programmatically using the onsubmit event handler or selectively handle any of the custom events. See Overriding Default Behaviors.

lightning:recordEditForm handles field-level validation errors and Lightning Data Service errors automatically. For example, entering an invalid email format for the Email field results in an error message when you try to submit the change. Similarly, a required field like the Last Name field displays an error message when you try to submit the change and the field is blank.

A Lightning Data Service error is returned when a resource becomes inaccessible on the server or an invalid record ID is passed in, for example. To display the error message automatically, include lightning:messages before or after the lightning:inputField components. For more information, see Overriding Default Behaviors.

lightning:recordEditForm also verifies data input based on your validation rules. The form submits and saves data input only if all data in the fields are valid. The form clears validation rule errors when an onchange event is fired on the overall form, and also when you update a field with a validation rule error.

If a single field has multiple validation errors, the form shows only the first error on the field. Similarly, if a submitted form has multiple errors, the form displays only the first error encountered. When you correct the displayed error, the next error is displayed.

We recommend using custom validation rules to verify data input instead of implementing client-side validation errors. A validation rule can contain a formula or expression that evaluates the data in one or more fields. You can include an error message to display on an invalid field. See Validation rules in Salesforce Help for more information.

If your org uses record types, picklist fields display values according to your record types. You must provide a record type ID using the recordTypeId attribute if you have multiple record types on an object and you don't have a default record type. Otherwise, the default record type ID is used.

To locate the ID of a record type, use the following SOQL query.

Passing in a record type as a field on this component is not supported.

To create a multi-column layout for your record edit layout, use the Grid utility classes in Lightning Design System. This example creates a two-column layout.

To provide a custom field value when the form displays, use the value attribute on lightning:inputField. If you're providing a record ID, the value returned by the record on load does not override this custom value.

This example displays a form with a custom value for the account name field. The form creates a new account record when you click the button.

This example displays a form with a custom value for the account name field. The form updates the account record when you click the button. The component implements the flexipage:availableForRecordHome and force:hasRecordId interfaces and automatically inherits the record ID from the record page it's placed on.

To programmatically set the value when the form loads, use the init handler or the onload event handler. This example sets the value in the onload event handler, which runs after the init handler. You can set this value programmatically at a later time, such as on a button click.

Set the field value in your client-side controller.

In the Salesforce user interface, the Display Density setting lets users choose how densely the content is displayed. The Comfy density shows labels on top of the fields and more space between page elements. Compact density shows labels next to the fields and less space between page elements.

The record form components, lightning:recordForm, lightning:recordEditForm, and lightning:recordViewForm, handle form density in similar ways. The density attribute is set to auto by default for all record form components.

Display density is supported for lightning:inputField and lightning:outputField within the form; display density is not supported for custom components within the form.

With auto density:

• Record form components detect the Display Density setting and the width of the form's container to determine label position. The record form components don't change the space between elements, however.
• If your Salesforce density setting is Comfy, the fields always display with their labels above them.
• If your Salesforce density setting is Compact, the fields initially display with their labels next to them. If you resize the form container below a certain width or use the form in a narrow container, the fields display with their labels above them. This behavior is similar to how other elements behave in Lightning Experience when Compact density is enabled. The record form components use the same width settings to determine when to switch the display density.
• If a record form component doesn't detect the Salesforce density setting, the fields display with their labels next to them. If you resize the form container to a narrow width, the fields display with their labels above them.

Detecting the user's density setting is only supported in Lightning Experience. When a record form component runs outside Lightning Experience, and density is set to auto, the fields display with their labels next to them, and switch to labels above the fields when in a narrow container.

If you specify a variant for lightning:inputField or lightning:outputField, the variant overrides the display density for that field.

To display a record form with a particular density, set the density attribute to one of these values.

• comfy makes the form always display labels on top of fields and doesn't detect the user setting.
• compact makes the form display labels next to their fields and doesn't detect the user setting. However, the form switches to the comfy density if the form is narrowed to the width that triggers the automatic change. To reduce the whitespace between the label and field when the form uses compact density, use the slds-form-element_1-col class on lightning:inputField or lightning:outputField.
• auto makes the form use the default behavior described in Form Display Density.

The lightning:recordEditForm component's built-in events and their return parameters are as follows.

onerror

The action triggered when the record edit form returns a server-side error on form submission.

onload

The action triggered when the record edit form loads record data. If you load the fields dynamically, onload is triggered before the child elements of lightning:recordEditForm finish loading. To prepopulate a list of field values using aura:iteration, consider setting the values using the init event instead.

onload is triggered when the form gets new data from Lightning Data Service, which can be once or multiple times after the component is initialized. For example, onload is triggered when:

• The recordId value changes
• The fields list changes
• The form includes picklist fields
• The record type changes

If you require onload to be called only once, write code to prevent it from running more than once.

onsubmit

The action triggered when the submit button is pressed. Client-side validation errors, if any, are displayed. The form is then submitted only when all fields in the form are valid. The form can be submitted only after it's loaded.

onsuccess

The action triggered when the record data is updated successfully, and then fires the load event to return the updated data.

To see the fields data on load:

To see the response data when a record is created or updated successfully:

To customize the behavior of your form when it loads or when data is submitted, use the onload and onsubmit attributes to specify event handlers. If you capture the submit event and submit the form programmatically, use event.preventDefault() to cancel the default behavior of the event. This prevents a duplicate form submission.

Errors are automatically handled. To customize the behavior of the form when it encounters an error on submission or when data is submitted successfully, use the onerror and onsuccess attributes to specify event handlers.

Here are some example event handlers for onsubmit and onsuccess.

The same event handlers can be used with lightning:recordForm

To reset the form fields to their initial values, use the reset() method on lightning:inputField.

We recommend creating a button that reverts the field values to their initial values using lightning:button. The default type for lightning:button is button, which does nothing unless you include an onclick handler.

If you use an HTML button element within lightning:recordEditForm to perform an action such as resetting the field values, specify type="button". By default, an HTML button element uses type="submit" when it's rendered in an HTML form element. Additionally, using type="reset" on a button deletes the form values and does not preserve the initial values.

This example creates a form with two fields, followed by Cancel and Save Record buttons. When you click the Cancel button, the handleReset method resets the fields to their initial values. Add this example to an account record page to inherit its record ID.

Call the reset() method on each field.

To use lightning:recordEditForm in a custom action for Lightning Experience or the Salesforce mobile app, add the force:lightningQuickAction or force:lightningQuickActionWithoutHeader interface to your custom component. On the Object Manager page for your object, select Buttons, Links, and Actions and then New Action. Your custom component then appears on the Lightning Component action type picklist.

For example, you want to provide a custom action that creates a new case on a contact record page. Your custom component appears in an overlay dialog and you can configure the form to navigate back to the contact record page after a user enters the case details.

When a user clicks the Create case button on the custom action component, update the ContactId field with the contact record ID using component.get("v.recordId") before submitting the form.

In some cases, you must explicitly reload the view to display your latest change on the record page. For example, if you navigate to another page instead and try to go back to the contact record page via the browser's Back button, you might notice that the case related list doesn't reflect the latest record you created. To make sure all standard components like the related list on a record page reflect your changes, fire the force:refreshView event.

For more information, see Lightning Component Actions and Override Standard Actions with Aura Components.

A person account is a record type on the account object. It combines fields from the account and contact object into a single record. To use person accounts in your org, you must enable the Person Accounts setting first. After Person Accounts is enabled, it can’t be disabled. For more information, see Enable Person Accounts.

To access person account fields, use the account object with objectApiName="Account".

Specify the fields using the field names listed in the IsPersonAccountFields section for the Account object in the Object Reference.

The fields that begin with Person are the fields from the contact object.

For standard fields on the contact object, use Person<ContactFieldName>. For example, use fieldName="PersonMobilePhone" for the MobilePhone field on the contact object.

For custom fields on the account object, use CustomFieldName__c as usual.

For custom fields on the contact object, use CustomFieldName__pc.

This example creates a form to update a person account record.

Multiple currencies aren't supported. If you enabled Activate Multiple Currencies in your org, lightning:recordEditForm displays currency fields using the corporate currency, even when the default currency of a record is different. For more information, see Manage Multiple Currencies.

Nesting lightning:recordEditForm in another instance of the component, or nesting it in lightning:recordForm or lightning:recordViewForm is not supported.

Use lightning:inputField only as a direct child of lightning:recordEditForm. Don't nest lightning:inputField components in another component.

The form displays read-only input fields the same as output fields, without borders or gray backgrounds, unlike disabled input fields.

The Id field for a record ID displays as read-only even when specified with lightning:inputField.

Formula fields are automatically calculated, and displayed read-only on record forms. Formula fields always display the calculated value.

For more information about supported field types such as name fields and lookup fields, see the lightning:inputField documentation.

Working with Salesforce Data