> ## Documentation Index > Fetch the complete documentation index at: https://deepline.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Play triggers > Manual calls, webhooks, schedules and row changes that start Play runs. A **Play trigger** determines when a Play receives input and starts a run. The same workflow can support a direct call, an incoming event, a schedule or a supported Database row change. The Play's business logic remains in one place. For example, a company-review Play can run on demand for one account, each morning for a selected list, or when a new provider event arrives. Each entry point needs input that matches the Play's contract. ## Choose the source of work | Entry point | What starts the run | Input | | - | - | - | | Manual call | A person, agent or application invokes the Play. | The caller supplies fields or supported file input. | | Webhook | Another system sends an HTTP request to the issued URL. | The JSON request body. | | Cron schedule | A scheduled occurrence becomes due. | The configured static input, or `{}`. | | SQL listener | A supported stream receives a matching row change. | One changed-row event. | Manual calls can use the web app, CLI, SDK or Runtime API. They do not require an automated binding. A local file run submits the handler's code snapshot without activating its declared schedule or webhook. Automated bindings live in the Play file's exported `config` object and belong to the published Play. One Play can declare several trigger types, provided its function understands each input shape. Checking a file validates the declaration. Publishing activates the selected definition. ## Webhooks bring input from another system Deepline issues a webhook URL for a published webhook binding. The sender posts the Play's input there. A lead form, CRM relay or application event can use this path to start a workflow without waiting for a schedule. The Play can declare a signature verification contract. Deepline verifies configured signatures before the handler runs. The sender or relay must use the matching format and signing secret. An empty webhook declaration alone does not authenticate the sender. A stable delivery identity lets Deepline recognize a retry of the same event. Supported headers include explicit deduplication keys and delivery IDs from supported webhook formats. Repeating identical JSON alone does not establish that identity. A new business event needs a new delivery ID. An accepted webhook acknowledges intake, which can precede execution. The resulting run and its retained state show whether the Play started and finished. A sender retry and a deliberate new invocation are different operations. The [webhook guide](https://deepline.com/docs/sdk-v2/webhooks-and-schedules.md) explains authentication, delivery header precedence and how to inspect the issued binding. ## Cron schedules start work at known times A cron binding declares a schedule and timezone. It can also declare static JSON input. Without that input, the handler receives `{}`. Input from a previous manual run does not become the schedule's input. For example, a daily refresh can select accounts that need current evidence, then process them as a dataset. The schedule supplies the occasion. Account selection, overlap policy and acceptance rules remain in the Play. The published binding controls future occurrences. A scheduled run uses its admitted version, so later source edits do not alter a run already underway. Timezone, input and publication state all affect what the automation does. Billing restrictions can suspend scheduled work. Recovery depends on the recorded reason. A balance correction can recover eligible insufficient-credit suspensions, while a customer-paused schedule remains paused until explicitly resumed. ## SQL listeners react to retained row changes A SQL listener connects a published Play to a supported tool and stream. Deepline resolves that stream to its Database table. The binding selects operations such as inserts or updates and can apply row-level filters. Each listener invocation receives one event containing the operation, stream, before/after rows and change metadata. Inserts have no before row. Deletes have no after row. Updates carry both. A listener can filter for relevant changed values, then let the Play query other records and apply business rules. Joins and broader decisions belong in the handler rather than its row-level filter. A [Monitor](https://deepline.com/docs/plays/monitors.md) often supplies the source events. The listener subscribes to the tool's stream, not a private queue for one Monitor key. Several Plays can consume accepted data from the same stream. A listener also differs from a periodic query over all accumulated rows. ## Publication and lifecycle controls Publication activates declared bindings for the selected Play revision. Removing a binding changes future entry points. Existing runs retain their own execution identity and need separate cancellation when appropriate. Removing a webhook retires its URL. Re-enabling it issues a new URL, so the sender configuration also needs to change. A schedule or listener likewise needs its own control rather than relying on the stop state of one run. The lifecycle boundaries are separate: * Disable a trigger to prevent its future work. * Stop a run to cancel an execution already started. * Change a Monitor to alter its upstream feed and accepted source data. For repository-owned Plays, source publication belongs in the [Git deployment workflow](https://deepline.com/docs/sdk-v2/git-deploys.md). A manual handler test does not establish that the live sender, signature, schedule or stream delivers work. ## Observe automated work The active binding explains what should start a run. [Play runs](https://deepline.com/docs/play-runs.md) show what happened after launch. Source delivery and downstream execution can fail independently, so both need observation. Notification settings can route supported scheduled and webhook Play outcomes. Configured rules, destinations and recipient preferences determine delivery. The [notification settings](https://deepline.com/docs/workspaces.md#notifications) and [trigger setup guide](https://deepline.com/docs/sdk-v2/webhooks-and-schedules.md) explain the available checks. ## Continue learning * [Schedule or trigger a Play](https://deepline.com/docs/sdk-v2/webhooks-and-schedules.md): configure webhooks and cron schedules. * [Set up a Monitor](https://deepline.com/docs/plays/set-up-a-monitor.md): supply a feed and connect a SQL listener. * [Play runs](https://deepline.com/docs/play-runs.md): inspect execution, results and cancellation. * [SDK reference](https://deepline.com/docs/sdk-v2/sdk-reference.md): exact binding and event contracts. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.