Trigger on Database Update

	Component	Type	Description
	Trigger on Database Update	▶️ trigger	trigger a workflow when a record is created, updated, or deleted in a Workflow86 database

The Trigger on Database Update component allows you to automatically start a workflow whenever changes occur in a Workflow86 database. This enables you to build reactive workflows that respond to data changes in real-time.

When to Use

This component is ideal for:

• Data synchronization: Keep external systems in sync when database records change
• Notifications: Send alerts when specific records are created or modified
• Audit trails: Log all changes to important data
• Cascading updates: Trigger additional processing when data changes
• Approval workflows: Start review processes when new records are submitted

Configuration

Select Database

Choose the Workflow86 database you want to monitor for changes. The dropdown displays all databases available in your workspace.

Trigger Events

Select which database events should trigger the workflow:

Event	Description
Record Created	Triggers when a new record is inserted into the database
Record Updated	Triggers when an existing record is modified
Record Deleted	Triggers when a record is removed from the database

You can select one or more events. The workflow will trigger whenever any of the selected events occur.

Output Placeholder

Configure the placeholder key that will contain the record data. When the workflow triggers, this placeholder contains a JSON object with both the old and new record states:

{
  "new": {
    "recordId": "row_abc123",
    "sessionId": "session_xyz",
    "Column A": "new value",
    "Column B": "another value"
  },
  "old": {
    "recordId": "row_abc123",
    "sessionId": "session_xyz",
    "Column A": "previous value",
    "Column B": "another value"
  }
}

• new: The record data after the change. Contains recordId, sessionId, and all column values. For deleted events, this will be null.
• old: The record data before the change. Contains recordId, sessionId, and all column values. For created events, this will be null.

This structure allows you to easily compare what changed by examining both the old and new values.

How It Works

1. Publish your workflow - The trigger only becomes active after the workflow is published
2. Database change occurs - A record is created, updated, or deleted in the selected database
3. Workflow triggers - A new workflow session starts automatically
4. Data is passed - The record data and event details are available in the output placeholder
5. Workflow executes - Subsequent components process the data

Database change occurs
    ↓
Event matches configured triggers?
    ↓ Yes
New workflow session starts
    ↓
Record data passed to output placeholder
    ↓
Workflow continues to next component

Example Use Cases

Send notification on new submission

When a new record is created in a "Submissions" database:

1. Trigger on Database Update (Record Created) monitors the database
2. Email component sends notification to the team
3. Create Record component logs the notification in an audit database

Sync data to external system

When any record changes in a "Customers" database:

1. Trigger on Database Update (Record Created, Record Updated) monitors changes
2. API Request component sends the updated data to an external CRM
3. Update Record component marks the record as synced

Archive deleted records

When records are deleted from a "Projects" database:

1. Trigger on Database Update (Record Deleted) captures deletions
2. Create Record component saves the deleted data to an "Archived Projects" database
3. Email component notifies the project owner

Detect and log specific field changes

When you need to track changes to specific fields (e.g., status changes):

1. Trigger on Database Update (Record Updated) monitors the database
2. Use a Code component or Conditional Logic to compare old.Status with new.Status
3. If the status changed, log the change or send a notification with both old and new values

Best Practices

1. Be specific with events - Only select the events you need to avoid unnecessary workflow executions

2. Use conditional logic - Add a Conditional Workflow component after the trigger to filter which records should continue through the workflow

3. Handle high-volume databases carefully - If the database receives many updates, consider adding rate limiting or batching logic

4. Test with draft data first - Before publishing, ensure your workflow handles the data structure correctly

5. Consider cascading triggers - If your workflow updates the same database, be careful to avoid infinite loops. Use conditions to prevent re-triggering on your own updates

Avoid Infinite Loops

If your workflow updates the same database it's monitoring, you could create an infinite loop. Add conditions to check if the update was made by your workflow before processing.

Troubleshooting

Issue	Possible Cause	Solution
Workflow not triggering	Workflow not published	Publish the workflow to activate the trigger
Missing record data	Wrong event type selected	Ensure you've selected the correct event types
Trigger fires unexpectedly	Multiple event types selected	Review which events are enabled
Infinite loop	Workflow updates same database	Add conditional logic to prevent re-triggering
Delayed triggers	High system load	Triggers are processed in near real-time but may have slight delays during peak usage

important

Workflow must be published

The workflow must be published before the database trigger becomes active. Changes to unpublished workflows will not trigger any workflow sessions.

Database must exist

The selected database must exist and be accessible. If the database is deleted, the trigger will stop working.