Overview
The Custom Attribute Updated trigger starts a workflow whenever a custom attribute value changes on a booking, customer, resource, partner, or user. It provides the entity, the attribute definition, and both the previous and new values — so you can automate responses to any data change.
When It Triggers
A custom attribute value is created or updated on any supported entity type
The trigger fires once per value change (one attribute, one entity)
Both the old and new values are captured at the moment of the change
Use Cases
Send a welcome email when a customer's "VIP Status" is set to "Yes"
Notify a manager when a booking's "Follow-up Status" changes to "Needs Review"
Update a CRM or external system when a partner's "Tier" changes
Log attribute changes for auditing purposes via a webhook
Automatically set related attributes when a specific value is selected
Send an SMS when a resource's "Availability Status" changes to "Unavailable"
Configuration
This trigger requires two configuration fields:
1. Model
Select which entity type to watch for attribute changes:
Booking
Customer
Partner
Resource
User
2. Attribute
After selecting a model, choose which specific custom attribute to monitor. The dropdown shows all custom attributes defined for the selected entity type in your business unit.
If no custom attributes exist for the selected model, a message will prompt you to create one first via the Attributes page.
Note: Each trigger instance watches one specific attribute on one entity type. To monitor multiple attributes, create separate workflows for each.
Available Data
When this trigger fires, it provides context data from the entity plus attribute-specific fields.
Custom Attribute Fields
Field | Description |
| ID of the attribute definition |
| Display name of the attribute (e.g. "VIP Status") |
| Slug identifier (e.g. "vip-status") |
| Attribute type (text, number, select, status, etc.) |
| The previous value before the change (null if newly set) |
| The new value after the change |
Entity Context
Depending on the model you selected, the trigger also includes the full entity context. For example:
Booking — all booking fields (
booking.id,booking.status,booking.date, customer info, product info, etc.)Customer — all customer fields (
customer.id,customer.name,customer.email,customer.phone, etc.)Partner — all partner fields (
partner.id,partner.name,partner.email, etc.)Resource — all resource fields (
resource.id,resource.name, etc.)User — all user fields (
user.id,user.name,user.email, etc.)
These are the same context objects used by other triggers (e.g. Booking Confirmed, Customer Created), so you have access to all the same fields for conditions and actions.
Accessing Data in Workflows
{custom_attribute_definition.id}
{custom_attribute_definition.name}
{custom_attribute_definition.slug}
{custom_attribute_definition.type}
{old_value}
{new_value}
{customer.name}
{customer.email}
{booking.id}
{booking.status}
Example Workflows
1. VIP Welcome Email
Workflow Steps:
Trigger: Custom Attribute Updated (Customer → "VIP Status")
Condition: If
{new_value}equals "Yes"Action (True): Send Notification — welcome email to
{customer.email}
2. Follow-Up Status Alert
Workflow Steps:
Trigger: Custom Attribute Updated (Booking → "Follow-up Status")
Condition: If
{new_value}equals "Needs Review"Action (True): Send Notification — alert the operations team
3. Sync Changes to External System
Workflow Steps:
Trigger: Custom Attribute Updated (Customer → "Tier")
Action: Send Webhook with
{customer.id},{new_value}, and{old_value}to your CRM endpoint
4. Auto-Tag Repeat Guests
Workflow Steps:
Trigger: Custom Attribute Updated (Customer → "Visit Count")
Condition: If
{new_value}is greater than 2Action (True): Update Customer — set "Loyalty Tier" to "Repeat Guest"
Testing
When testing this trigger in the workflow editor:
Select the entity type (must match the trigger configuration).
Select the attribute definition to test with.
Select a specific entity (e.g. a particular customer or booking) by ID.
The workflow runs using the entity's current attribute value as both old and new value (simulated change).
Review the execution logs to verify that the context data (entity fields, attribute info, old/new values) appears as expected before activating the workflow.
Best Practices
One attribute per workflow — each trigger watches a single attribute. Create separate workflows for different attributes to keep logic clean.
Use conditions on new_value — filter on the new value to only act on meaningful changes (e.g. only when status changes to a specific option).
Compare old and new — use both
{old_value}and{new_value}in conditions to detect specific transitions (e.g. from "Pending" to "Approved").Combine with Update actions — pair this trigger with Update Customer or Update Booking to set related attributes automatically.
Test before activating — always test with a real entity to confirm the context data matches your expectations.
Related Documentation