Skip to content

Event Triggers

Event triggers let a workflow react to activity in a connected service. Instead of checking on a schedule, GloriaMundo subscribes to the service and runs the workflow when the matching event happens.

That makes event-triggered workflows useful for tasks that should run as soon as something changes. A GitHub workflow can start when a new commit is pushed. A Gmail workflow can start when a message arrives. A Slack workflow can start when a message is posted in a channel you follow.

If you have seen Composio Event in the current builder, that is the same feature described on this page.

When to use event triggers

Use an event trigger when the service already knows about the event you care about and can notify GloriaMundo directly.

Examples:

  • A GitHub workflow that runs when a new commit is pushed to a specific repository
  • A Gmail workflow that runs when a new message matches a mailbox or label filter
  • A Slack workflow that runs when a message appears in a specific channel

This is different from a scheduled workflow. A schedule wakes up every few minutes or hours and checks for new work. An event trigger waits quietly until the service sends the event, then starts immediately. That means lower delay and no wasted polling.

If the service does not support the exact event you need, use a scheduled workflow instead.

Choosing the right trigger type

GloriaMundo supports four main trigger types:

  • Manual: you start the workflow yourself.
  • Scheduled: GloriaMundo runs it on a timetable.
  • Webhook: an external system sends an HTTP request to a URL you control.
  • Event: GloriaMundo subscribes to a connected service and starts the workflow when that service emits a matching event.

As a rule of thumb, use:

  • Event when the service already offers the event
  • Scheduled when you need polling or a recurring job
  • Webhook when another system will call your endpoint directly
  • Manual when you want to run on demand

Setting up an event trigger

Open the trigger picker in the builder and choose the event option. In the current UI, that opens the event trigger panel with four parts:

  1. App: choose the connected service, such as GitHub, Gmail, Slack, or Google Calendar.
  2. Trigger: choose the event from that app's trigger catalogue.
  3. Connected account: choose which account should own the subscription.
  4. Config fields: fill in any event-specific settings that narrow the subscription.

Some triggers need no extra configuration. Others do. A GitHub commit trigger usually needs a repository owner and name. A Gmail trigger may need a label or mailbox filter. A calendar trigger may need a specific calendar or response type.

Here is a typical event-trigger configuration as it appears in the picker:

Type: Event
App: GitHub
Trigger: GITHUB_COMMIT_EVENT
Connected account: engineering@company.com
Config:
  owner: vlogbaseltd
  repo: GMRebuildApr2025

After you save the trigger, the workflow still needs to be enabled before it can run live.

What happens at activation

Building the workflow is only the first step. Event-triggered workflows do not start listening the moment they are created.

When you enable the workflow, GloriaMundo creates the subscription with the upstream service. Until that subscription is active, the workflow will not fire. In most cases this completes within a few seconds.

Once activation finishes, the workflow waits for real events from that account and configuration. If you later disable the workflow, GloriaMundo stops using that subscription.

Virtual Run for event triggers

Manual, scheduled, and webhook workflows can often be previewed with real or user-provided trigger data. Event triggers are different because there is no live event payload available while you are still building.

For Virtual Run, GloriaMundo uses a representative sample payload from the trigger catalogue. That lets you inspect how downstream steps will read fields from the event before the workflow is live.

The sample payload is meant to be realistic, not random. It shows the general shape of the event so you can confirm that your later steps are reading the right fields, filters, and destinations.

Common mistakes

The most common problems are simple:

  • Forgetting to enable the workflow: saving the workflow is not enough. Event-triggered workflows only start listening after activation.
  • Picking the wrong account: if you have more than one account connected for the same service, the subscription belongs to the account you choose in the trigger picker.
  • Confusing event triggers with webhooks: event triggers are managed subscriptions on known services. Webhooks are generic HTTP endpoints that another system calls directly.
  • Using a schedule when an event already exists: if the event is available in the picker, the event trigger is usually the better fit.