Skip to main content

Key configuration details for Conditional Actions to work correctly

In this article, we highlight what to consider when creating conditional actions to ensure field values and links are transferred as expected

Uspacy Support Team avatar
Written by Uspacy Support Team
Updated yesterday

Conditional Actions in Uspacy can automatically fill fields, transfer values between entities, and trigger workflows without manual effort. However, for automation to work as intended, it’s essential to configure fields, mappings, and data transfer rules correctly. Below are practical nuances that most often lead to unexpected behavior—and how to account for them in your setup.

Transferring values for List / Tag fields

Conditional Actions are often used to automatically transfer data between entities—for example, from a Deal to a Smart Object or from a Smart Object to a Task (when a value from one entity’s field needs to be written into a field of another entity). At first glance, this seems simple: “take the value here → write it there.” However, this is exactly where mistakes most often occur if you don’t consider how different field types work.

A critical nuance for List and Tag fields: when transferring values, the system does not compare the title you see in the interface (“Under review,” “Sold,” “Advance payment received”), but the internal ID of the value. So even if the titles in the Deal and the Smart Object look identical, the transfer may fail if those values were created separately and have different IDs.

How this works in our example:

In the deal card, we filled out the Translation types field with the value Written. When the deal moved to the Collaboration details stage, an element of our Smart Object was automatically created—a new Project. As you can see, the correct value was successfully transferred to the corresponding field in the project card (Translation types – Written).

Entity linking

When you configure a conditional action to transfer Contacts or Companies from a Deal to a Smart Object (that is, to re-link existing entities), it’s important to pass the entity ID, not the entity name.

This matters because relationship fields work through internal identifiers. The entity name is only a display value in the interface—it can be duplicated or changed—so transferring data by name may fail.

How this works in our example:

We linked our deal to the company Storm. When the deal moved to the Collaboration details stage, a new Smart Object element (a Project) was automatically created. As shown in the project card, the link to the same company was preserved correctly.

Transferring values for User fields

Similarly to entity-link fields, when transferring values for User-type fields (for example, Person responsible) via a Conditional Action, you must pass the user ID, not the user’s first and last name.

How this works in our example:

When the Conditional Action creates a Task, it takes the value of the Person responsible field from the Smart Object (Projects). The system substitutes the user’s ID—not their name—so the same employee is automatically assigned as responsible for the task.

If you have additional questions or you need to contact the support, send a request to this email [email protected]

Did this answer your question?