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
ContentPosted · edited · deleted · hidden, locked or pinned · moved · merged · split · reported MembersRegisters · validates · logs in · updates their profile · flagged as a spammer · reacts · follows · joins or leaves a club · RSVPs · completes a course CommercePurchase paid · about to expire · expired · renewed · cancelled OtherPoll voted · file downloaded · club created PagesSomebody presses a button you designed 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.
For example: when content is posted, and the author has fewer than 5 posts, and the content matches a URL pattern — hide it and send yourself a webhook. 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.

Developer Sign-In
Let your members sign in with GitHub, GitLab or Bitbucket — the accounts they already have, on the platforms they already use every day.
Invision Community ships sign-in handlers for Facebook, Google, Microsoft, LinkedIn, Apple and X. Excellent for a general community. Not much use if your members are developers.
Who this is for
Software and open-source communities — support forums, plugin and mod communities, anywhere the conversation is about code. Homelab, self-hosting and sysadmin communities, where a GitHub account is more universal than a Facebook one. Companies running their own GitLab. A community that self-hosts its forum very often self-hosts its GitLab too, and this connects the two. Your instance address is a field on the settings screen. Game and modding communities whose members publish their work on one of these platforms already. What it does
Three providers, one application. Enable one, two or all three. Each is a separate sign-in button with its own credentials, and each can be turned on and off independently. Verified email addresses, carried across. This is the part that is fiddly to do by hand — see below. Avatars and names come across too, and you decide whether the provider's name is used or the member picks their own. Works alongside everything else. Passwords, existing social logins and any other handler carry on exactly as they are. A member can link a provider to an account they already have, from their account settings, and unlink it there just as easily. Self-hosted GitLab is supported properly, not as an afterthought — every address the handler uses is built from the instance you name. The email problem, and why it is worth paying to skip
Invision Community includes a generic OAuth handler that can, in principle, be pointed at anything. The reason people give up on it for these three platforms is the email address.
PlatformWhat actually happens GitHubThe profile carries only the public address, and most developers keep theirs private — so it arrives empty. The real address needs a second request, a specific permission, and filtering down to the one that is both primary and confirmed. BitbucketThe profile carries no address at all. Same story: a second request, and permissions that have to be set on the application itself rather than asked for at sign-in. GitLabStraightforward — provided you ask for the right scope. Get this wrong and sign-in still appears to work. Members simply arrive with no email address and are asked to type one, which is exactly the friction you installed a one-click sign-in to remove.
An unverified address is never accepted. Only an address the provider itself confirms as belonging to the account holder is used. Anything less would let somebody register an account elsewhere against one of your members' addresses and land on their community account.
What it does not do
It does not import repositories, issues or commits, and it does not post anything to your community. It does not sync organisations, teams or repository access to member groups. It does not replace your existing sign-in methods. It adds to them. Requirements
Invision Community 5. A free OAuth application on each platform you want to offer — a few minutes each, and the setup guide walks through all three with the exact values to paste. No cron job, no theme edit, and no third-party service beyond the platforms themselves.

Profile Photo Gallery
Give your members a set of profile photos to choose from, instead of leaving every avatar to whatever they happen to upload.
You supply the photos. Members pick one from their account settings, and it becomes their profile photo everywhere on the community — topics, profiles, the member list, hovercards, notifications.
Why communities want this
Younger or moderated communities where letting members upload arbitrary images is a moderation problem you would rather not have. Themed communities — a game, a show, a team — where a set of house avatars is part of the character of the place. Anyone tired of the letter avatar. Most members never set a photo at all. A row of ready-made ones they can pick with a single click converts far better than an upload form. What it does
Photo sets. Group your photos however you like — "Mascots", "Seasonal", "Staff" — each with its own heading that members see. Restrict a set to member groups. Staff-only avatars, supporter-only avatars, a set that only appears for a promoted group. Secondary groups count, so a member given a staff group as a secondary sees the staff photos. Members choose from their account settings, in a tab alongside Email Address and Password, where they already go to change things about their account. One click to change, one click to remove. The photo they are wearing is marked, so it is obvious what they have. See what is actually being used. Every photo in the AdminCP shows how many members are wearing it, and deleting one that is in use warns you first. Upload in bulk. Select a folder's worth of images at once; they are resized on the way in. How it stores them
One copy of each photo, shared by everyone who chose it — not a duplicate per member. A community of five thousand members wearing twenty avatars stores twenty images.
It uses the same mechanism Invision Community's own Gallery application uses for this, so photos work everywhere a profile photo appears, with no theme edits and no template hooks. They can also be moved to S3 or any other storage you have configured, from the AdminCP screen you already use for that.
What it does not do
It does not remove or replace your members' ability to upload their own photo. That stays exactly as your group settings have it — the gallery is an additional way to get one, not a restriction. If you want uploads switched off, that is a group setting in Invision Community itself. It does not import photos from anywhere. You upload the images you want offered. Requirements
Invision Community 5. Nothing else. No third-party service, no cron job, no theme changes. Invision Community offers a profile photo gallery on its Cloud Team, Business and Enterprise plans. This brings the same idea to a self-hosted community.

