Alias Names for Custom Action in AJO

​@Vijaya-Vigneshan I agree.

The core issue is the lack of a persistent, user-friendly identifier—such as an alias or a stable name—for custom actions. Currently, their primary identifier is a system-generated ID, which changes whenever the custom action is duplicated or modified in a way that necessitates a new version (as is often the case when structural updates are required).

Proposed Enhancement: Persistent Custom Action Identifier

We should introduce an alias or a permanent identifier for every custom action. This identifier must remain constant for the entire lifecycle of the custom action, even if the underlying definition or logic is updated.

• Stability and Maintainability: This persistent alias would serve as the primary reference point across all journeys/emails.
• Automatic Reflection of Changes: Ideally, any change to the custom action's definition—including changes to its payload (e.g., adding a new field like product_rating)—should be allowed and seamlessly reflected in all consuming journeys and messages.

The Current Pain Point,

Consider the scenario involving a custom action named "Product Metadata Service." This service is used within a journey's email message to dynamically retrieve and personalize content such as:

• product_price
• product_image_url
• product_in_stock_status

This personalization is implemented using the custom action's request/response fields within the email's content (e.g., using AJO personalization tokens).

If a necessary change arises—for instance, the service needs to be updated to also return the product_rating—the current process is highly inefficient and error-prone:

1. Duplication Requirement: Because the current platform often requires duplication to implement significant changes (which results in a new system ID), the original custom action becomes obsolete.
2. ID Change and Broken References: The new, updated custom action has a completely new, unique system ID. This breaks every existing reference within active journeys and, within the email's personalization logic.
3. Manual Remediation: To fix this, the user must manually navigate to every single journey and every single email template that utilized the old custom action ID and replace it with the new custom action ID. 

Desired State: Seamless, Automatic Updates

The ideal state is one where updates to a custom action are automatically propagated:

• The user updates the "Product Metadata Service" custom action.
• Because the action's alias ("Product Metadata Service") remains the same, all journeys and emails continue to reference it correctly.
• Any new fields added to the custom action's response (e.g., product_rating) immediately become available for use in the personalization interface without checking the custom action id’s and just require an update to the email to include product_rating.

​@Sukrity_Wadhwa Can we move this to ideas section? or Should we create a new one?

hi ​@Vijaya-Vigneshan,

If the sequence is Custom Action 1 followed by Custom Action 2, you can use the fields Previous Node ID or Previous Node Name from the journey properties available in the activities, instead of hardcoding the values. This way, whenever you create a new custom action and start using it, it will automatically refer to the new custom action in the next custom action.

Warm Regards,

Reena John