Workflows — when this happens, do that

Every community has jobs that get done by hand over and over. Tag the posts that mention billing. Message new members after their first post. Add buyers to a group. Push reports into the chat channel your team actually watches.

Workflows does them for you. You pick a trigger, add conditions if you need them, and choose what should happen.

28 things to trigger on

Every one of those is wired to a real Invision Community event and tested on an install with the first-party applications present. The trigger list only ever offers events that genuinely fire — you cannot save a rule that quietly never runs.

Buttons on a Pages record

Twenty-seven of those triggers are things your community does. The twenty-eighth waits for a person.

Design a button in the rule — its wording, its colour, an optional icon, which databases and categories it appears on, which groups can see and press it, and whether to ask for confirmation. What happens when it is pressed is the ordinary conditions and actions below. Approve and Reject on a bug tracker, Send back to the author on an article, a one-click Mark as answered.

Because it is a rule and not a template edit, a button can carry conditions, write to a Pages field, message the author, fire a webhook, and be changed by somebody who has never opened a theme.

Buttons run immediately rather than on the queue — you pressed it, so you are told what happened rather than waiting on a background task.

Conditions, so rules stay precise

Forum or category, author's group, post count, account age, content contains text, content matches a pattern, tagged with, title contains, is the first post in a topic.

Actions

Lock, unlock, pin, unpin, hide, approve, add tags, add or remove a secondary group, award points, award a badge, send a private message, and send a webhook.

The webhook action is the important one

Anything your community does can be pushed to Zapier, Make, n8n, or your own code, as JSON. That means Workflows isn't limited to what this application can do — it's the bridge to everything else you already use.

Set a signing secret and each request is signed, so the receiving end can tell a genuine call from anyone who guessed the URL.

A run log that answers the real question

Rules engines fail when you can't tell why a rule didn't fire. Workflows records every evaluation, with the reason:

• "Forum 'Introductions' is not in the selected list."
• "Bob has 3 posts; condition was at least 10."
• "Content does not contain \"refund\"."

Filter by matched, skipped or errors, and by rule. Turn skipped logging on while you build a rule and off once it works.

Built not to get in the way

• Nothing blocks posting. Conditions are evaluated inline because they're cheap; actions run on the background queue. A rule pointing at a slow webhook can never make a member wait, and an outage can't stop people posting.
• Loops are impossible. "When a post is created, post a reply" would take a site down. The engine refuses to re-enter an event it's already handling — that's built into its structure, not a setting you can get wrong.
• Only sensible options are offered. The builder hides conditions and actions the chosen trigger can't supply, so you're never offered "lock the topic" on a member-registered rule — there isn't one.
• Actions report what they actually did, not what they attempted — including when Invision Community declines something, and why.
• Rules run in order, and any rule can stop the ones after it.
• No core files are edited. Upgrading Invision Community won't break it.

Requirements

• Invision Community 5.0 or newer (self-hosted), with the Forums application
• Nothing else. No external service and no API key — unless you use the webhook action, which needs somewhere to send to.

Commerce triggers require the Commerce application; club and course triggers require theirs. Everything else works on a stock install.