Passkeys — sign in with a face, a fingerprint or a security key
A passkey replaces the password entirely. Your members tap their phone, look at their laptop, or touch a security key, and they are in. Nothing to remember, nothing to type, nothing to leak.
This is a real login method, not a second factor. Invision Community has no WebAuthn support of any kind — this registers through core's own login-handler system, so the passkey button sits alongside your existing sign-in options and behaves like one of them.
Why passkeys and not another password policy
They cannot be phished. A passkey is bound to your domain by the browser. A convincing copy of your login page on another domain simply will not work — the credential refuses to sign for it.
They cannot be reused. Every site gets a different key, so a breach somewhere else cannot reach your community.
There is nothing on your server worth stealing. You store a public key. It verifies signatures and can create none.
Nothing to reset. No "forgot password" flow, no reset emails, no support tickets about them.
What members see
Adding one
A page in their account settings. One button, their device prompts, they name the key. Several devices, several keys.
Signing in
A "Sign in with a passkey" button on the normal login form.
Managing them
Rename or remove any key, with the date added and last used, so an old laptop is easy to spot and revoke.
Works with what people already have
Face ID and Touch ID, Windows Hello, Android biometrics, iCloud Keychain, Google Password Manager, 1Password, Bitwarden, and hardware keys such as YubiKey. Nothing to install — every current browser has this built in.
Built carefully, because this is authentication
Every check the WebAuthn specification asks for is performed, and the reason each one exists is that skipping it breaks the model. The challenge is single-use, purpose-bound and expiring, so a captured ceremony cannot be replayed. The origin is compared exactly — not "starts with" — so a lookalike domain cannot relay it. Registrations cannot be replayed as logins. A signature is verified over exactly the bytes the authenticator signed.
Cloned-device detection. WebAuthn gives one signal that a credential may have been copied: a signature counter that goes backwards. If that happens the passkey is disabled and the member is told why. Authenticators that don't count at all report zero forever — that is normal, and is never mistaken for an attack.
No third-party code. No composer packages, no bundled cryptography library, nothing fetched at runtime. Verification uses PHP's own OpenSSL functions.
Hidden when it cannot work. Browsers refuse passkeys outside a secure context, so on a site without HTTPS the button does not appear rather than failing when pressed.
No core files are edited. Upgrading Invision Community will not break it.
What you control
How many passkeys each member may register
Whether to require user verification — a fingerprint, face or PIN, rather than mere presence
Whether a backwards counter disables the credential
The name members see on their device when it asks them to confirm
Requirements
Invision Community 5.0 or newer (self-hosted)
HTTPS. Browsers will not create or use a passkey without it.
PHP with OpenSSL — standard on every install

Disposable Email Blocker — stop throwaway signups
Ten-minute mailboxes are how a banned member comes back, how one person becomes fifty accounts, and how a spam run gets its foothold. Invision Community has no idea those domains are different from anybody else's.
This knows about eight thousand of them, keeps the list current by itself, and decides what happens the moment such an account is created.
What it does
Recognises throwaway domains. A maintained public blocklist, fetched at install and refreshed daily, so a service that launched last week is caught this week. You choose the response. Hold the account for approval, ban it outright, or record it and do nothing — useful for watching what arrives before you act on it. Your list beats the public one. Add domains it misses, and mark domains it is wrong about as always allowed. A refresh never touches either. Blocking a domain blocks its subdomains. One entry for example.com covers mail.example.com without listing every variation by hand. Shows you what it caught. A panel of counts and the recent catches, so you can tell whether the rule is right rather than trusting that it is. Holding for approval is the default, on purpose
Not everybody using a forwarding address is a spammer. Plenty of careful people sign up to a new forum with a throwaway address precisely because they do not know you yet, and some of them become your best members.
So the default is to hold the account for a human, not to ban it. You get to look. Ban is there when you want it, and there is a third setting that changes nothing at all and simply keeps a record — the honest way to find out what your signups actually look like before you start turning people away.
It acts when the account is created, not at the signup form
Worth being straight about, because it is visible to you: Invision Community 5 provides no way for an application to refuse a registration while the form is being filled in. The account is created, and this acts on it immediately afterwards.
That is not a workaround — it is the better place to stand. It means the check also covers registrations that never touch the form: social and OAuth logins, and anything created through the REST API. A guard bolted onto the signup form would miss all of them, which is exactly where a determined spammer goes next.
Built not to get in the way
A fault never blocks a real signup. If the database is unhappy, the check is skipped rather than failing closed. A spam tool must never be the reason somebody cannot join your community. A bad download cannot empty your blocklist. If the source returns a suspiciously small list, it is treated as a failed fetch and the existing list is kept. Existing members are never touched. It only ever looks at an account as it is created. The log records the domain, never the address. You do not need a file of other people's email addresses to decide whether a rule is working. Requirements
Invision Community 5.0 or newer, self-hosted Outbound access to fetch the blocklist — or add domains by hand and turn the refresh off, which works perfectly well on a closed network Built to be safe
It adds two small tables, hooks no templates, and never edits a core file. Everything it does happens on the member-created event, wrapped so that no fault of its own can surface to the person registering.
Version 1.0.0 · Invision Community 5 · self-hosted

