Metadata Type: InvocableActionExtension
InvocableActionExtension is a metadata type in Salesforce that represents the configuration for defining how an invocable action's inputs and properties are presented in a user interface, particularly within Flow Builder. This metadata type allows organizations to customize the property panel experience for administrators and developers working with specific Apex actions, enhancing usability and declarative configuration.
Overview
The InvocableActionExtension metadata type was introduced in API version 65.0 and is a key part of Salesforce's efforts to provide a more tailored and intuitive experience when configuring complex Apex actions in Flow. It enables developers to control vertical display sequences, group input parameters into collapsible sections, define static or dynamic picklist values, and even assign Lightning Web Components (LWCs) as partial custom property editors or custom headers for actions.
Key Features
- Custom UI configuration for invocable action property panels in Flow Builder
- Support for defining picklists (static or dynamic) for input parameters
- Ability to group and order input parameters for better scannability
- Integration with Lightning Web Components for custom headers and custom property editors
Structure and Components
An InvocableActionExtension typically consists of the following components:
- Targets: The specific target of the extension, which dictates the type of component being modified (e.g., ActionDefinition, ActionParameter, TypeDefinition, or TypeProperty).
- Target Name: The exact name of the targeted component or parameter.
- Attributes: The list of configuration attributes containing the specific behaviors and properties.
- Key-Value Pairs: Specific configurations like Order, GroupName, CpeName (Custom Property Editor), or ProvidedValueList, mapped to defined data types.
Deployment Considerations
When deploying InvocableActionExtension metadata, administrators should be aware of several potential issues:
1. Base Action Dependencies
Ensure that the underlying invocable actions, custom Apex types, or parameters referenced in the target names exist in the destination org. Deploying an extension for an action that hasn't been deployed will result in a failure.
2. Lightning Web Component Availability
If utilizing attributes like CpeName or CustomHeaderLwcName, verify that the referenced Lightning Web Components are included in the deployment package or already exist in the target org.
3. API Versioning
Because this type was introduced in API version 65.0 (with new key additions in 67.0), confirm that your deployment manifests (package.xml) use a compatible API version to prevent the metadata from being ignored or failing validation.
4. Valid Target Types
Be cautious when assigning target types and names. Ensure the targetName syntax (e.g., ActionName.inputParameter) perfectly matches the Apex class structure to avoid detached or malfunctioning UI configurations.
5. Data Type Mismatches
Verify that the value provided for an attribute matches the required data type (e.g., Boolean, Integer, String). Passing a string into an attribute that expects an integer (like the Order key) will cause deployment errors.
Best Practices for Salesforce Administrators
To effectively use and manage InvocableActionExtension metadata, Salesforce administrators and developers should follow these best practices:
1. Document Your Extensions
Maintain clear documentation of all action extensions, especially when using complex Lightning Web Components as custom property editors. This documentation is vital for other developers who need to update or debug the Flow UI.
2. Group Logically
Leverage the GroupName key to bundle related input parameters into collapsible sections. This greatly improves the user experience for Flow builders navigating actions with numerous inputs.
3. Provide Value Lists for Consistency
Use the ProvidedValueList key to offer static or dynamic picklists for string parameters. This prevents typos and invalid data entry by restricting what Flow builders can input into the action configuration.
4. Leverage Sandboxes
Always build and test UI modifications for your invocable actions in a sandbox environment. Verify how the property panel renders in Flow Builder before deploying to production to ensure the layout makes sense.
5. Control Parameter Visibility
Use the ControllingField key to conditionally display input parameters based on the presence of other inputs. This keeps the property panel clean and guides users through a logical configuration path.
6. Version Control
Store your `.invocableactionextension` files in your source control repository alongside their corresponding Apex classes. This ensures that logic and its corresponding UI configuration are versioned and deployed together.
7. Use Order Attributes Strategically
Explicitly define the vertical display sequence of your parameters using the Order key. Prioritize the most critical or required inputs at the top of the panel to streamline the builder's workflow.
8. Modularize Custom Editors
When using CpeName, build your Lightning Web Components to be reusable where possible. Linking an input parameter to be controlled by another's custom property editor (using ConfiguredBy) can save development time.
9. Error Handling in Dynamic Picklists
If referencing an Apex class for dynamic picklist values (apex://MyDynamicPicklistClass), ensure that class has robust error handling so it doesn't break the Flow Builder UI if external data or queries fail.
10. Training and Documentation
Provide enablement sessions for your declarative automation team (Flow builders) when introducing heavily customized action panels. Showing them how the new grouped, ordered, and picklist-driven UI works will increase adoption and efficiency.
Conclusion
The InvocableActionExtension metadata type is a powerful asset for Salesforce teams looking to bridge the gap between complex Apex development and declarative Flow building. By customizing how action inputs are presented, grouped, and validated, developers can provide a significantly improved user experience for administrators. As with any metadata configuration, careful planning, strict alignment with the underlying Apex, and thorough sandbox testing are essential to maintaining a clean and functional Flow Builder environment.