Winter ‘22: Prepare to test Dynamic Interactions

Published by Richard Clark, September 16, 2021

As part of the Winter ‘22 release Salesforce has made Generally Available (GA) a feature called Dynamic Interactions (DI). What surprised me about this is that the feature was previously only in Pilot and has been released not as a Beta (with features still pending), but fully supported, albeit with further features to come on the roadmap.

As this feature is now GA your Devs and Admins will likely start to leverage this functionality rapidly, like so many have already for Dynamic Forms and Actions. If you’re a QA expert you should expect to provide test coverage for Dynamic Interactions, which luckily for you are easier to test than traditional ways of delivering the same functionality with code.I’m getting ahead of myself, so let’s first recap what Dynamic Interactions are, and what you can (currently) do with them.

What are Dynamic Interactions?

Lightning App Builder Image

Figure 1 – Lightning App Builder, adding an interaction: 1 Select the type of interaction to execute; 2 Choose a target component on the same page to receive an interaction; 3 Customise the attributes of the component to set when the interaction fires, in this example an SObject to render; 4 a list view name to use to filter the records. The same component is reusable for different objects which is a popular LWC solution – DI makes it possible to dynamically change which object/list view is shown based on the choices made elsewhere on the page without creating and hiding/showing multiple versions of the component. The page loads much faster.

Like other dynamic features, Dynamic Interactions let you implement functionality, or business logic, that is conditional based on rules you set and which you control the behaviour declaratively through the Lightning App Builder.

For Dynamic Forms and Actions this is typically based upon the value of one or more related fields and/or user permissions. Overall, dynamic features let you master a single Lightning page (aka Flexipage) that can behave differently based on the specific data or user. This saves on using multiple page layouts, record types, and business processes when all you want to handle are some edge cases to your normal behaviour.

Dynamic Interactions in Winter ‘22 are ways in which you can publish an event (through simple code – at the moment), and configure the interactions you wish to occur to one or more components on a page. Previously, a developer was needed to deliver all such behaviour and every component needed to be a custom lightning component, ergo potential technical debt, extra development, extra testing, extra maintenance risk, and a higher total cost of ownership for using Salesforce.

To configure a Dynamic Interactions, an Admin user creates a new Lightning Page, edits an existing page using the App Page Builder, or by using the Edit Page link.

In Winter ‘22 you’ll need to rely on developers to make minor changes to their lightning web components to declare any events they want to publish, but they don’t need to amend any components you want to react to the changes, including standard out-of-the box components, 3rd party components or ISV provided components. Wow!

If that sounds exciting, then add in the fact that you can use DI to update attributes to any lightning component, whether they are Aura or LWC based, 3rd party or home grown. With Winter ‘22 this is limited to string/boolean attributes of a component, but Salesforce makes it very easy to see which attributes can be mapped in an interaction.

Interactions Details Image

Figure 2 – On this interaction we see a Record ID can be specified a literal text or expression can be passed, including any attributes included by the interaction event.

To connect these components the Admin simply needs to click on the source or publishing component, and they will observe a new tab for Interactions next to the properties of the component. Within this tab they can create one or more interactions to target other components on the page. For Winter ‘22 the component attributes are limited to text fields, but it’s reasonable to expect other data types to be supported in the near future.

Note: If you were part of the Summer ‘21 Pilot you will need to amend your source components before they work with Winter ‘22. For myself, this required edits to my DI event schemas to remove the “label” keyword and increase the API version to 53. I was able to redeploy my source component, edit the lightning pages where the component was used, re-add my interactions and re-run my Provar tests to verify the changes worked as before. Not surprisingly, I found DI to be even more reliable than the Pilot, and was able to reduce retry counts and wait times in my tests. I did hit issues with some 3rd party components, but those are bugs (in my opinion) exposed by my use.

Potential Use Cases

Below is an example of a page using DI that I recently demonstrated at the London Admin User Group:

Running Flexipage Image

Figure 3 – A running flexipage using Dynamic Interactions to update multiple components from a single source component list view. This includes 3rd party components from the AppExchange.

Hovering on a record on the lightning list view in the top section sends interactions to update a custom record detail lightning web component, a third party Twitter feed component and an Aura weather component both from the AppExchange. Once you add a source component that publishes events you only need to add interactions to map the event to other components and specify which attributes that you want to override when the event happens.