Backup & Restore
Invision Community ships with no backup of any kind. The only thing it does is ask you to tick a box confirming you have made one — immediately before an upgrade, which is the single most dangerous thing the software does.
The usual advice is "just run mysqldump". On a correctly configured server you cannot. Invision Community's own Configuration Error notification tells administrators to disable exec, shell_exec, passthru, popen and proc_open. Take that advice, as you should, and every shell-based backup tool stops working.
This is pure PHP. No shell, no mysqldump, no external binary. It works on shared hosting, in a container, and on a hardened server where nothing can be executed.
It reads every backup back
A backup nobody has ever opened is not a backup — it is a file you are hoping about. After writing an archive this one reads it again, from the beginning, and checks:
the compressed stream decompresses whole, without truncation;
the end-of-file marker is present, which is what proves it was not cut short;
the SHA-256 checksum matches what was written;
every table is present, and every table's row count matches.
Only then is it marked verified. A backup that fails any of those is marked failed and — importantly — never counts towards your retention limit, so a good archive is never deleted to make room for a broken one.
It tells you when a backup is not a snapshot
Where the database is small enough to finish in one request, the dump runs inside a single transaction with a consistent snapshot: every table as it was at the same instant. Where it is too large, the work is queued across requests — which means the first table is read minutes before the last, while people are still posting.
Both kinds are labelled, on every row. A staged backup can contain a reply whose topic is missing. That is a real limitation of any backup taken this way, including mysqldump without --single-transaction, and you are told which kind you have rather than left to assume.
Somewhere other than the server it is protecting
A backup on the same disk as the community does not survive losing that disk. Archives are written above the web root where possible, so they cannot be requested over the internet at all — and can be sent to any storage you have already configured: Amazon S3, Cloudflare R2, Backblaze or FTP.
If the parent directory is not writable and archives have to live under the web root, the application says so plainly on the screen rather than quietly hoping the filename is enough.
Restoring
One table
The case that actually happens: somebody deleted a forum. Restore that one table and nothing else — the rest of the community, including everything posted since, is untouched. The screen shows which tables have lost rows since the backup, so you can see what is missing before you touch anything.
Everything
Runs from a generated standalone script, not from a button. A full restore replaces the very tables the running request depends on — sessions, caches, the job queue — and doing that from inside the suite is how a community ends up unable to start. The script boots nothing, reads your configuration directly and survives its own work.
The restore script is key-protected, refuses to run without an explicit confirmation, and refuses outright if the archive does not match the database it is pointed at — for example if it came from a different install, or before an application was added — unless you override it deliberately.
Details that matter when it counts
Binary data is hex-encoded, so blobs, attachments and anything with a NUL byte come back byte for byte rather than quietly corrupted.
A legitimate zero stays zero in an auto-increment column, instead of being silently reassigned and breaking every row that pointed at it.
Archives are portable. The dump is written as ordinary SQL that restores in any MySQL session, not only inside Invision Community.
The schedule is measured from the last successful backup, not the last attempt — so a job that fails every night cannot keep satisfying the schedule while producing nothing.
It survives its own restore. Restoring replaces this application's own records too; it rebuilds them by reading the archives back off disk, rather than reporting that you have no backups.
Requirements
Invision Community 5.0 or newer (self-hosted)
PHP with zlib, which every install already has
A running task scheduler, for scheduled backups
No shell access. No mysqldump. No external service.