Why classification labels in Collabora Online matter for document handling
Your users need to mark documents by sensitivity while they are still in the browser editor, and those marks need to survive once a file leaves the platform. From Collabora Online 26.04, Writer, Calc and Impress can apply organisation-defined classification labels, which appear in document banners, headers, footers, watermarks and content, and are preserved in DOCX, XLSX and PPTX files. That gives you a way to put the handling marking where the author works, rather than relying on a separate step after the file is saved or downloaded. Teams usually need this when documents are created and edited in the browser, then shared with partners, printed, or opened later in desktop Microsoft Office, where a visible marking tells the next reader how to treat the content.
Labels are a marking control, not an enforcement control. A visible label does not stop someone from opening, copying, forwarding or printing a file, and it does not encrypt anything. Access to documents still depends on your identity provider, the permissions set in your integrating platform (for example, group limits on who can use or edit in Nextcloud Office), and storage encryption. Data loss prevention tooling is what inspects labelled content on the way out. Before rollout, confirm with your own security team which label taxonomy your policy defines, who is allowed to change or remove a label, and how labels will be checked after a round trip through your other tools. Test with representative DOCX, XLSX and PPTX files from your own environment, since a label that is preserved in one tool may be treated differently in another.
Label placement options and when each fits a data handling policy
This table compares the five placements the 26.04 release notes describe (banner, header, footer, watermark and content) against common policy needs such as recipient visibility, print behaviour and removal risk. Read each row as a question to confirm in your own pilot, since the release notes do not describe print or removal behaviour in detail. The main takeaway is that placement choice is a policy decision as much as a visual one.
| Placement | What it does | Policy fit and what to confirm |
|---|---|---|
| Banner | Shows the label as a prominent line at the top of the document view | Good for visibility to readers. Confirm whether the banner is part of the saved file or only displayed in the editor. |
| Header | Places the label in the page header on every page | Suits printed copies and print-based handling. Confirm that the label survives a DOCX export and is not overwritten by a template header. |
| Footer | Places the label in the page footer on every page | Common for marking classification on printed pages. Confirm the same DOCX and PDF output behaviour as headers. |
| Watermark | Overlays the label across the page body | Strongest visual signal for copies. Confirm legibility on print and whether it affects readability for users with accessibility needs. |
| Content | Writes the label as text within the document body | Hardest to remove unintentionally, but it becomes part of editable text. Confirm how it appears in tracked changes and how it is found during later review. |
| Removal risk | Ease with which an editor can delete or change the label | Headers, footers and banners are easier to edit than content text. Confirm who can edit labels and whether the integrating platform restricts editing rights. |
| Recipient visibility | How clearly a recipient sees the label when opening the file | Banners and watermarks are most visible. Confirm how labels appear when the file is opened in desktop Microsoft Office. |
Whether labels survive DOCX, XLSX and PPTX round trips
The Collabora Online 26.04 release notes state that Writer, Calc and Impress preserve classification labels in DOCX, XLSX and PPTX files. That statement is the starting point for your test plan, not the finish line. Preservation depends on the file passing through Collabora Online and then through whichever Office application your recipients use, so you need evidence for each path your documents actually take. DeployOpen would run a documented test set against your own label definitions and sample files rather than assume the label survives. Confirm the exact behavior with Collabora and in your own environment before you rely on it for handling decisions.
The test set should follow the life of a document. Create a labeled document in each of Writer, Calc and Impress, then save it, close it, reopen it in Collabora Online and confirm the label still appears in the banner, header, footer, watermark and body content where your policy requires it. Re-save the file, repeat the reopen check, and then export the same file to PDF to see which label elements carry into the output. Next, open the saved DOCX, XLSX and PPTX files in Microsoft Office and in any other tools your organization uses, such as LibreOffice desktop or a document management viewer, and record which label elements survive each conversion. Use one sample per label level and per file type so that a failure points to a specific step.
Record every result in a table that names the Collabora Online version, the label configuration, the file type, the step and the receiving application. Treat any step that drops or alters a label as a finding that needs an owner. Typical decisions include blocking a format for a classification level, requiring PDF export for external sharing, or adding a check in the integrating platform. Ask Collabora and your integration vendor which label elements are guaranteed in each format, and plan to repeat the test set after each point release, since a fix or regression can change results between versions.
How to roll out classification labels in a Collabora Online deployment
This sequence moves classification labels from a written policy to tested, user-supported use in Writer, Calc and Impress on Collabora Online 26.04. Each step ends with a check so the label scheme is proven in your environment before it reaches the wider user base.
Write the policy and label taxonomy
Your information security or data governance owner defines the classification levels, what each level means for handling, who may apply or change a label, and which document types must carry one. Map each level to the handling rules it drives, such as sharing, external transfer and printing. Confirm the final taxonomy with the data owners and record it as an approved, versioned document. The step is done when every label has a definition, a handling rule and a named owner.
Confirm the 26.04 label configuration path
Before any build work, your platform team reads the Collabora Online 26.04 release notes and confirms with Collabora how organisation-defined labels are configured, where the label text, banner, header, footer and watermark settings live, and whether labels can be set per deployment or per integrating platform. Record any gap, such as a setting you cannot yet find in documentation, as an open question for the vendor. The step is done when each taxonomy level maps to a confirmed configuration method or a logged question.
Deploy a 26.04 test instance
Install a Collabora Online 26.04 test instance in an environment that mirrors production, using the same WOPI host, such as Nextcloud, and the same reverse proxy and TLS settings. Use a supported release rather than CODE if the test will inform a production decision, because CODE is described by Collabora as not recommended for production. Apply the labels you configured in step two. The step is done when a test user can open, label and save a document from the integrating platform without errors.
Run round-trip tests on representative files
Build a test set of representative DOCX, XLSX and PPTX files that includes existing labelled documents, unlabelled documents, files with tracked changes, comments, headers, footers, embedded objects and large spreadsheets. Apply each label in Writer, Calc and Impress, save, download, and reopen in Microsoft Office and in Collabora Online. Compare banners, headers, footers, watermarks and label metadata before and after each round trip. The step is done when every test file keeps its label through the round trip, and every failure is logged with the file, application and steps to reproduce.
Pilot with one user group
Choose a pilot group whose work covers all three applications and the highest-sensitivity documents they handle. Give them the approved taxonomy, a feedback channel and a clear rule for documents that fail a round trip. Monitor which labels are applied, which files are reopened in other tools, and where users report that a label was lost or appeared incorrectly. The step is done when the pilot has run through its planned period, every reported defect is either fixed, accepted in writing by the policy owner or blocked from wider use.
Publish user guidance and governance
Write short guidance for users that explains each label, when to apply it, how to change it, what happens when a file leaves the organisation, and who to contact. Record the known limitations found in testing so users do not rely on behaviour that was not verified. Agree with the policy owner how label changes, configuration updates and future Collabora Online upgrades will be re-tested against the same file set. The step is done when guidance is published, the limitations list is attached, and the re-test trigger is written into your change process.
Security and operational considerations for labels in Collabora Online
A classification label tells people how to handle a document. It does not, by itself, decide who can open it, encrypt it or stop a copy. The cards below cover the gaps a label leaves open, and the change control, logging and user behavior that keep the label meaningful after rollout.
Labels are visible text, not controls
A label that appears in a banner, header, footer or watermark is content the editor can see and, in most cases, change. Users may remove, retype or alter it before saving, and a label applied by Collabora Online does not prove who applied it. Check whether your DOCX, XLSX and PPTX consumers treat the label as informational only, and document that the label is a handling cue rather than an authorization decision.
Access control stays in the host platform
Who can open or edit a file is decided by the WOPI host, such as Nextcloud, and its group and share settings, not by the label. Nextcloud Office lets administrators limit which groups can use the editor and which can edit rather than only view. Confirm those group limits match the classifications in your policy, because a label on a file open to a broad group does not restrict that group.
Encryption at rest is a separate decision
Labels do not encrypt document content. Confidential files stored on the host, in backups, or in transit between the browser and the server depend on the storage encryption, TLS and backup encryption you configure in your own infrastructure. Write down which layer protects which classification level, and confirm with the host platform how it stores and caches document data during an editing session.
Copy and download restrictions need another layer
A label does not stop copying, printing, or downloading a file. Where those restrictions are required, use the host's own controls. The sibling topic on watermarking and download restrictions with Nextcloud secure view covers this area. Before you rely on any restriction, test it in your environment with a file at each classification level, because restrictions depend on the host and the editing session.
Change control for the label set
The label names, their wording, the banner text and the rules for when each applies are policy artifacts. Keep them under version control with a named owner, an approval step and a record of changes. Because labels are written into documents, a renamed label leaves older files carrying the old text, so agree how legacy labels will be read and whether they are re-applied during a review cycle.
Logs and audit evidence
Auditors will ask who applied or changed a label, when, and on which file. Confirm which events Collabora Online and your WOPI host write to their logs, where those logs are kept, how long they are retained and who can read them. Where the host does not record label changes, decide whether document version history or a periodic scan of stored files will serve as evidence instead.
Operator and user guidance
Users need short, specific guidance on choosing a label, what each label obliges them to do, and who to ask when unsure. Operators need a runbook for handling a mislabeled file and for confirming that a label survives a round trip after an upgrade. Review the guidance whenever the label set changes or a new Collabora Online branch is deployed.
Fitting labels to your data handling policy by audience
Policy owners decide the classification taxonomy: how many levels exist, what each label means, and what handling rules attach to it. The label is only as useful as the definition behind it, so this group must write meanings that a non-specialist can apply to a real document in a few seconds. Collabora Online 26.04 renders labels from organisation-defined values, which means the scheme is yours to design, not a vendor default.
- Label names and meanings: a short definition for each level, with examples of what belongs at that level and what does not.
- Handling rules per label: who may view, edit, share externally or print, written in terms the platform team can enforce or document.
- Banner and marking text: the exact wording that appears in banners, headers, footers and watermarks, approved by legal or compliance.
- Default and escalation rules: which label applies when a user is unsure, and who resolves disputes.
- Review cycle: who owns changes to the taxonomy and how changes reach existing documents.
Check that the policy is written before the platform configuration starts, and that every label has a named owner who can answer questions from users.
Platform teams turn the approved taxonomy into configuration and keep it working through upgrades. Their work sits in the deployment, not in the editor's user interface, so they need to confirm how label definitions are supplied to Collabora Online, where they are stored, and how they are versioned. Treat the label set as configuration under change control, the same way you treat other security settings.
- Label definitions as configuration: how labels are loaded into each Collabora Online server, and whether the same set reaches every node in a cluster.
- Round-trip testing: a test set of DOCX, XLSX and PPTX files that confirms labels survive save, reopen and export.
- Integration behavior: how the host platform, such as Nextcloud, passes user context and whether it can enforce the same labels.
- Upgrade regression checks: re-running the test set on each new branch before rollout, since label handling is a release-level feature.
- Change records: a log of which label set version is live and when it changed.
Confirm the exact configuration method with Collabora's 26.04 documentation and your own environment before writing runbooks, because the supplied release information describes the feature but not every setting.
End users apply and change labels while they write, so their guidance must be short and concrete. They need to know when a label applies, who to ask when a document sits between two levels, and what happens when they change a label on a file that others have already shared. Training should use real examples from your own document types rather than abstract definitions.
- When to apply a label: the trigger for each level, such as the first draft of a client contract or a payroll spreadsheet.
- When to change a label: the events that require a review, such as publication, reclassification or a project closing.
- Where the label shows: banners, headers, footers and watermarks, so users know what the marking looks like once applied.
- Who to contact: a named role for questions, not a generic mailbox.
- What not to do: removing a banner or editing a marking to hide a label, and the reporting route if this happens by accident.
Before rollout, ask a small pilot group to label five or six of their own documents and report where the guidance was unclear, then update the written instructions from those answers.
Limits to confirm before relying on labels for compliance
The 26.04 release notes establish that labels can be applied and preserved in DOCX, XLSX and PPTX files. They do not, on their own, establish how far a label can be enforced, how it behaves in every file type, or how other tools read it. Treat each item below as a test to run in a non-production environment before a label scheme becomes part of your data handling policy.
Supported label definitions
Confirm which label schemes Writer, Calc and Impress accept. Ask whether an organization can define its own label names, colors, banner text and placement, or whether the set is fixed. Check whether labels can carry a hierarchy such as public, internal and confidential, and whether a label can be renamed without re-labeling existing documents. Your classification policy should match what the product can express, not the reverse.
Display only or enforced
A label that appears in a banner is not the same as a control. Confirm whether the editor can block export, printing or copying for a labeled document, or whether it only displays the label. If enforcement depends on the integrating platform, such as the download and view restrictions in Nextcloud, document that split of responsibility and test it end to end.
Macros and legacy formats
Test labeled files that contain macros, embedded objects and older binary formats such as DOC, XLS and PPT. Confirm whether the label survives a save as DOCX, XLSX or PPTX, whether it is removed when a macro-enabled file is saved, and whether it is retained when a file is opened and re-saved by a different editor. Record the results per format, because preservation is confirmed only for the three OOXML formats named in the release notes.
Interaction with the AI assistant
The AI assistant is optional and off by default in 26.04. If you enable it, confirm whether a labeled document's content, banner or metadata is sent to the configured provider, and whether that behavior changes between an external provider and a model on your own infrastructure. Link this check to your policy on which labels may leave your environment, and confirm the answer in writing with Collabora before you rely on it.
Readability by DLP tools
Confirm where the label is stored inside the file, such as in document properties, custom XML parts or visible text only. A label that exists only as visible text may not be readable by a data loss prevention scanner. Ask your DLP vendor which OOXML metadata locations it inspects, then run a sample labeled file through that tool to confirm it reads the value you expect.
Label changes across versions
Labels added in 26.04 are a new capability, so files labeled by 25.04 or earlier deployments will not carry them. Confirm how a label applied in one version behaves when the same file is opened in an older branch that is still in service, and whether a label can be changed or removed after a document is shared. Record the version you tested so results can be repeated after a future upgrade.
Questions buyers ask about classification labels in Collabora Online
Does a classification label in Collabora Online enforce access to a document?
No. A label marks the document so people can see its classification, but the label itself does not decide who can open, edit or share the file. From Collabora Online 26.04, Writer, Calc and Impress can apply organisation-defined labels that appear in banners, headers, footers, watermarks and content, and they are preserved in DOCX, XLSX and PPTX files, according to the Collabora Online 26.04 release notes. Access control stays with the integrating platform. In Nextcloud, for example, administrators decide which groups can use the editor and which can edit rather than only view. Plan the access rules in the host and treat the label as the visible signal that the policy applies.
What drives the effort and cost of rolling out classification labels?
The main drivers are the number of classification levels, how many people and document types are in scope, and how much the labels must match existing policy wording. Costs fall into three groups: internal time from policy, IT and document owners; the Collabora Online subscription or self-hosted running costs; and any partner work for configuration or testing. The Collabora Online pricing page lists the Business plan at 3 euros per user per month for up to 99 users, which includes long term support, a service level agreement and signed security updates. Ask any quote to separate one-time design and testing from recurring subscription and support.
What does the rollout need from our policy and IT teams?
Policy owners need to define the label set, the wording for each level and the handling rules that go with it. IT teams need to decide where labels are applied, how the host platform restricts access, and how the labels are checked after files leave the editor. Document owners need a short guide on when each label applies. Before go-live, test representative DOCX, XLSX and PPTX files through a round trip, because the release notes state preservation for those formats but your own templates, macros and layouts should be checked as well.
Can our own team configure classification labels without a partner?
Yes, it is possible for a capable team to configure labels, provided they have access to the Collabora Online 26.04 installation and the policy wording is settled. Confirm the exact configuration method, file location and admin options against the 26.04 documentation before planning the work, because this page does not set out those steps. Teams that lack a test environment or have not run an editor upgrade before may find an outside review of the design and test plan worthwhile.
Which Collabora Online version do we need for classification labels?
Classification labels require Collabora Online 26.04 or later, since that release introduced the feature for Writer, Calc and Impress. Earlier branches, including 25.04, do not provide this feature according to the 26.04 release notes, so an upgrade is needed first if you run an older version. Check the current point release on the release notes page before rollout, because security fixes arrive in point releases and the 25.04 line, for example, received point releases into 2026.
How do upgrades affect labels that already exist in documents?
Labels already present in DOCX, XLSX and PPTX files are expected to remain in the file because the feature preserves them in those formats, according to the 26.04 release notes. Still, verify this on your own documents before and after an upgrade, including files that other tools created or that were edited in older versions. Keep a copy of a sample set, record what labels look like before the change, and compare the results. Ask your provider to include this check in the upgrade scope.
Does the AI assistant in 26.04 affect how labels work?
The optional AI assistant is off by default in 26.04, so labels work without it. If you enable it, administrators choose the AI provider and whether it is hosted externally or on their own infrastructure. Decide that setting with your data handling policy in mind, because classified content should not go to a provider your policy does not allow. Confirm the interaction between the assistant and labelled content in your own test environment before enabling it.
How DeployOpen scopes and delivers label rollouts
A label rollout starts with a written scope agreed before any work begins, because the decisions that matter most are organizational: which labels exist, what each one means for handling, and where each one must appear. DeployOpen's fixed-scope approach puts those decisions into a policy mapping workshop with your security, compliance and records owners. The workshop turns your data handling policy into a label set, a placement rule for each label (banner, header, footer, watermark or body content) and a list of which document types and applications the rule covers. The output is a signed-off scope document that names the Collabora Online version in use, the Writer, Calc and Impress behaviors in scope, and the integrations that will read or write labels. Ask for this document to list what is excluded as well as what is included.
Next comes a test plan built on representative files that your own teams produce. DeployOpen proposes a sample set of DOCX, XLSX and PPTX documents covering templates, tracked changes, embedded objects, linked content, and files already labeled by another tool, then records how each label is applied, displayed and preserved after a round trip through Collabora Online and back to the originating platform. Confirm with your vendor how the 26.04 label feature handles files that already carry labels from other systems, because that case is often where rollouts fail. Deployment then takes place on your own cloud accounts, data centers or air-gapped networks, with the configuration, test evidence and change records handed over to your team.
Support is priced separately from the build and recurs for as long as you need it. A support retainer covers upgrades to later Collabora Online branches, retesting of the label set after each release, and changes to the policy mapping when your classification scheme changes. Ask any partner, including DeployOpen, to state in the quote which of these items are one-time and which recur, and who pays for the test files and label policy reviews. DeployOpen does not issue audit reports or attestations. Independent auditors assess whether your controls meet your obligations, and the evidence produced here is designed to support that assessment.
