By default, an Update Records job only modifies raw records. No Items update or Destination Items update occurs automatically. You typically trigger these updates manually after verifying your records.
You can override the default behavior by providing on_success_trigger values as query parameters in your Update Records call. This instructs Bloomreach to automatically start downstream jobs after successful record updates.
Available triggers
Update items
When the Update Records job finishes successfully, Bloomreach automatically starts an Update Items job. This transforms your updated records into items using the current schema configuration.
POST .../records?on_success_trigger=update-items
Update destinations
When the Update Items job finishes successfully, Bloomreach starts an Update Destination Items job. This syncs the updated items to connected Discovery and Engagement catalogs.
POST .../records?on_success_trigger=update-destination-items
You can specify both triggers together:
POST .../records?on_success_trigger=update-items&on_success_trigger=update-destination-items
When to use automatic triggers
Use automatic triggers when:
-
Each record update leaves data in a consistent, transformation-ready state.
-
You want to reduce manual workflow steps.
-
Your updates are complete and don't require multiple stages to reach consistency.
-
You want your source updates to go directly to destination applications.
When not to use automatic triggers
Avoid automatic triggers when:
-
Your updates require multiple sequential calls to reach a consistent state.
-
You send partial data that becomes complete only after accumulating several updates.
-
You want to batch multiple small updates before transforming them into items.
-
You need to validate records before propagating changes downstream
Trigger behavior with concurrent jobs
If an Update Items job is already queued or running when another Update Records job completes with an update-items trigger, Bloomreach doesn't queue a duplicate Update Items job. The running or queued job will process all record changes that were completed before it began execution.
This means an Update Items job triggered by an early Update Records job might incorporate changes from later Update Records jobs if those jobs complete before the Update Items job starts processing. The updates still apply serially and in the expected order.