> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getoperate.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Triggering Flows

> Flows can be triggered in 7 ways.

On-demand triggers:

* [Auto-generated UIs](#)
* [Customized UIs with the App Editor](#)
* [Schedule the Execution of a Flow](#)
* [Trigger Flows from CLI (Command Line Interface)](#)
* [Trigger a Flow from another Flow](#)

Triggers from external events:

* [Scheduling + Trigger Scripts](#)
* [Trigger Flows from Webhooks](#), including from [Slack](#) or [Emails](#)

## On-demand Triggers

### Auto-generated UIs

getOperate automatically generates user interfaces (UIs) for scripts and flows based on their parameters.

By analyzing the main function parameters, it creates an input specification in the JSON Schema format,
which is then used to render the UI. Users do not need to interact with the JSON Schema directly,
as getOperate simplifies the process and allows for optional UI customization.

This feature is also usable directly in the script editor to test a flow in the making:

<Card title="Auto-generated UIs" href="#">
  getOperate creates auto-generated user interfaces for scripts and flows based on their parameters.
</Card>

### Customized UIs with the App Editor

getOperate provides a WYSIWYG app editor. It allows you to build your own UI
with drag-and-drop components and to connect your data to scripts and flows in minutes.

<Card title="App Editor" href="/developer/manual/app">
  Detailed section on getOperate's App Editor
</Card>

You can also [automatically generate](#) a dedicated app to execute your flow.

### Schedule the Execution of a Flow

getOperate allows you to schedule scripts using a user-friendly interface and control panels,
**similar to [cron](#)** but with more features.

You can create schedules by specifying a script or flow, its arguments, and a CRON expression to control
the execution frequency, ensuring that your tasks run automatically at the desired intervals.

<Card title="Schedules" href="/workflows/events/schedules">
  Scheduling allows you to define schedules for Scripts and Flows, automatically running them at set frequencies.
</Card>

### CLI (Command Line Interface)

The `getOperate` CLI allows you to interact with getOperate instances right from your terminal.

<Card title="Command-Line Interface" href="/developer/cli/installation">
  Interact with getOperate instances right from your terminal.
</Card>

### Trigger a Flow from another Flow

getOperate supports inner flows. This allows you to call a flow from another workflow.

<Card title="Flow Editor" href="/developer/manual/flow">
  Detailed section on getOperate's Flow Editor.
</Card>

## Triggers from External Events

### Scheduling + Trigger Scripts

A particular use case for schedules are [Trigger Scripts](/introduction/quickstart/triggering-scripts).

Trigger scripts are designed to pull data from an external source and return all of the new items
since the last run, without resorting to external webhooks. A trigger script is intended to be used
with [schedules](/workflows/events/schedules) and [states](#) (rich objects in JSON, persistent from one run to another)
in order to compare the execution to the previous one and process each new item in a [for loop](/workflows/events/loops).
If there are no new items, the flow will be skipped.

By default, adding a trigger will set the schedule to 15 minutes.

<Card title="Trigger Scripts" href="/introduction/quickstart/triggering-scripts">
  Trigger scripts are designed to pull data from an external source and return all of the new items since the last run, without resorting to external webhooks.
</Card>

### Webhooks

In getOperate, webhooks are autogenerated for each Script and Flow, providing either asynchronous or
synchronous execution modes.

These webhooks accept incoming HTTP requests, allowing users to easily trigger
their getOperate scripts and flows from external services by simply sending a POST request to the
appropriate authentified webhook URL (requires passing a [token](#) as Bearer or query arg).
Their purpose is to have the flow run when it receives an input from its associated webhook.

Using webhooks, you could also trigger a flow from scripts.

<Card title="Webhooks" href="#">
  Trigger scripts and flows from webhooks.
</Card>

#### Webhooks: Trigger Flows from Slack

One use case of webhooks is [building a Slackbot with getOperate](#).

getOperate uses Slack to trigger scripts and flows by establishing Slackbots and creating specific commands.
By connecting Slack with getOperate, parsing incoming Slack commands, and leveraging getOperate workflows,
operational teams can trigger complex automations directly from Slack.

<Card title="Slack Integration" href="#">
  Learn how to integrate Slack with getOperate.
</Card>

#### Webhooks: Trigger Flows from Emails

One use case of webhooks is [triggering scripts via inbound emails using Mailchimp](#).

getOperate leverages [Mailchimp Mandrill](#)'s capabilities to initiate scripts and flows
via email-triggered events. By parsing inbound emails and routing the content to getOperate through webhooks,
scripts or flows are activated, enabling automation based on email content or just their arrival.

<Card title="Mailchimp Mandrill Integration" href="#">
  Learn how to integrate Mailchimp Mandrill with getOperate.
</Card>