Deployment Process
Overview
This page explains how Avonni Dynamic Components are stored within Salesforce and how you can easily deploy them between your different Salesforce environments (e.g., from a Sandbox to Production, or between developer orgs).
One of the key advantages of Avonni Dynamic Components is their portability. Because they are built and stored natively on the Salesforce platform, moving your custom-built components between organizations is straightforward using standard Salesforce deployment tools.
How Dynamic Components are Stored
When you create and save a Dynamic Component in the Avonni Component Builder, its entire definition is stored as a record in a specific Custom Metadata Type (CMDT) provided by the Avonni managed package.
Where Your Component's Code Lives
Think of this Custom Metadata record as the source code and structure of your Dynamic Component—everything from layout and data sources to visibility rules and interactions is encoded in this metadata. It’s essentially where your Dynamic Component “lives.”
For example, if you create a component like “Account Dashboard,” it will be stored as a single record within the Avonni Dynamic Component CMDT (e.g., avonnidc__Dynamic_Component__mdt
).
Using CMDT for storage is what makes Avonni components highly portable and compatible with Salesforce’s native deployment infrastructure.

Deployment Workflow
The typical process for deploying Dynamic Components follows standard Salesforce best practices:
Build & Test Create and configure your Dynamic Component in a source org (such as a Sandbox), then thoroughly test it. Don’t forget to Save and Activate it in the Avonni Component Builder.
Identify Components Determine which specific CMDT records (i.e., component definitions) need to be deployed.
Choose a Deployment Tool Select from tools such as Change Sets, Salesforce DX (SFDX), Ant, or third-party solutions like Gearset or Copado.
Include CMDT Records Add the necessary CMDT records to your deployment package. These records will be listed under the CMDT name (usually something like
avonnidc__Dynamic_Component__mdt
—confirm this in your org).Deploy Deploy the metadata using your chosen tool.
Verify & Configure in Target Org
Confirm the CMDT records deployed correctly.\n- Open the Avonni Components App in the target org to locate your deployed components.\n- Activate them within the builder if they appear in a “Draft” state.\n- Use the Lightning App Builder to place them on Lightning pages
Using Common Deployment Tools
Change Sets
Create an Outbound Change Set.
Under Component Type, choose Custom Metadata Type.
Add the specific CMDT records for your Dynamic Components.
Include any dependent components (e.g., Apex classes, Flows, referenced fields).
Upload and deploy the Change Set to your target org.
Salesforce DX (SFDX)
Ensure your
package.xml
manifest file includes the Custom Metadata Type for Avonni Dynamic Components. It will look something like this (verify the exact nameAvonni_Dynamic_Component__mdt
in your org)
<types>
<members>*</members>
<name>CustomMetadata</name>
</types>
<types>
<members>Avonni_Dynamic_Component__mdt.*</members>
<name>CustomObject</name>
</types>
(Note: CMDT records are often retrieved/deployed via the CustomObject metadata type definition in package.xml) Alternatively, or for more granularity, you might reference the specific records within the CustomMetadata type entry if you only want to deploy specific components.
Use SFDX commands (
sf project retrieve start
/sf project deploy start
) to retrieve the CMDT records from the source org and deploy them to the target org.
Third-Party Tools
Tools like Gearset and Copado fully support CMDT deployment. Select the appropriate Avonni CMDT records and follow your tool’s deployment flow.
Important Considerations
Activation in Target Org: Deployed components often arrive in a 'Draft' state in the target org. You will likely need to open them in the Avonni Component Builder in the target org and Activate them before adding them to Lightning Pages.
Dependencies: Ensure any underlying components your Dynamic Component relies on (custom objects, fields, Apex classes called by interactions, Flows, etc.) are also included in your deployment or already exist in the target org.
Permissions & Licenses: Verify that users and administrators in the target org have the necessary Avonni licenses and permission sets assigned to use the builder and view the deployed components.
Managed Package Updates: Ensure both the source and target orgs are on the same (or compatible) version of the Avonni Dynamic Components managed package before deploying component definitions.
In Summary
Avonni Dynamic Components are stored as Custom Metadata Type records—essentially the "code" and "structure" of your components. This design enables easy deployment using Salesforce-native and third-party deployment tools. By treating your components like metadata assets, you can confidently manage their lifecycle across multiple environments with speed and precision.
Last updated
Was this helpful?