A trigger decides whether an automation fires. Pick the one that matches how people reach you, and set its keywords so it catches the right messages and skips the wrong ones.

You can give a trigger more than one keyword — enter them as a comma-separated list, and the trigger fires when an incoming message matches any of them.

Comment triggers

A comment trigger watches a specific post or reel and fires when someone comments one of your keywords.

• Matching is whole-word. big looks for your keyword as a standalone word in the comment. LINK fires on "LINK", "send me the link please", and "Link?" — but not on "linktree" or "blinking", because the keyword isn't a separate word there.
• Case-insensitive by default. LINK, link, and Link all match — unless you turn on Case sensitive for the trigger (see below).
• A comment trigger needs a post and at least one keyword — there's no catch-all for comments.
• One post in the dashboard, several elsewhere. The dashboard binds a comment trigger to one post. The API (post_ids), the CLI (--post, repeated) and the local MCP server (postIds) can bind several, and the trigger then fires on a matching comment under any of them. The dashboard shows the first of those posts, and picking a post there replaces the whole list with that one.
• One active comment automation per post. If another active automation already watches the same post, saving a second one fails until you deactivate the first.
• Use a short, distinctive keyword so you don't fire on unrelated chatter.

DM triggers

A DM trigger fires when someone sends your account a direct message.

• Matching is exact. The incoming DM must equal one of your keywords. A DM trigger keyed on START fires when the message is "START", but not when it's "I want to START" — that's extra text around the keyword.
• Case-insensitive by default, unless you turn on Case sensitive.
• Leave the keywords empty to make a catch-all. A DM trigger with no keywords fires on any incoming DM. The automation card shows it as "any DM arrives". Use it for a general welcome flow — your keyword automations still win their own words, whichever you created first (see Which automation answers).
• Use keyword DM triggers for clean, single-word opt-ins where you tell people exactly what to send.
• A reply to your story is a DM too, so DM triggers match those as well — see Story replies and your DM automations below.

Story-reply triggers

When someone replies to one of your Instagram stories, Instagram delivers that reply to you as an ordinary direct message. A story-reply trigger fires on those messages specifically, so a fan who replies YES to your story can get a different answer from someone who types YES into your inbox cold.

• It watches every story on the account, not one story. There's no story picker like the one comment triggers have for posts, and there won't be one: a story disappears after 24 hours, so a trigger bound to a single story would be dead by tomorrow. Choose the account the automation runs on, and it covers whatever you post to it.
• Keywords are optional. Leave them empty and the trigger fires on any story reply — the automation card shows it as "any story reply arrives". Add keywords and it fires only when the reply matches one of them.
• Matching is exact, the same rule DM triggers use. A story trigger keyed on YES fires when the reply is "YES", but not when it's "yes send it please".
• Case-insensitive by default, unless you turn on Case sensitive.
• Nothing to switch on. Story replies come in over the same connection your DMs already use. If your Instagram account is connected, story triggers work — there's no extra permission to grant and no reconnecting to do.

Story replies and your DM automations

Your existing DM automations keep answering story replies. Because a story reply is a DM, a catch-all DM trigger still fires on one exactly as it did before story triggers existed — the promise that a keyword-less DM trigger fires on any incoming DM is unchanged, and it always covered story replies. Adding a story automation doesn't take that away.

If you'd rather your story replies were handled only by a story automation, turn on Skip story replies on the DM trigger. It's off by default, so no automation you already built changed behaviour. It governs which automation starts: if someone is already mid-conversation with that DM automation, a story reply from them continues that conversation, exactly as any other reply of theirs would.

When a story reply could match both a DM automation and a story automation, the usual rule decides (see Which automation answers). A story automation with keywords beats a catch-all DM automation on those keywords. But two catch-alls — a keyword-less DM trigger and a keyword-less story trigger — tie, and the older one answers, so a catch-all DM automation you already had will beat a catch-all story automation you add today. Turn on Skip story replies on that DM trigger and the story automation wins.

Which automation answers

Only one automation runs per incoming message. When more than one matches, big picks in this order:

1. Priority order — a lower priority_order goes first. Automations you build in the dashboard all share the same priority, and there's no reorder control in the dashboard yet. Set it with big rule:set <id> --priority <n>, big_rule_update on the local MCP server, or priority_order on PATCH /api/automations/:id.
2. Keywords before catch-alls — at the same priority, an automation with keywords is tried before one without, so a catch-all welcome never steals a keyword's message, however old it is.
3. Oldest first — anything still tied goes to the automation created first.

An explicit priority still wins over everything else: a catch-all you give a lower priority_order answers before any keyword automation behind it.

Case sensitivity

By default, matching ignores letter case. Each trigger has an optional Case sensitive setting in the automation builder — turn it on when case matters, and LINK will then match LINK but not link. It's off by default, so unless you change it, case never matters.

The three triggers at a glance

Tags applied on trigger

A trigger can carry a list of tags. Anyone who fires the automation gets those tags added to their contact automatically — handy for building an audience out of everyone who commented LINK, without tagging by hand. In the builder it's Tags applied on trigger on the trigger; outside it, --tags on big rule:create and big rule:set, tagIds on the local MCP server's big_rule_create and big_rule_update, tag_ids on the remote create_automation, and tag_ids over the API.

This is a different list from the trigger's Audience, which decides who the automation fires for at all: an only fire for these tags list and a never fire for these tags list (--include-tags / --exclude-tags, includeTagIds / excludeTagIds, include_tag_ids / exclude_tag_ids). See Per-automation audiences.

Next step

Once your trigger fires, big runs your actions. See Sending DMs for what those replies can contain and when they're allowed to go out. To route people down different paths based on how they reply, see Branches.