ThingWorx Flow > Creating and Managing Triggers
Creating and Managing Triggers
A trigger is a specialized action that you can configure on of a workflow to define when the workflow is executed automatically. You can automate complex business processes without running the workflow manually. There are two types of triggers:
Polling triggers
Check the external system periodically for specific changes. If changes adhere to the trigger configuration criteria, then the workflow is initiated.
By default, polling triggers run every 5 minutes. To modify the default trigger time, edit the value of the DEFAULT_HOOK_INTERVAL parameter in the trigger deployment configuration file, deploymentConfig.json file that is available under the <ThingWorx Flow Installation Folder>\modules\trigger\ folder. This value is defined in milliseconds. It is recommended that you use small intervals for short-term testing only.
For some cloud services such as Google, if you set the polling interval below a threshold value, for example, 1000 milliseconds, the Google service may automatically refuse requests for your account and you may have to contact Google to restore access to your account. Check with your third-party service provider if they have any restrictions on such requests.
All the polling triggers are marked with in the triggers list. The following connectors support polling triggers:
Webhook triggers
Register a call-back with the external system so that whenever the specified event occurs on that system, that system calls into ThingWorx to start the workflow. For webhook triggers to work, ThingWorx Flow must be accessible from third-party systems.
The following connectors support webhook triggers:
Best Practices for Trigger Configuration
It is recommended (whenever possible) that you use non-polling or webhook triggers that are fired directly only when the subscribed event occurs. This reduces the load on the subscribed system and on ThingWorx while ensuring that a workflow is executed as soon as the subscribed event occurs.
With polling triggers, the ThingWorx subscription services must make regular requests to the connected system to support the polling trigger subscriptions (at the configured polling interval). With the increase in requests across the subscribed systems, the load on the subscribed systems and on the ThingWorx subscription service increases.
Was this helpful?