Bot attributes and Burn-on-Read permissions extend ABAC to automation accounts and ephemeral messaging. Desktop v6.4 adds one Boards plugin update for subpath deployments.

A switch has two positions. Mission environments rarely have only two kinds of accounts.

Many administrative controls begin as binary: a feature is on for everyone or off for everyone. That holds until a compliance review asks who exactly can do this, and the honest answer is “all of them.”

Update to v12.1

v12.1 builds on the policy model your administrators already know. Upgrade your server to get bot attributes and Burn-on-Read permissions, and review the Mattermost upgrade guide before you begin. The full list of changes is in the v12 changelog.

Then audit your own environment. Which of your controls are still switches, and which of those switches are protecting something that deserves a policy?

v12.1 is available now. For air-gapped and sovereign configurations, contact your account team or get started.

The Question Is No Longer “Is It Enabled?”

The challenge is no longer whether a capability is turned on. It’s who holds it, under which conditions, and whether you can show why.

Mattermost v12.1 replaces two of those switches with policy. Bot accounts now carry attributes, and the ability to send Burn-on-Read messages is now a permission that attribute-based access control (ABAC) can grant to some users and withhold from others. Both ship in Mattermost Enterprise Advanced on November 16, alongside Mobile v2.46 and Desktop v6.4.

Bot Accounts Get Attributes, Not Just a Flag

Mattermost Enterprise Advanced

Bots are accounts with access, so in a governed environment they need policy like any other account. Until now, a membership policy could only ask one thing about a bot: is it a bot? That is a blunt instrument for an organization running many automation accounts with different purposes.

In v12.1, bots can have attributes. Any attribute defined in your attribute schema for users, such as department, classification, or program, is now available for bots. You assign them under Integrations, then Bot Accounts.

Consider a channel restricted to participants at a given clearance level or higher. With bot attributes, a membership policy can admit an engineering bot whose attributes qualify and keep a summarization bot out. You can test the policy before saving and see exactly which bots would gain access.

Access policies get a matching improvement. Previously, “members” included bots, so a bot-only rule meant stacking an “is bot account” condition with an OR for everyone else. Policies now have an explicit scope for bot accounts. You can allow only Summarization bots to upload and download files while confirming the engineering bot is denied.

Three details matter for rollout:

  • Who sets attributes. Setting an attribute on a bot requires the manage-bots permission, a system admin or a bot manager. Each attribute is also defined as either system-admin-managed or end-user-managed, and both conditions must be satisfied.
  • Need-to-know holds. Someone managing a bot sees only the programs they belong to, the same rule that applies to users.
  • Scope has a limit. Bot attributes apply to bot accounts that use the REST API. Plugins that go through the plugin APIs are a separate path and are not covered.

The result is cleaner segregation for customers with many bot accounts: the policy states which automation may enter which channel, and why. Read the full documentation.

Burn-on-Read Becomes a Permission

Mattermost Enterprise Advanced

Burn-on-Read removes messages from the server completely. That is the point of the feature, and it is also the tradeoff. A message that never persists is a message that cannot be audited or reviewed afterward. Some organizations will want it available to specific roles and unavailable to others. Until now, the control was an on or off setting for the whole instance.

v12.1 adds a new action to permission policies, “Create Burn-on-Read message,” listed alongside upload and download files. It controls who can send. Everyone can still receive Burn-on-Read posts as long as the feature is enabled for the instance.

The behavior is immediate. Write a rule that says only the department Engineering can send Burn-on-Read messages and immediately the option disappears for Product users, while all groups can still receive and view Burn-on-Read posts.

You can also apply the restriction at the channel level. Block creation in one channel, and the option is gone there while remaining available elsewhere.

Mobile now renders permissions too. The option disappears from the mobile composer when policy removes it, and the interface updates live as policies change. As more features gain permission actions, the UI will reflect enforcement rather than waiting for the server to refuse an action. Read the full feature documentation.

Desktop v6.4: One Action for Subpath Deployments

Breaking change

Mattermost Desktop App v6.4 requires servers configured with a subpath in their Site URL to update the Boards plugin to v9.4.0 or later.

You can update Boards from the Marketplace without a server upgrade. Deployments without a subpath are unaffected. If you are unsure which applies to you, check your Site URL before the November 16 release. Read more about the breaking change.