Moving Beyond Scheduled Syncs: Event-Driven Automation with Ouvvi

Scheduling gets you a long way, but some workflows need to respond to things happening rather than waiting for a timer. Here's how Ouvvi's trigger system makes that possible.

View All Blog Posts

Scheduling is the right starting point for most automations. Set a job to run every hour, every night, or every Monday morning, and for many workflows that's perfectly sufficient. But as your integrations grow, you start to encounter situations where a schedule isn't quite right.

A new order arrives and it needs processing immediately. A file drops into a folder from a third-party supplier. A support ticket gets a reply that should route to another system. A project fails and nobody knows until someone checks the logs the next morning.

These aren't problems a schedule solves well. What you need is automation that responds to things happening, not automation that runs on a timer and hopes something has changed. That's what Ouvvi's event based triggers are for.

How Triggers Work

Before getting into the different trigger types, it's worth understanding how they all work.

Every trigger in Ouvvi works by returning a timestamp, which is checked every 30 seconds. If it's newer, the trigger fires and any linked projects start running. If it's the same, nothing happens.

This means that whether you're watching a database table, a file on disk, or a remote API, the question Ouvvi is always asking is the same: has something advanced since I last checked? When the answer is yes, your workflow starts.

Watching Your Data

The most powerful triggers for most teams are the ones that watch data sources directly.

SQL Trigger

The SQL trigger runs a query against any SQL Server, OleDb, or ODBC-compatible database and fires when the returned value changes. The query should return a DateTime or timestamp, typically the maximum value of a date column on a table you're monitoring.

For example, SELECT MAX(CreatedDate) FROM Orders will fire the trigger whenever a new order is added. SELECT MAX(ModifiedDate) FROM SupportTickets fires when a ticket is updated. SELECT MAX(ReceivedDate) FROM Emails WHERE IsReply = 1 detects incoming replies to your helpdesk.

This is the trigger to reach for when your data lives in SQL and you want workflows to start the moment something changes, rather than waiting for the next scheduled run.

SharePoint and SharePoint Online Triggers

Both on-premise SharePoint and SharePoint Online have dedicated triggers that watch a specific list for changes. When the list's last modified timestamp advances, because a new item was added or an existing one was updated, the trigger fires.

Useful for workflows that respond to form submissions, approval requests, document updates, or any process that flows through a SharePoint list.

Dataverse, Salesforce and OData Triggers

For teams using Dynamics 365, Dataverse, or Salesforce, dedicated triggers watch entities and objects for changes. An OData trigger covers any OData-compatible endpoint. These follow the same pattern: watch for a newer timestamp, fire when one appears.

Practical use cases include syncing new or updated CRM records, responding to stage changes in a sales pipeline, or picking up new cases as they're raised.

Watching Files and Folders

For workflows that involve file-based data exchange, such as supplier imports, batch processing, or third-party drops, file-watching triggers are the right tool.

File Trigger

Watches a specific file on disk and fires when its last modified timestamp changes. Supports an optional delay between detection and firing, which is useful when you're dealing with large files that take time to finish writing before they're safe to process.

A typical use case is a nightly export from a third-party system that lands in a known location. Rather than scheduling a sync at a fixed time and hoping the file has arrived, the File trigger sets the projects going as soon as it does.

Folder Trigger

This is similar to the File trigger, but watches an entire directory. It tracks the most recent write or creation time across all files in the folder and fires when any file is newer than the last check. Useful when the filename isn't predictable, such as a drop folder where different files arrive at different times.

A supplier that sends differently named export files each day, a folder where automated reports are deposited, or an inbound processing queue for scanned documents are all good candidates.

FTP Trigger

The same file-watching mechanic, but for a file on a remote FTP server. Supports SSL, passive mode, and configurable timeouts. If you're still exchanging data with partners over FTP (and plenty of organisations are), this trigger means you can respond to updated files without polling on a fixed schedule.

Reaching Out to External Sources

Some triggers work by calling external endpoints and watching for a change in what they return.

JSON Trigger

Calls a remote URL (GET or POST), parses the JSON response, and uses a JSONPath expression to extract a DateTime value. Fires when that value advances.

This is useful for monitoring REST APIs that expose a last-updated or last-modified field. For example, an order management system that returns {"lastOrderTime": "2025-06-01T14:32:00"} in a status endpoint. Point the JSON trigger at that field and your workflow starts the moment a new order is recorded.

HTTP Trigger

Calls a URL and expects a plain DateTime back as the response body. Simpler than the JSON trigger and suited to lightweight internal endpoints or custom monitoring pages that return a timestamp indicating when data last changed.

Program Trigger

Runs an external executable or script and reads a DateTime from its standard output. Fires when the returned DateTime advances beyond the last stored value.

This is the option to reach for when the other triggers don't cover your use case. If you can write a script in PowerShell, Python, or anything else that checks a condition and outputs a timestamp, you have a trigger. Custom API integrations, proprietary system checks, or unusual data sources that don't fit the standard connectors can all be handled this way.

Atom Trigger

Watches an Atom or RSS feed and fires when the feed's modified date advances. Less commonly needed, but useful if you're monitoring external content sources, news feeds, or third-party services that publish update feeds. If a supplier or partner publishes an Atom feed of their product updates or order notifications, this trigger can start your import workflow the moment new content appears.

Reacting to Ouvvi Itself

Ouvvi Project Error Trigger

This one is different from the others. Rather than watching an external system, it watches Ouvvi itself, specifically it tracks the most recent project failure across your entire instance and fires when a new one is recorded.

The practical use for this is automated alerting or escalation. Rather than relying on someone checking the monitoring view each morning, you can attach a notification project to this trigger and have Ouvvi tell you the moment something fails. Combine it with the queue system and you have a starting point for automated recovery workflows: detect the failure, notify the right person, and queue a retry once the issue is resolved.

Putting It Together

The trigger system means Ouvvi can sit at the centre of workflows that respond to things happening rather than just running on a timer. A new order detected by a SQL trigger kicks off a fulfilment sync. A file arriving in a folder triggers a data import. A project failure fires a notification. A reply arriving in a helpdesk table routes to the right team.

Each of these can also feed into Ouvvi's queue system, so if a triggered workflow fails, it doesn't just disappear. It retries, and if it exhausts its retries, it lands in the queue failure table waiting for action, exactly as described in our previous post on the queue system.

For the full list of trigger types and their configuration options, the Ouvvi trigger documentation covers each one in detail. And if you're looking at a workflow that doesn't seem to fit what you've read here, reach out to us, there's usually a way.

By Rebecca Allen | Monday, July 6, 2026 | Permalink