Define a Top-Level Editor Override

You can define a single editor for your entire custom Lightning type in the editor.json file. This editor applies whenever an instance of the type is used as an input parameter.

For example, you have a custom Lightning type named taskFilter that corresponds to the Apex class TaskCriteria with two properties: priorityLevel and dueDate. You want to use a custom dropdown to select the priority level and a calendar picker for the due date.

Here’s an example of what the editor.json file can look like for the custom Lightning type taskFilter.

This example uses lightningDesktopGenAi to configure the custom Lightning type. To configure the type for a different channel, create the editor.json file inside the folder that corresponds to that channel.

Example: Basic Configuration Using the value Property

This example shows you how to configure a component to handle the entire object via a single @api value property. The component receives the full object in one property.

To view a complete, working example of an LWC editor implementation, see Customize UI for Input.

Create the LWC.

This sample code shows the LWC component myTaskComponent.

The @api value property in custom Lightning type editors doesn’t support data injection, so the agent can’t pre-populate it with conversational context or default values. Use it only to capture user input. The framework returns this data to the agent action only after the user submits a response in the chat interface.
Update the js-meta.xml file.

Include the lightning__AgentforceInput target.

This sample code shows the contents of the myTaskComponent.js-meta.xml file.
Configure the editor.json file.

Use the $ keyword to map the type to the component.

Here’s how to reference myTaskComponent to override the editor for the taskFilter custom Lightning type in the editor.json file.

Example: Attribute Mapping

If you’re reusing an existing component and the property names don’t match your schema (for example, the component uses urgency instead of priorityLevel), you must map the properties.

Create the LWC.

This sample code shows myExistingTaskComponent.
Update the js-meta.xml file.

Expose the properties in targetConfigs to register them as valid input properties for the lightning__AgentforceInput target.

This sample code shows the contents of the myExistingTaskComponent.js-meta.xml file.
Configure the editor.json file with attribute mapping.

Use the attributes object to link schema properties to component properties.

This sample code shows how to reference myExistingTaskComponent to override the editor for the taskFilter custom Lightning type in the editor.json file.

You must map the component’s properties to the corresponding properties in the Apex class, even if they have the same name. However, if the component receives the entire Apex class object through a single value attribute, you don’t need to map the individual attributes.

The expression "urgency": "{!$attrs.priorityLevel}" links the priorityLevel property of the TaskCriteria Apex class to the urgency property of the LWC component myExistingTaskComponent (and vice versa).

Here’s what each element represents.

urgency: Property in the LWC component myExistingTaskComponent
{!$attrs}: Pointer to the TaskCriteria class
priorityLevel: Property in the TaskCriteria class
{!$attrs.priorityLevel}: Evaluates to the specific value of the priorityLevel property so it can be dynamically passed to the component

See Also