Triggers

Triggers let your scripts run automatically — no need to open the app and start them by hand. You attach a trigger to a script, tell it what to watch for, and Script.it runs the script every time that thing happens.

​

What a trigger can watch for

There’s one kind of trigger, with a menu of things it can watch for:

• A schedule — every weekday at 8 AM, every six hours, the first of the month. See Schedule triggers.
• An app event — a new Notion database item, a GitHub pull request, a Slack mention, a Calendly booking, a new row in a Google Sheet. Over 80 events across 40+ apps. See App events.
• A webhook — your own URL that any service can send a request to. See Webhook triggers.
• Anything else — if nothing in the menu fits, the agent can build a custom trigger for you. See Custom triggers.

They all behave the same way once they exist: they watch for something, and when they see it, they run your script.

​

Creating a trigger

The easiest way is to ask the agent in chat:

Run this every weekday morning at 8 AM.

Trigger this whenever someone opens a pull request on our repo.

The agent picks the right trigger, fills in the settings, and switches it on. You can also create one yourself: open the script, click the Triggers tab, and click Add Trigger. A searchable list shows every event available for the apps you’ve connected. Either way, the trigger starts working as soon as it’s created.

​

What a trigger does

A trigger runs a script. You choose which script, and optionally the input values it should run with — the same inputs you’d fill in when running it by hand. When the trigger fires, the details of what happened are handed to your script, so it can act on them — the contents of the Slack message, the fields on the new Notion item, the body of the webhook request. Runs show up in your session history alongside sessions you started yourself. Related events can be grouped into a single ongoing session instead of opening a new one every time, so a busy trigger doesn’t flood your history.

​

Triggers are part of the script

A trigger isn’t a separate thing hanging off your script — it lives inside it, like a block does:

• It appears in the script, with its own settings, an on/off switch, and its recent run history.
• It’s saved with the script’s files.
• So it travels with the script. Export the script, import it into another workspace, or share it with a teammate, and its triggers come along.

There’s no separate place to keep in sync: change the trigger and the script updates with it.

​

Triggers in a shared workspace

Scripts are shared with your workspace, but triggers run for a person. So when a teammate opens a shared script, its triggers appear switched off, with an Enable button. Turning one on creates their own copy. It runs with their connected accounts and their credits, and it has its own settings and run history. Any member of the workspace can enable a script’s triggers. Doing so doesn’t change the script or affect anyone else’s copy.

​

Next steps