Core Concepts of Custom Lightning Types

You build all custom Lightning types, whether Apex-based or object-based, by using a common set of foundational components. Understand these core concepts to create, customize, and deploy your types.

Lightning Type consists of these artifacts.

Schema defines the data structure and the rules for its validation, such as maximum length, type, and format.
Editor defines the input UI component that you use to enter or edit data.
Renderer defines the output UI component that displays data.

The LightningTypeBundle metadata type describes the custom Lightning types. It’s available in API version 64.0 and later.

To get a list of the custom and standard Lightning types deployed in your org, make a call to the /connect/lightning-types resource.

For more information about the resources available in the Type System Connect REST API, see the Type System Resources.

LightningTypeBundle components are stored in the lightningTypes folder.

Here’s an example of the LightningTypeBundle structure.

The bundle includes these resources.

The lightningTypes folder (1) contains a folder for each custom Lightning type created in the format {typeName} (2).
Each custom Lightning type folder contains a schema.json file (3) that defines the JSON schema that drives the custom Lightning type validation.
Optional channel-specific folders (4). To override the default UI for a specific Salesforce application, the bundle contains a folder named after that channel. The supported channel folders are:
- lightningDesktopGenAi (Agentforce Employee agent in Lightning Experience)
- enhancedWebChat (Agentforce Service agent via Enhanced Chat v2)
- experienceBuilder (Experience Builder)
Inside the {channelName} folder, you can configure:
- The editor.json file (5) containing custom user interface and editor information
- The renderer.json file (6) containing custom user interface and renderer information
  
  This file isn’t supported in experienceBuilder.

To deploy a LightningTypeBundle to your Salesforce org, use Metadata API or SF Commands. The Metadata API uses a manifest file that defines the metadata that you want to deploy.

Here’s an example package.xml manifest file for a LightningTypeBundle that includes the custom Lightning type myFlight.

To delete a custom Lightning type, you must deploy a destructiveChanges package to your org that lists the types to delete.

See Also

Metadata API Developer Guide: Deploying and Retrieving Metadata with the Zip File
Metadata API Developer Guide: Deleting Components from an Organization

Use the Salesforce CLI project commands to deploy, retrieve, and track the source files for the LightningTypeBundle metadata type in your Salesforce DX project. See project Commands in the Salesforce CLI Command Reference.

Packaging supports the LightningTypeBundle metadata type that describes custom Lightning types. You can include the LightningTypeBundle in first-generation (1GP) and second-generation (2GP) packages. See the First-Generation Managed Packaging Developer Guide and the Second-Generation Managed Packaging Developer Guide.

See Also

The LightningTypeBundle includes these configuration files.

Schema.json

The schema.json file is a required resource in every Lightning Type Bundle. It defines the data structure, validation rules (such as type, format, and maximum length), and constraints for your custom Lightning type by using the JSON Schema specification.

Editor.json

With the optional editor.json file, you can override the default input UI. Use this file to define the specific custom LWC component for entering or editing data.

The editor.json file supports this type of override.

Editor Override. Defines the custom editor for the custom Lightning type. Use the $ keyword to specify an LWC component that captures or edits data for the entire type. Alternatively, use property names to specify LWC components that capture or edit data for individual properties while default editors handle the rest.

Renderer.json

With the optional renderer.json file, you can override the default output UI. Use this file to define the custom LWC component used to present or display data to the user.

The renderer.json file supports two types of overrides.

Renderer Override. Defines a single renderer for the entire custom Lightning type. You use the $ keyword to specify the LWC component that renders the data for a single instance of the type.
Collection Renderer Override. Defines a renderer for a structured list or array of data. This approach uses the collection keyword to associate a custom LWC component that renders the entire list of data at once.

See Also

Component Override

When you reference metadata such as a custom label or a component in your custom Lightning type, use the correct namespace prefix. This prefix applies to metadata references in your schema, editor, and renderer files.

For metadata created in your org

Use the “c” namespace prefix. This rule applies even if your org has its own namespace. For example, if your org’s namespace is myOrgNamespace and you create an LWC component named flightDetails, refer to it as c/flightDetails.

This rule also applies to custom Lightning types in managed packages. Reference any new metadata in the same package by using the “c” prefix.

For metadata installed via a managed package

Use the package’s unique namespace as the prefix. For example, if a package has the namespace isv and includes an LWC component named flightDetails, refer to it as isv/flightDetails.

Example of Local Org Metadata References

This schema.json file uses the “c” namespace to reference a custom label and the @apexClassType reference of an Apex class.

This renderer.json file uses the “c” namespace to reference a Lightning Web Component.

You can customize labels for the title and description values in the schema.json file for a custom Lightning type.

To create and use a translated custom label in a custom Lightning type, complete these steps.

From Setup, enter Labels in the Quick Find box, and then select Custom Labels.
Create a custom label.
In the schema.json file for the custom Lightning type that you created, use the expression {!$Label.c.MyLabel1} for the title and description values. Here, “c” is the namespace prefix and “MyLabel1” is the API name of the custom label.

See Also

You can override the default UI of some Salesforce applications by using a custom Lightning type. Each Salesforce application listens to a specific channel that you specify in your LightningTypeBundle.

You can override these Salesforce applications.

Agentforce Employee agent in Lightning Experience
Agentforce Service agent via Enhanced Chat v2
Experience Builder
Prompt Builder
Flows via Structured Outputs

To override the UI, create a folder in your LightningTypeBundle with the application’s corresponding channel name.

Salesforce Application	Channel Folder	Category
Agentforce Employee agent in Lightning Experience	`lightningDesktopGenAi`	Apex
Agentforce Service agent via Enhanced Chat v2	`enhancedWebChat`	Apex
Experience Builder	`experienceBuilder`	Object
Prompt Builder	Not Applicable	Object
Flows via Structured Outputs	Not Applicable	Object

See Also