Record Form

Use the lightning:recordForm component to quickly create forms to add, view, or update a record.

Using this component to create record forms is easier than building forms manually with lightning:recordEditForm or lightning:recordViewForm. The lightning:recordForm component provides these helpful features:

• Switches between view and edit modes automatically when the user begins editing a field in a view form
• Provides default Cancel and Save buttons in edit forms
• Uses the object's default record layout with support for multiple columns
• Loads all fields in the object's compact or full layout, or only the fields you specify

However, lightning:recordForm is less customizable. To customize the form layout or provide custom rendering of record data, use lightning:recordEditForm (add or update a record) and lightning:recordViewForm (view a record).

The objectApiName attribute is always required, and the recordId is required only when you’re editing or viewing a record.

lightning:recordForm implements Lightning Data Service and doesn't require additional Apex controllers to create or edit record data. It also takes care of field-level security and sharing for you, so users see only the data that they have access to.

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:recordForm 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:recordForm on a record page for an account, set objectApiName="Account". The component submits changes only if the record ID is in agreement with the specified object API name. If there's a mismatch, 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 won't render even when requested.

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

External objects are not 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.

The component accepts a mode value that determines the user interaction allowed for the form. The value for mode can be one of the following:

• edit - Creates an editable form to add a record or update an existing one. When updating an existing record, specify the recordId. Edit mode is the default when recordId is not provided, and displays a form to create new records.
• view - Creates a form to display a record that the user can also edit. The record fields each have an edit button. View mode is the default when recordId is provided.
• readonly - Creates a form to display a record without enabling edits. The form doesn’t display any buttons.

For all modes, the component expects the fields attribute or the layoutType attribute.

Use the fields attribute to pass record fields as an array of strings. The fields display in the order you list them.

Use the layoutType attribute to specify a Full or Compact layout. Layouts are typically created or modified by administrators. Specifying record data using layoutType loads fields that are defined by the layout definition. All fields that have been assigned to the layout are loaded into the form. This is the same behavior as the Lightning Data Service’s force:recordData object.

To see the fields in the layout types in your org:

• Full - The full layout corresponds to the fields on the record detail page. From the management settings for the object that you want to edit, go to Page Layouts.
• Compact - The compact layout corresponds to the fields on the highlights panel at the top of the record. From the management settings for the object that you want to edit, go to Compact Layouts.

For more information, see Page Layouts.

lightning:recordForm renders a field as required only if the field is marked as required on the object. If a field is marked as required only on a page layout, the form doesn't render the field with the styling or validation for a required field.

To specify the field order, use fields without the layoutType attribute. We don't recommend using the fields attribute with the layoutType attribute as the display order of the fields can vary. Alternatively, use the lightning:recordEditForm or lightning:recordViewForm component to display a custom layout.

Fields that have a spanning relationship aren't supported by lightning:recordForm. The fields specified must be associated with the same objectApiName. A field such as Contact.Account.Ownership is a cross-object reference between the Contact object and the Account object, and can't be displayed in the form.

To create a form that lets you view a record and optionally edit field values, use mode="view". Use recordId and objectApiName to pass the ID of the record and the corresponding object API name to be edited. Specify the fields using the fields attribute, or layoutType attribute to display all the fields defined on the Full or Compact layout.

The view mode loads the form using output fields with inline editing enabled. You can edit fields that are marked updateable in the User Interface API. If the user clicks an edit icon next to a field, all fields that are updateable become editable, and the form displays Cancel and Save buttons.

This example creates a view mode form for an account record with fields from the full layout.

To create a form that lets you view a record but not edit its field values, use mode="readonly". Use recordId and objectApiName to pass the ID of the record and the corresponding object API name for the record to be viewed. Specify the fields using the fields attribute, or layoutType attribute to display all the fields defined on the Full or Compact layout.

The readonly mode loads the form with output fields only, and without Cancel or Save buttons.

This example creates a form for an account record in readonly mode with a single column and fields from the compact layout.

To create a form that lets you edit a record, specify the mode="edit" attribute. Use recordId and objectApiName to pass the ID of the record and the corresponding object API name to be edited. Specify the fields using the fields attribute, or layoutType attribute to load all the fields defined on the Full or Compact layout.

When a recordId is passed, edit mode loads the form with input fields displaying the specified record’s field values. The form also displays Cancel and Save buttons.

This example creates an editable two-column form for an account record using the compact layout. Place the form on an account record page, which is enabled by the flexipage:availableForRecordHome interface. The record ID is provided by the implicit recordId attribute added by the force:hasRecordId interface.

Define an array of field names in your JavaScript using the fields property. The onsubmit attribute specifies an action to override the handler for the submit.

To create a form that lets you create a record, do not specify a recordId. The form loads in edit mode by default when you don't specify a record ID. Use objectApiName to pass the object API name for the record to be created. Specify the fields you want using the fields attribute, or use layoutType="Full" to load all fields in the full layout.

The compact layout cannot be used for creating records. If you specify layoutType="Compact", the full layout is shown. If you specify the fields attribute, be sure to include any fields that are designated as required for the object's records.

Because no record ID is passed, edit mode loads the form with input fields that aren’t populated with field data. The form displays Cancel and Save buttons.

This example displays a form with the required name field and several others for creating account records. The onsuccess attribute specifies an action to override the handler when an account is successfully created.

When an account is successfully created, a toast message is displayed using the lightning:notificationsLibrary component's showToast method, which is called by the handleSuccess event handler. The onsuccess event returns the record object, including the ID of the newly created account.

lightning:recordForm does not support prepopulating of field values when the form loads. To create a form that displays custom field values, use the lightning:recordEditForm component.

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.

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.

Setting the Form Display Density

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.
• auto makes the form use the default behavior described in Form Display Density.

To customize the behavior of your form when it loads or when data is submitted, specify your own event handlers using the onload and onsubmit attributes.

Errors are automatically handled. 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.

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.

To customize the behavior when the Cancel button is clicked, use the oncancel attribute.

For information about Event Return Parameters and examples of event handlers, see the documentation for lightning:recordEditForm.

To use lightning:recordForm 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.

In some cases, you must explicitly reload the view to display your latest change on the record page. For example, when you use lightning:recordForm to create a related contact record on an account record page, fire the force:refreshView event to make sure all standard components like the related list on a record page reflect your changes.

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 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 view and update a person account record.

Multiple currencies are not supported in edit mode. If you enabled Activate Multiple Currencies in your org, lightning:recordForm 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:recordForm in another instance of the component, or nesting it in lightning:recordEditForm or lightning:recordViewForm is not supported.

lightning:recordForm shares the same usage considerations as lightning:recordEditForm and lightning:recordViewForm.

lightning:recordForm loads fields using lightning:inputField and lightning:outputField internally. As a result, it supports the same field types as listed in the documentation for those components.

lightning:inputField

lightning:outputField

lightning:recordEditForm

lightning:recordViewForm

Lightning Data Service