# Run, schedule and trigger > Pass inputs and start a workflow manually, on a schedule, from a webhook or from an event. ## Before you begin You need owner or dashboard editor access to run workflows or change triggers. Declare and save your [workflow inputs](/en/docs/workflows/build) first. ## Run manually 1. Open the workflow's **Pipeline** tab. 2. Choose **Run**. 3. Fill in the declared inputs and submit the form. 4. Open **Runs** to inspect the result. Without inputs, **Run** starts immediately. Required or invalid values block submission. Runs continue after you close the page. ## Add a schedule 1. Choose **Add trigger**, then **Schedule**. 2. Set the recurrence, time and timezone. 3. Under **Data**, assign a **Fixed value** to every required input. 4. Save the trigger. Schedules support daily runs, selected weekdays, selected month days and fixed minute or hour intervals. A month day beyond the month's end runs on its last day. The workflow shows the next run time. Each trigger has its own **Enabled** setting. Disabling the workflow pauses all schedules; enabling it resumes enabled schedules from their next occurrence. Several triggers can start the same pipeline with different input assignments. Trigger changes save separately from inputs and steps; use **Save trigger** when editing one. Every trigger must supply a value for each required input. **Required inputs** in the trigger drawer shows what is missing, and saving waits until each has a value. A new webhook is the exception until its first delivery arrives. ## Connect a webhook 1. Choose **Add trigger**, then **Webhook**. 2. Choose **Create webhook**. Its URL appears under **Address**. 3. Copy the URL and choose **Reveal** to obtain the secret. 4. Send a POST request with the secret in the `X-Botchi-Webhook-Secret` header, or use **Paste an example**. 5. Under **Received data**, choose the input each field feeds. **New input** creates an input from a field. 6. Choose **Save trigger**. **Advanced** holds a request example. An optional `Idempotency-Key` header prevents retries with the same key from starting another run. The Assistant and MCP can return the URL, but never receive the secret. Botchi answers **202** once it has stored a request, and the run is queued right after. A retry with the same `Idempotency-Key` and body answers **200** and starts nothing; the same key with a different body is refused with **409**. Keys are remembered for at least 7 days. Requests that started nothing or kept failing appear in the webhook drawer with their reason; editors can choose **Retry** on a failed one. ### Signed requests If the sender supports [Standard Webhooks](https://www.standardwebhooks.com), choose **Standard Webhooks signature** under **Authentication**. The sender then signs each request with the secret instead of sending it, in the `webhook-id`, `webhook-timestamp` and `webhook-signature` headers. A missing or wrong signature, or a timestamp more than 5 minutes away, is refused with **401**. `webhook-id` replaces `Idempotency-Key`: the same id and body answer **200**, the same id with a different body **409**. Switching the mode creates a new secret. > **Watch out** — **Rotate** invalidates the old secret immediately. Update the sender before relying on further deliveries. Only editors and owners can reveal or rotate secrets. ## Listen for an event 1. Activate the required account connection under **Connections**. 2. Choose **Add trigger**, then an event: **WhatsApp · Message received**, **Slack · Mention or direct message**, **Slack · /botchi command** or **Facebook · New lead**. 3. Under **Connection**, choose the connection the trigger listens to. WhatsApp and Slack can also listen to all their connections; **Facebook · New lead** always names one, such as one client of an agency. 4. Under **Received data**, choose the input each event field feeds, or create one with **New input**. 5. Give other required inputs a fixed value under **Inputs without data**. 6. Save the trigger. 7. Use **Variable → Inputs** in your steps to consume those values. A trigger saves only when its source is ready: the webhook verified and, for the chosen connection, everything its connector page lists. **Facebook · New lead** also needs the Pages selected and subscribed; see [social channels](/en/docs/tools/social-channels). Its fields include the form answers, such as **Email**. One workflow can have the same event once per connection, for example one trigger per client. For a WhatsApp reply, declare a recipient input and assign it to the event’s **Reply address**. Slack replies use **Reply channel** and, where available, **Thread**. Filter sender values with a Condition: put matching actions on the true lane and leave the false lane empty. Every active listener receives the event; several replying workflows send several replies. With no listener, WhatsApp stays silent; Slack gives a private notice at most once per connection and channel each hour. ## Test and inspect deliveries 1. Save the trigger's input assignments. 2. Choose **Try with the sample** in the webhook or event drawer. 3. Inspect **Recent deliveries** and the run trace. > **Watch out** — A sample test executes real steps and spends Sparks. It can send messages or change data. Send a fresh source delivery if the sample cannot be replayed. **Recent deliveries** lists the latest 50 deliveries, outcomes and drop reasons. Missing required inputs prevent a run. Delivery data is kept for 30 days. Viewers see arrival times and assigned field names; only managers see values. Original data appears under **Advanced** for webhook and event runs. External deliveries queue and run one at a time. Automatic runs act as the workflow's last editor and use shared account Sparks. See [failures and concurrency](/en/docs/workflows/guardrails). ## Related - [Build a workflow](/en/docs/workflows/build) - [Connected accounts](/en/docs/tools/connected-accounts) - [Usage](/en/docs/usage)