As part of our continuing drive to make Lightning pages more dynamic and interactive, we are excited to give you a sneak peek at our next big thing™ to address this issue: Dynamic Interactions.
Today, if you want components on a Lightning page to talk to each other, you need developers to write code and wire events up. We want anyone to be able to point-and-click their way through the App Builder to build this experience.
Coming soon, an event occurring in one component on a Lightning page, such as the user clicking on an item in a list view, can automatically update other components on the page. Dynamic Interactions lets admins create applications with components that communicate and transform based on user interactions, all in the Lightning App Builder UI. It unlocks capabilities for admins that were previously reserved only for developers.
How does it work? To get the most out of Dynamic Interactions, admins and developers work together.
Developers write custom components that power the interactions. New code lets a developer define the events that are supported by a component and then expose them in the Lightning App Builder UI. Then, using new features inside the Lightning App Builder, an admin configures the event by setting up the interactions between the components.
There are four major building blocks for Dynamic Interactions:
An event occurring in one component (the source) can trigger changes in one or more other components on the page (the targets). A single source can have multiple targets.
Kai (they/them) and Rina (she/her) are an admin and developer team. Kai wants to give their on-the-go users an easy way to check the location of various accounts so they can plan efficient site visits, using a simple app page.
Kai enlists Rina’s help to make this happen, and Rina suggests Dynamic Interactions. As a developer, Rina knows that she can wire up events between components using code, but she wants to give Kai the freedom and power to configure the event interactions in the way that they need to, without being required to come back to her every time a change is necessary.
Rina creates a custom source component for Kai, plus two other components to act as event targets. After installing the new components in their org, here’s what Kai’s got: an app page with three custom components — Account List, Account Detail, and Account Location (a map).
The source component is the Account List on the left. It has an “Item Selected” event enabled, which Rina exposed to the Lightning App Builder UI using new Dynamic Interactions code. After Kai finishes configuring the event interactions, when a user clicks a list item in the Account List component, the event fires. The Account Detail component updates to show that account’s details, and at the same time, the Account Location component pinpoints that account’s location on a map. Every new click or tap on an account in the list results in an update in the content in the other two components.
As we mentioned, it takes both admins and developers to make Dynamic Interactions shine. And the keystone for the whole process is a custom source component. Only Lightning Web Components (LWCs) can be source components, but any component (Aura or LWC) can be a target.
How did Rina expose events from her source component? First, she fired standard JavaScript CustomEvents in the .js file. To make the event discoverable for Dynamic Interactions, she used some new metadata available for the component js-meta.xml file, similar to how properties for builders are exposed.
Developers, if you’re curious what this looks like, we have a sample js-meta.xml file for you at the end of this post.
After Rina makes the event available in the Lightning App Builder via the Account List component, Kai connects the dots between the source and target components using a new Dynamic Interactions UI in the Lightning App Builder properties pane.
If a component has events exposed, when you select it on the canvas, the properties pane for that component displays with two tabs. The Properties tab contains the component properties that you’re familiar with. The Events tab is new for Dynamic Interactions. It lists all of the events that are exposed for the selected component. Here is the properties pane that Kai sees when they click on the Account List source component in the Lightning App Builder.
The Item Selected event is available, but no interactions are set up for it. Kai can do that easily by clicking Add Interaction, selecting an interaction, then choosing a component to be the target of the interaction.
Components display in the list with their region location to help you select the correct component when working on pages with many components spread across multiple regions.
When you select a target component, its properties appear in the Interaction Details pane. There, you can define the new value that you want each target property to have when the event triggers and the interaction happens.
Here, Kai the admin is configuring an interaction between the Account List source component and the Account Location target component. After Kai selects Account Location as the target, its Record Id property appears, ready for Kai to give it a new value.
Kai’s goal for the interaction is that when a user clicks on an account in the list, the Account Location component updates to show the selected account’s location as a point on a map. Passing the record ID into the Account Location component tells the component what record to look at to pull the address information. Rina made the recordId property available as part of the event, so Kai can use the {!Event.recordId} expression in this field.
As we promised earlier, here’s the js-meta.xml configuration file for the sample Account List source component Rina created.
Dynamic Interactions introduces two new <targetConfig> subtags that can be used in a source component’s js-meta.xml file to expose an event.
<?xml version="1.0" encoding="UTF-8"?> <LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata"> <apiVersion>52.0</apiVersion> <isExposed>true</isExposed> <masterLabel>Account List</masterLabel> <targets> <target>lightning__AppPage</target> </targets> <targetConfigs> <targetConfig targets="lightning__AppPage"> <property name="apiName" type="String"/> <property name="listViewApiName" type="String"/> <event name="itemselected" label="Item Selected" description="This event fires when an item is selected."> <schema> { "type": "object", "properties": { "recordId": { "type": "string", "title": "Record ID", }, "apiName": { "type": "string" } } } </schema> </event> </targetConfig> </targetConfigs> <description>meta xml description</description> </LightningComponentBundle>
How would you use the power of Dynamic Interactions to create more powerful apps? Start thinking about it now, because it will be Generally Available (GA) in Winter ’22. More information coming soon!
True to the Core is a favorite session at Dreamforce and TDX, especially for admins who want an opportunity to connect with Salesforce executives and product managers on the topics that are most important to you. True to the Core offers an unfiltered look into our product development plans, and gives you the chance to […]
Winter ’25 is almost here! Learn more about Conditional Field Formatting and check out Be Release Ready to discover more resources to help you prepare for Winter ’25. The challenge with configuring visual indicators today Creating custom visual indicators to call attention to key fields is a common Salesforce configuration requirement. Visual indicators make it […]
Gosh, it just seemed like yesterday that I was putting together my blog post about Summer. But here we are, getting ready for Winter ’25. I find it a bit comforting to think about snow as a way to cool down in this 80/90 degree weather we’ve been having in Boston. Mochi (my Pomeranian) would […]