Flexipage selecting different record image

Figure 4 – Selecting a different record in the top component changes the content in each of the other components with no code required and no page refresh. You can specify when the event fires. I experimented with both row selection using clicks and hovers, both worked smoothly.

I was fortunate enough to be involved in the DI Pilot program, and there’s some very exciting things you could do including:

  • Developers can trigger DI events based on back end changes occurring elsewhere in your infrastructure which update UI components in real time.
  • Admins can create Dynamic Actions Bars* which, when activated by a user, changes which object’s data is displayed in a list view. For example, to show a list of Cases where you had a list of Accounts previously.
  • Users can avoid navigating multiple tabs to view data and see different details in a related record component depending on the data of the parent record they’re interacting with. Creating components that take an Object API name as an attribute and a Field Set name are great ways to increase component reuse.
  • As part of the pilot program I used DI to update free AppExchange components to show Twitter feeds for a Contact or Account, to show the weather in a customer’s location, their location on a map and their full detail record. I could also have used it to update a visual component showing an account balance or payment history related list from SAP, for example.
  • I suspect another popular solution will be to include the filtering of lists based on selected records or actions. Imagine clicking an Overdue button and instantly seeing all the related lists on the page update to only show the applicable items! Likewise for filtering data by a related date (e.g. This Month).

All of these changes happen at the component and not at the page level. That means that there’s no need to issue a page navigation prior to asserting the change has completed. You might need a very small wait (less than 0.1 seconds) or let Provar handle the retry for you and just reduce the retry time and attempts (3 strikes is plenty in my opinion).

* Note: Dynamic Actions Bar is a pilot feature in Winter ‘22 and only available on custom App Pages (not available forRecord or Home pages. You will need to contact your Salesforce Account Manager to request access to join any Pilot program, and it is not recommended to use Pilot features in Production, as they are not guaranteed to become part of the platform in the future.

Why should QA teams care?

I’ve put some pretty one sided pros and cons here:

  1. You’re going to have more scenarios to test (groan!) to achieve coverage for the customisations, and your Salesforce teams will be able to deliver even more, faster.
  2. Using event based integration makes components loosely coupled. This means if a developer makes a change to a source component which issues an event they may have little idea of the potential consequences, and are unlikely to be checking for impact in their unit tests (sigh!). QA to the rescue once more!
  3. If you had such functionality previously you probably had multiple components, one per object plus one for every different type of component (list, related record, graphical display). Your team can now reduce that to fewer components of each type and this means you’ll actually have less components that need test coverage (woohoo!)
  4. With the above optimisations I’d argue you don’t have to test every scenario on every object entity. Again, this could mean you have less scenarios to execute (wahay!)
  5. Because DI are dynamic, you can reuse the same test using Provar’s data driven support to automatically test multiple scenarios and objects simply by adding data rows to your parameter value source file. Provar provides LWC locators that can bind to a component’s metadata attributes, not the field’s label, Id or page DOM tree (boom!)
  6. If there is a bug in the component you have a much greater chance of finding it if the component is reused, than if you’re testing multiple components (yay!). Your developers and admins also only need to fix the bug once (double yay!).


I personally find all the Dynamic features from Salesforce hugely empowering for admins and exciting for stakeholders too. User experience can become more synonymous with Tableau so that users expect stuff to happen when they hover and click without needing special training on every page in your app. More importantly, rapid development of features can be delivered into production in hours and days instead of weeks and months.

Quality Assurance should never be overlooked, and using Provar, which makes it as easy to create and run tests as using Salesforce itself, reduces the cost of testing and speeds up delivery cycles without compromising quality or skipping on governance.

Further Information

Details about building Dynamic Interactions can be found in the Salesforce Winter ‘22 Release Notes here and here.

I’d also recommend this recent Salesforce Blog post about it here. Note that features change over time and you should always consult the latest Help pages for up to date feature information from Salesforce.

Details of the combination of Dynamic Actions Bar (Pilot) and Dynamic Interactions can be found here to whet your appetite for the future.


Images courtesy of Winter ‘22 release notes, Provar Limited and publicly available content.

We use cookies to better understand how our website is used so we can tailor content for you. For more information about the different cookies we use please take a look at our Privacy Policy.

Scroll to Top