Mattermost guest accounts for external collaboration: when your teams need them
Your teams often need to work with people outside your organization in the same chat channels they use every day: a managed services vendor troubleshooting a deployment, a contractor building a feature for one project, or a customer following an implementation. Adding those people as full members would give them access to far more of your workspace than the work requires. Mattermost guest accounts provide controlled access to specific channels and team members, and a system admin must enable guest access in the server settings before any guest can be invited.
Guest accounts fit three common situations. Vendors and managed service providers need a shared channel for incident coordination or change windows. Contractors need access to the project channels they staff, but not to the internal operations or HR conversations next to them. Customers may need a private space to exchange status updates or approve deliverables. In each case the question to answer first is which channels the outside person must read and post in, and which channels must stay invisible to them.
The feature is documented by Mattermost in its guest accounts guide, and it applies to a self-hosted Mattermost server in the same way it applies to the hosted service. On your own infrastructure, the enablement decision, the invitation policy and the audit trail all sit with your administrators, so the rollout plan needs an owner inside your organization. Confirm the current setting names and the behavior of your server version against the documentation before you draft policy, because guest-related options have changed across releases.
Before you enable guest access, decide who may invite guests. By default only system admins can invite them, which is a conservative starting point for a regulated organization. Enterprise and Professional customers can extend that permission to others, so confirm which plan your organization holds and whether a wider group of team administrators needs the ability. Also agree how you will verify each external identity before an invitation is sent, and who approves the removal of a guest when a contract ends.
Plan the guest list alongside your identity and licensing model. Mattermost treats a guest who belongs to exactly one active channel as a single-channel guest, and those accounts do not count toward paid seats, up to a 1:1 ratio with your licensed seats. Guests who belong to more channels are counted as normal users. Ask your Mattermost account team how this ratio applies to your contract and how seat usage is reported, and build a periodic review that removes guests from channels they no longer need.
Guest invitation options and when each fits
This table compares the default invitation model, where only system admins invite guests, with delegated invitation rights available on Professional and Enterprise plans. Read each row as a decision: who sends invitations, who approves them, and what the team gives up or gains. The main takeaway is that delegation trades central control for speed, so the delegation policy needs to be written down before it is switched on.
| Decision | Default: system admins only | Delegated invitation rights |
|---|---|---|
| Who can send guest invitations | Only Mattermost system admins, once a system admin has enabled guest access | System admins can grant invitation rights to other users on Professional and Enterprise plans |
| Who approves guest requests | The system admin receives and acts on each request, so admin availability sets the pace | The admin who grants the right decides who can invite. Confirm in the current docs how request routing and approval work for delegates |
| Central control | Highest. Every guest enters through one group of admins who can apply one onboarding standard | Lower per invitation. Control shifts to the delegation design, the people granted rights and the policy they follow |
| Speed for project teams | Slower. Project teams wait for an admin to act on each invitation | Faster. Project leads can bring in vendors, contractors or customers without a separate admin request |
| Plan requirement | Applies to the default configuration. Confirm the guest settings your plan includes with Mattermost | Requires a Professional or Enterprise plan, per the documented defaults |
| Effect on paid seats | No change. Guests active in exactly one channel are single-channel guests and do not count toward paid seats, up to a 1:1 ratio with licensed seats | No change. The same single-channel guest rule applies regardless of who sends the invitation |
| Where it fits | Small guest populations, tightly controlled vendor onboarding and engagements where every external account needs admin review | Many project teams that work with outside parties under a written invitation policy and a named owner for each channel |
How single-channel guests affect licensed seats
A guest who belongs to exactly one active channel is a single-channel guest. Under the rule Mattermost documents, single-channel guests do not count toward paid seats, up to a ratio of 1:1 with the licensed seats on your plan. That one condition, exactly one active channel, decides how a guest is counted, so it should shape how you invite external users. Before you add a vendor, contractor or customer, decide which single channel they need and whether that channel will be the only place they ever sit. Every additional channel changes the count, so access design and seat planning belong in the same review.
The 1:1 ratio is the part that catches teams out. Free single-channel guests are capped at the number of licensed seats your organization holds, so a plan with a given seat count covers only that many single-channel guests at no seat cost. Guests beyond that cap are not covered by the free allowance. Build a simple inventory before rollout that lists every guest, the channels each one belongs to, and the date each access was granted. Ask your admins which reports or exports show per-guest channel membership in your server version, so the count can be verified from data before each renewal discussion.
The following scenario is illustrative and hypothetical, and it is not a statement of any Mattermost price or plan. Suppose an organization holds 20 licensed seats and invites 18 vendor and customer guests, each in one active channel. Those 18 are single-channel guests within the 1:1 ratio, so none of them uses a paid seat. Now one of the 18, a contractor, is added to a second channel. That contractor is no longer in exactly one active channel, so the single-channel rule no longer applies, and under the documented rule the guest is expected to count as a regular seat. Confirm that with Mattermost. Adding the same contractor to a third channel does not change the counting outcome, but it widens the access that your team has to review.
Confirm the counting logic against your current plan and license terms with Mattermost before you rely on it in a budget or renewal. Seat rules sit alongside the plan you buy, and Mattermost sells its paid plans as prepaid annual subscriptions based on seat licenses, so a count that has drifted from your license can surface at renewal. Ask for the rule in writing, including how guests are counted under your specific plan, whether a guest moving between channels changes the count immediately or at a billing point, and what happens when guests exceed the ratio. Keep a dated record of the answer and of your periodic guest review, and reconfirm the rule whenever you change plans or upgrade the server.
Setting up guest accounts in a self-hosted Mattermost
This sequence takes a self-hosted Mattermost server from disabled guest access to a tested, repeatable process for inviting an outside person into one channel. Each step closes with a check, so the owner confirms the setting works before any external person is involved.
Confirm the plan and admin roles
Confirm which Mattermost plan the organization holds and which people hold the system admin role on the self-hosted server. Guest access is enabled by a system admin, and by default only system admins can invite guests, so the people named here will own every later step. Ask your Mattermost account contact to confirm which guest permission controls your plan includes before you draft the invitation policy. Check: the named admins can sign in to the System Console and see the guest-related settings, and the plan includes the permission controls your policy needs.
Enable guest access on the server
A system admin turns on guest access in the System Console before any guest can be invited. If you run a staging server, make the change there first, then repeat it in production and record both changes in your change log so the configuration is reviewable. Confirm the setting is saved and whether your deployment needs a configuration reload or restart to apply it. Check: an admin account can see the guest invitation options, and a non-admin test account cannot.
Decide who may invite guests
Decide whether only system admins invite guests or whether a wider group, such as team admins or named staff, may do so. On Professional or Enterprise plans, set this permission deliberately, because the default keeps invitations with system admins. Write down who approves each guest request, which internal sponsor must be named for each guest, and which teams are out of bounds for outside access. Check: a non-admin test user who holds the permission can send a guest invitation, and a user without it is refused.
Create a test guest account
Create one internal test guest using an email address your team controls, so no outside person is affected while you test. Sign in with the same method external guests will use, such as the server's email sign-in or your single sign-on setup, so the test follows the path a real guest would take. Keep a standard team member account available for side-by-side comparison. Check: the test guest can sign in, and before any channel is added it sees no channels it was not invited to.
Add the test guest to one channel
Add the test guest to a single channel created for the external work, ideally one that holds no sensitive history. Keep the guest in exactly one active channel, because that status is what makes it a single-channel guest that does not count toward paid seats. Ask your account contact to confirm in writing how seat counting applies to your plan and license before you depend on it. Check: the channel's member list shows the test guest, and the guest appears in no other channel.
Verify what the guest can see
Sign in as the test guest and review everything it can reach: the channel it was added to, the team members it can view and message, and any other channels or teams it can open. Compare the results with the expectations written in the earlier steps. Confirm the guest cannot open private channels it was not added to and cannot browse channels in other teams. Check: every visible item matches the written expectations, and any gap is corrected and retested before rollout.
Roll out with an onboarding and offboarding routine
Turn the tested setup into a written routine: a request form, a named internal sponsor, an invitation step, a review date for each guest, and a removal step when the engagement ends. Offboarding should deactivate the guest account and remove it from its channels, and the routine should name the person who confirms the departed guest no longer has access. Review the routine with your security and compliance owners before the first external invitation. Check: the first external guest is onboarded under the written routine, and the sponsor can show who approved the access and when.
Security and operational considerations for external guests
Each card describes a control to design and verify in your own environment, not a guarantee the platform provides. Together they cover how outside people sign in, where they can go, how their access ends and what stays visible afterward.
Identity of outside users
Decide how each outside person signs in before you invite them. Confirm whether your SSO setup (SAML, OIDC or OAuth) and AD/LDAP user sync apply to guest accounts in your Mattermost version, since the pricing page lists these features from the Professional plan without describing guest behavior. If guests use local credentials, design the password policy, the multi-factor expectation and a named internal sponsor for every external identity.
Channel hygiene and access reviews
Keep each guest in the fewest channels that serve the engagement, because a guest in exactly one active channel is treated as a single-channel guest, and that status also affects seat counts. Assign an owner to every channel that contains guests and compare guest membership with the engagement record on a schedule your compliance team sets. By default only system admins can invite guests, so decide whether to widen that group and document who holds the permission.
Offboarding when a contract ends
Treat the end of an engagement as a defined process with an owner, a checklist and a recorded date. Remove the guest from every channel, deactivate the account and confirm that active sessions, tokens and bot integrations tied to that user stop working. Confirm how deactivation and session revocation behave in your server version, then test the checklist on a pilot guest before a large vendor engagement ends.
Retention and audit visibility of guest messages
Decide how long conversations with guests must be kept and who can search or export them. Guest messages often fall under the same policy as internal chat, but the channel may be run with another organization's staff, so confirm which retention, export and legal hold capabilities your plan and deployment include. Ask the vendor to confirm in writing how edits, deletions and channel ownership appear to an auditor before guest access goes live.
File sharing exposure
A file leaves your control once a guest downloads it, so decide which file types guests may upload and download and keep the most sensitive material in a system with narrower access. Confirm whether link sharing and previews apply to guests. Check where attachments are stored, because a high availability cluster requires shared storage that every node can read. Set attachment retention separately from message retention, and confirm whether deleting a message also removes its files.
Governing guest access over time
Guest access drifts unless someone owns it, so set up the governance routine before the first guest is invited. Decisions made at invitation time are the hardest to unwind later. Start with a naming convention that makes every guest identifiable in member lists, search results and audit exports. For example (illustrative only), a display name that ends with the sponsoring organization, such as "Jane Doe (Acme Logistics)", combined with a username prefix that internal employees cannot claim. Confirm with your identity team whether AD/LDAP sync or SSO attribute mapping can overwrite these names at the next login, because a sync that resets display names will undo the convention silently.
Every external relationship needs one named internal owner, recorded in a register kept outside Mattermost, such as your contract management system or a controlled spreadsheet. The owner is the person who requested the guest, confirms the business reason and answers when the guest's access needs to change. Record the contract reference, the sponsoring department, the channels the guest may join and the date the relationship ends. By default only system admins can invite guests, so the register should also show who asked for each invitation. If you plan to delegate invitation rights, decide that scope in writing first and confirm the current setting names in the administration guide for your server version.
Once a quarter, the owner of each relationship reviews every channel that guest can see and confirms each membership still has a business purpose. Ask the owner to remove guests from channels whose work has closed, and to check whether any private channel now holds information the guest should not see. Produce the guest list and channel memberships from the admin console or the API so the review works from actual data. Mattermost documents single-channel guests as the group that does not count toward paid seats, so a guest added to a second active channel changes both the access footprint and the licensing position. Make that check part of the same review, and confirm which export options your server version provides.
Removal should be triggered by the contract end date in the register, not by someone remembering to act. Set a reminder for the owner before each end date, and a deactivation step on the day it passes. Deactivate the guest account, then confirm it no longer appears in channel member lists. File the removal record with the contract. Review guest counts alongside your seat reports each quarter, since guests active in more than one channel count toward paid seats, while single-channel guests are free up to a 1:1 ratio with licensed seats. Ask Mattermost how guests appear in seat counts at renewal before you settle on a subscription size.
Guest accounts questions buyers ask before hiring help
How much does it cost to set up Mattermost guest accounts?
The cost has two parts: the Mattermost subscription and the implementation work. Mattermost sells Professional, Enterprise and Enterprise Advanced plans as prepaid annual subscriptions based on seat licenses. Its pricing page lists no public prices, so you need to contact Mattermost sales for plan pricing. Implementation cost depends on the scope agreed in writing with DeployOpen before work starts. The main cost drivers are the plan level you need, how many channels guests will join, whether guest sign-in goes through your identity provider or directory, and how much governance design (who invites, who approves, how access ends) you want documented. When you request a quote, ask for the subscription and implementation costs as separate line items, and ask which costs recur each year.
How long does a guest access rollout take?
The duration depends on the scope, and the written scope sets the timeline. The biggest variables are the number of channels and teams guests will use, whether guest identity must integrate with SSO or AD/LDAP, and how many approval steps your policy requires before anyone is invited. A rollout limited to enabling guest access and writing an invitation policy takes far less time than one that includes identity integration, channel structure changes and a test cycle with pilot external users. Ask for the planned phases, the decisions your team must make in each phase and the dates each phase depends on, so you can see where your own reviews will add time.
Can our own administrators set up guest accounts without a partner?
Yes, a small team can enable guest access and invite guests without outside help. A system admin must turn on guest access before any guest can be invited. By default, only system admins can invite guests, and Enterprise and Professional customers can choose who else may invite them. The harder work is usually the policy: deciding which external people qualify, which channels they may join, who approves each invitation, how guests are offboarded, and how you will show an auditor that these controls operate. Your team can do the configuration itself. Bring in a partner when you need that policy designed, documented and tested across your identity and compliance requirements.
What does our team need to provide for a guest account project?
Your team provides the decisions and access that only your organization can supply. Expect to name an accountable owner, confirm the Mattermost plan you have bought or intend to buy, and list the teams and channels external people will need. You also need a written guest policy: who may be invited, who approves invitations, what guests may see, how long access lasts and how it ends. If guest sign-in will use your identity provider or directory, provide those details and a test account. Finally, provide access to the deployment environment, a pilot group of internal users who will act as external collaborators, and time for reviews. Missing decisions are the most common cause of delay.
Do guest accounts count toward our paid Mattermost seats?
Some do not. Mattermost treats a guest who belongs to exactly one active channel as a single-channel guest. Single-channel guests do not count toward paid seats, and they are free up to a 1:1 ratio with your licensed seats. Guests who belong to more than one active channel do not get this treatment, so confirm how they are counted with Mattermost's guest accounts documentation and with sales before you invite them. For planning, count your licensed seats, list which guests will sit in one channel and which will need several, and ask the vendor to confirm the counting rule for your plan. A quote should state the seat count you assumed.
Should external guests sign in with SSO or manual invitations?
Manual invitations are simpler to start with, but they leave offboarding to people who may forget to act. SSO and AD/LDAP user sync are included from the Professional plan, according to Mattermost's pricing page, so your plan may already support them. The question to answer is whether your identity provider can hold external people with their own accounts, with access reviewed and removed when a contract ends. If it cannot, manual invitations with a documented removal step may be the workable choice. Confirm the identity options for your plan and your provider before the design is fixed, since changing sign-in methods later adds rework.
What goes wrong when guests join too many channels?
The usual problems are unplanned seat growth, unclear visibility and weak reviews. Guests added to several channels may move your count past the 1:1 single-channel allowance, which changes what you pay for. Guests may also see more conversation than the business intended if channel membership grows informally. Prevent this by setting a channel list per external group, limiting who may add guests, and reviewing guest membership on a set schedule. Ask whoever designs the system to show you how to report guest membership and channel counts, because a seat audit is far easier when the data is already organized.
How DeployOpen scopes and delivers Mattermost guest access
DeployOpen scopes Mattermost guest access as a written, fixed-scope piece of work inside your own Mattermost deployment. We set who may invite guests, how guests are confined to the channels they need, and how single-channel guests are counted against your licensed seats. Ongoing support is available as a retainer.
How we scope
- The written scope names who may invite guests and whether the default admin-only setting changes
- Scope lists the channels guests may join, the teams they must never see, and any approval steps
- Seat impact is modeled from your current user count and expected guest activity in each channel
How we build
- Enable guest access in the server administration settings and set invitation permissions your policy requires
- Configure channel membership so each guest sees only the channels named in the scope
- Test guest visibility with sample guest accounts for each role before any external user joins
How we hand over
- Written admin runbook covering invitations, removals, channel changes and seat checks
- Guest policy record listing approved inviters, guest-permitted channels and review owners
- Walkthrough with administrators so the team can invite and remove guests unaided
How we support
- Retainer covers version upgrades across monthly server releases and Extended Support Releases
- Periodic review of guest membership and seat counts against your Mattermost license
- Guest policy changes after a scope is signed go through a written change request
