Connector event triggers

Most enterprise connectors include trigger nodes that fire when something happens in the external service, a Slack message is posted, a Salesforce lead is created, a Stripe charge succeeds.

This page explains the common patterns. For the specific events each connector supports, see its page in the Connector catalog.

What's available

Sample of common connector triggers (full list per connector):

Each connector page documents its event list and per-event payload shape.

How they work mechanically

Two implementation styles:

Webhook-style triggers

The external service POSTs to a Flero-generated URL when the event happens. Low latency (seconds). Used when the service supports webhooks (most modern SaaS).

Flero handles:

• URL generation per trigger node.
• Registering / unregistering the webhook with the service when you activate / pause the workflow.
• Signature verification using the service's documented HMAC scheme.

Polling triggers

Flero checks the external service on a schedule (every 1–10 minutes, configurable) for new items. Higher latency (minutes). Used when the service doesn't offer webhooks, or when webhooks are unreliable / paid.

Each connector trigger documents which style it uses. Some support both, with a toggle.

Configuration patterns

Most connector triggers have a common configuration shape:

Plus event-specific config, e.g. Slack's message posted trigger has a "Workspace" and "Channel" picker; Salesforce's lead created has filter criteria.

Activating

1. Configure the trigger and credential.
2. Save the workflow.
3. Set workflow status to Active.
4. For webhook-style: Flero registers the webhook with the external service automatically.
5. For polling-style: the first poll happens immediately, then on schedule.

When the workflow goes inactive or archived, Flero unregisters the webhook (so the service stops sending). Polling stops accordingly.

Trigger payload

The payload shape is service-specific, see each connector page. Generally, expect:

• The event type / name.
• The affected entity (the message, the order, the lead).
• A timestamp.
• A unique event ID (useful for idempotency).

Most payloads land at $trigger.body.<service-fields>.

Webhook security

For webhook-style triggers, signature verification is done by Flero automatically using the service's secret. Find / rotate that secret under Settings → Credentials → → Advanced → Webhook signing secret.

If the signature check fails, the request is rejected with 401 and the workflow does not run. You'll see this in /logs under "Trigger rejections" if you've enabled that audit category.

Polling considerations

• Poll interval defaults to 5 minutes for most connectors. Lower it for time-sensitive events; raise it for cost-sensitive integrations.
• Polling counts as API calls against the external service's rate limit. Salesforce, Jira, HubSpot all have meaningful limits, be mindful.
• First poll after activating a workflow may return historical items. Most connectors have a "starting from now" option to suppress this.

Tips & gotchas

• Filtering on the trigger is cheaper than filtering in the workflow. Webhook-style triggers with a filter only fire when the filter matches; polling-style filters are applied client-side. Either way, fewer false-positive runs.
• Idempotency keys: use the event ID from the trigger payload as your idempotency key to handle the rare duplicate delivery.
• Multiple events per trigger. Some connectors let one trigger node listen to several event types (e.g. all *.succeeded Stripe events). The event type is in the payload, branch with a Switch node.
• Webhook registration can fail (insufficient scopes on the credential, the service rejects the URL). Check the trigger node's status chip after activating, it'll say "Registered" or show the error.

Related

• Connector catalog, per-connector event reference
• Webhook trigger, generic alternative when no connector exists
• Credentials & connectors

Found something out of date? This page lives in the Flero docs content set.