n8n and Mattermost integration

By default, the n8n Mattermost integration posts under a service identity, so Mattermost shows the bot account as the author of an alert, approval request or result. Unless the design records the requesting or approving person, the audit trail will show that a bot acted, not the human who clicked approve. Decide how attribution works before the first approval workflow goes live. The workflow needs to capture the Mattermost user ID of the person who responded, the timestamp, and the request being approved, then store those values in the message and in the n8n execution log with the execution ID. Test this in a non-production instance, and confirm how the Mattermost node and any interactive message callback expose the acting user in your Mattermost version, because that answer determines what your workflow must record itself.

Three identity types are often confused, and they behave differently in an audit. A Mattermost bot account is a non-person account whose token belongs to the service, so it survives staff changes. A personal access token belongs to a named employee, so posts appear to come from that person, and the integration breaks or needs reassignment when they leave or change roles. Single sign-on on the n8n side controls who signs in to the n8n editor. It does not change which identity a Mattermost post carries. SAML single sign-on for n8n is listed for the Business and Enterprise plans. Mattermost SSO (SAML, OIDC, OAuth) and AD/LDAP user sync are included from the Professional plan. Confirm which plan you are buying for each system before you design around these controls.

Adopt a naming and ownership convention for service accounts before creating any of them. Name each account for its function and environment, for example an illustrative svc-n8n-alerts-prod, so that a reader of the audit log can tell at a glance what the account does. Use separate accounts for alerts, approvals and workflow results, so that a leaked token exposes only one function. Record a named owning team and a backup owner for every account in the runbook, along with the channels it can post to and the workflows that use its token. Grant each bot only the team and channel membership it needs and avoid system administrator roles. Review this inventory when people change roles and when workflows are retired, because orphaned bot accounts are a common source of unexplained posts.

Write a token rotation plan before go-live and set the rotation interval in your security policy. The researched facts for this topic do not state a Mattermost token lifetime, so confirm with the Mattermost documentation and test in your own environment whether tokens expire automatically and how revocation takes effect. Store each token only in an n8n credential, which is encrypted with the instance encryption key. In queue mode, that key must also be available to worker and webhook processor nodes, so rotating the encryption key is a larger change than rotating a Mattermost token and needs its own plan. A practical rotation sequence is to create a new token under the bot account, update the n8n credential, send a test post to a sandbox channel, revoke the old token, and record the change with the date and owner. Rehearse this sequence once before you need it under pressure.

Decide the availability target before you choose a topology, because the Mattermost integration inherits the availability of every n8n process it touches. Start by writing down what happens when the n8n main instance is unavailable for an hour. Do alerts still reach Mattermost, do approval requests stop, and does a chat command get lost? Those answers determine whether a single main instance with a warm standby is enough, whether queue mode is needed for execution capacity, and whether you need multi-main. Note the licensing boundary early. n8n multi-main high availability is restricted to Enterprise self-hosted deployments, so a design that depends on it needs an Enterprise license. Confirm the tier with n8n before the architecture review.

In queue mode, the main instance keeps the trigger and webhook role, while executions pass through Redis to a pool of workers that read and write workflow data in PostgreSQL. Webhook processors can run as separate processes that receive inbound HTTP traffic. This split matters on the chat-triggered path. Whatever Mattermost uses to call n8n (confirm the exact mechanism for your Mattermost setup) depends on the webhook processor being reachable from the Mattermost server's network segment. The webhook URL, its TLS certificate and any load balancer in front of it belong in the design from the start. Test that path from the Mattermost network, not only from your administrator workstation. Redis and PostgreSQL are shared dependencies that every workflow touches, so their availability is part of the n8n target too.

Every worker and webhook processor needs the same encryption key as the main instance, because credentials are stored encrypted in the database and each process decrypts them at run time. The Mattermost access credential is one of those secrets. A process started with a different or missing key is likely to fail when it tries to read that credential, which can produce failures that appear only on some nodes. Treat key handling as a deployment control. Store the key in the secret manager your platform team already operates, inject it identically into every container or host, and document the change process before you add a second worker. Plan any key rotation as a scheduled change across all processes, with a tested restore of the database beforehand.

Mattermost high availability is a separate decision with its own licensing and storage rules. A cluster consists of redundant application servers, redundant database servers and redundant load balancers, and it is available only on the Enterprise and Enterprise Advanced plans. Each node also needs shared file storage on Amazon S3, an S3-compatible service or NAS, mounted on every node. Local file system storage will not work correctly and risks corrupting files. Treat that storage as a dependency with its own backup and failover plan. Database read replicas can spread read load, with writes still going to the primary database, but they do not replace the redundancy described above. Check with Mattermost which deployment guide applies to your version.

Before you size the design, put five questions to vendors and internal teams in writing: which n8n tier includes multi-main and at what cost, which Mattermost plan includes clustering, which shared storage option you will run, which network path connects Mattermost to the webhook processor, and which highly available database and Redis services you will provide. Mattermost sells prepaid annual subscriptions based on seat licenses and does not publish prices, and n8n Enterprise pricing is custom. Recurring license cost therefore has to come from a quote tied to a written scope. Ask each vendor to confirm features against your specific deployment and version.