How the Collabora Online and EGroupware integration works for your users
If your EGroupware team wants to create and edit office files without leaving the groupware, the core requirement is a browser editor that EGroupware can call on demand. According to Collabora's EGroupware partner page, the integration lets EGroupware users create, open and edit text documents, spreadsheets and presentations directly from within EGroupware. Collabora Online is the editing service in that arrangement. It connects to EGroupware through WOPI, the protocol in which the host (EGroupware) hands a document to the editor by URL, the editor opens it in the browser, and saves go back to the host. Users stay in the file manager they already use, and the documents remain in your EGroupware storage rather than in a separate editing service.
Because the editor reaches EGroupware over WOPI, the user experience depends on a few things you control: which file types open in the editor, whether users can edit or only view, and whether the browser can reach both EGroupware and the Collabora server over the same secure scheme. Collabora's partner page is the supplied source for the integration itself, but it does not give the menu paths, configuration keys or EGroupware version requirements you will need during setup. Confirm those for your target release with EGroupware's documentation and Collabora's Online documentation before you commit to a design. Pin the exact EGroupware and Collabora Online versions you will run, since the release you pick determines which settings are available.
During scoping, DeployOpen confirms these points with your team: the EGroupware version and how its file manager is used, the file types your users create and edit, which groups may edit versus view, how the Collabora server is named and reached from user browsers, and whether the EGroupware and Collabora servers sit in the same network zone. Those answers decide the setup sequence and the access control work described in the sections that follow, and they should be written into the scope before any configuration begins.
What the Collabora Online and EGroupware integration needs before setup
Four components have to be in place before the integration can work: a self-hosted EGroupware server, a Collabora Online server, secure connectivity between them, and administrator access on both. Confirm each one with the vendor and in your own environment before you schedule the change window.
Self-hosted EGroupware server
Confirm which EGroupware release your organization runs and that it is a server you operate, not a hosted service you cannot configure. Check with EGroupware that the release you plan to use supports the Collabora Online connection described in the partner documentation. Record the release number now, because the setup steps and the file manager behavior depend on it. Confirm that the file manager is enabled for the users who will create and edit documents.
Collabora Online server
Choose how the Collabora Online server will run: Docker, a system package, or Kubernetes. Use CODE only for testing, because Collabora does not recommend it for production. For a production server, confirm with Collabora which subscription plan and support terms apply to your user count. Plan the server so it sits in infrastructure you control and can reach the EGroupware server.
HTTPS on both servers
Serve EGroupware and Collabora Online over HTTPS and use the same protocol for the Collabora server URL as for EGroupware. Mixed HTTP and HTTPS settings are a common cause of blocked editing sessions. Confirm with Collabora and with your EGroupware documentation which URLs must be set in each configuration, and test that the browser loads both sites without warnings.
Network reachability
Map every connection before setup. Users' browsers must reach the Collabora Online server, and the EGroupware server must reach the Collabora Online server for WOPI requests. Confirm which ports and paths your firewalls, reverse proxies and load balancers allow. If you restrict WOPI requests to known Collabora server addresses, document those addresses and keep them current.
DNS and certificates
Create stable DNS names for both the EGroupware and Collabora Online servers and issue certificates that match those names. Confirm that the certificate chain is trusted by the browsers your users run and by the EGroupware server itself, because an untrusted certificate on either side can block editing. Plan certificate renewal before go-live so the integration does not fail on an expiry date.
Administrator accounts on each system
Name one administrator for EGroupware and one for the Collabora Online server, with the access needed to change configuration and restart services. Confirm which accounts can change the integration settings and who can review logs when a user cannot open a document. Keep the accounts separate from ordinary user accounts so access can be granted and removed without affecting daily use.
How EGroupware's file manager hands documents to the editor
When a user creates or opens a file from the EGroupware file manager, the document does not leave EGroupware storage as a download. The integration works by WOPI: EGroupware gives the Collabora Online server a reference to the file and an access token for one editing session, and the Collabora server then fetches the file from EGroupware over HTTPS. The browser loads the editor from Collabora, so the user sees a full office editing interface inside the EGroupware session while the document is served by the two servers you run. Collabora's partner page for EGroupware describes the result as users creating, opening and editing text documents, spreadsheets and presentations directly from within EGroupware. It does not spell out the internal request sequence, so treat the description above as the WOPI model Collabora documents across its integrations, and confirm the exact handoff before you rely on it.
Saves follow the same path in reverse. As the user edits, the Collabora server writes changes back to EGroupware through the WOPI host endpoints, which means the file version in EGroupware storage is what matters for backup, versioning and audit. Ask your EGroupware contact which release you are targeting, whether the integration ships as a built-in feature or as an app or connector that you install and configure, which WOPI endpoints that component implements, and how it handles locking, conflicting saves and version history. Those answers decide where you need to look for logs when a save fails, and whether file ownership and sharing rules in EGroupware carry over to the editing session unchanged.
Configuring EGroupware and Collabora Online step by step
This sequence connects a self-hosted Collabora Online server to EGroupware's file manager over WOPI, so users can create, open and save office documents in the browser. Each step ends with a check you can run before moving on, so faults surface at the layer where they occur.
Deploy Collabora Online behind HTTPS
Your infrastructure or platform team installs Collabora Online using the Docker image, system packages or Kubernetes option that fits your environment, then places it behind a reverse proxy with a TLS certificate on a stable hostname that does not change after go-live. Confirm the exact package or image version you intend to run against the Collabora Online release notes before you install, because the 25.04 and 26.04 branches differ in their point releases and features. The step is complete when the server answers over HTTPS on the chosen hostname and the certificate chain validates from a client outside the server.
Confirm the WOPI discovery endpoint responds
From a machine that can reach EGroupware, request the Collabora Online discovery URL and confirm it returns the WOPI discovery document listing the supported file types. Check that the hostname in the response matches the public hostname you chose in the previous step, since mismatched hostnames are a common cause of failed opens. Confirm the discovery path for your version with Collabora's documentation, because the path is a configuration value you must not guess. The step is complete when the discovery document loads without certificate warnings and lists the document types you plan to edit.
Register the Collabora server in EGroupware
An EGroupware administrator opens the office or collaboration settings in the administration area and enters the Collabora Online server URL and the discovery location in the form EGroupware expects. Use the same protocol and hostname that users will reach, and confirm the exact field names and any required options for your EGroupware release with the EGroupware documentation or the Collabora partner page. Save the configuration and reload the settings page to confirm the values persisted. The step is complete when EGroupware shows the Collabora integration as enabled and reports no connection error on its own check.
Set the WOPI host and allowed origins
Configure Collabora Online to accept WOPI requests only from your EGroupware server, using the WOPI host allow list and the EGroupware URL as the permitted origin. Add the EGroupware public hostname and any internal address it uses to reach Collabora, and restrict the list to the addresses you have confirmed. Restricting requests to known source addresses follows the approach the Nextcloud administration manual recommends for its own Collabora integration, and the same principle applies here. The step is complete when EGroupware can request a document session and a request from an unlisted host is refused in your logs.
Configure supported file types and editing permissions
Decide which document types EGroupware should open in Collabora Online, covering OpenDocument text, spreadsheet and presentation files, and Microsoft formats such as docx, xlsx and pptx. Confirm in the EGroupware settings which extensions are mapped to the editor and which groups may edit rather than only view, since the Collabora product page lists supported formats but EGroupware controls which ones it routes to the editor. Record the mapping so auditors and support staff can see what is enabled. The step is complete when a test file of each enabled type shows the editor option in the file manager and disabled types do not.
Test create, open and save with a pilot group
Using a pilot account in a non-production or limited group, create a new text document, a spreadsheet and a presentation from inside EGroupware, then reopen each one and make a visible edit. Save the changes and confirm that the new version appears in EGroupware's file storage with the expected name, size and modification time. Repeat the test with a second user viewing the same document to confirm that the session routes correctly. The step is complete when create, open, edit and save all succeed for each document type and the saved content is verified in the stored file.
Document settings and confirm the update channel
Record the Collabora Online version, the EGroupware version, the hostnames, the allow list entries and the file type mapping in your configuration documentation so the setup can be reproduced and audited. Confirm which Collabora release branch you are on, and whether you run the free CODE edition or a supported subscription, since the CODE edition is described as not recommended for production. Ask Collabora or check the pricing page for the support terms that apply to your plan before go-live. The step is complete when the configuration record is stored with your other infrastructure documentation and the owner of Collabora patching is named.
Mapping EGroupware users, groups and files to editing rights
This table compares the EGroupware objects that typically shape who can open, view and edit a document through Collabora Online. Read each row as a question to answer in your target EGroupware release, because no connector-level mapping detail has been confirmed for this integration. The main takeaway is that EGroupware's own permissions decide access, so the mapping must be tested with real accounts before rollout.
| EGroupware object | What it controls in the integration | What to confirm |
|---|---|---|
| User | The account that opens a document in the editor and the identity the editor session is tied to, which affects who can reach the file at all. | Confirm which user identity is passed to Collabora Online and whether it is the same account used for file access in EGroupware. |
| Group | Whether a group can open files from the file manager in the editor, and whether it can be limited to view only if the connector supports that split. | Confirm whether group membership alone can separate view and edit rights, or whether a second control is needed. |
| File | Whether a specific document can be opened and saved from the editor, based on the access EGroupware already grants on that file. | Confirm that a read-only file in EGroupware opens read-only in the editor and that saves are refused without write access. |
| Folder | Inherited access to documents inside it, which determines the scope of editing for everyone who can see the folder. | Confirm whether folder permissions are inherited by files created or uploaded through the editor. |
| File ownership | The owner who created a document from the editor, and the default rights the owner holds over later edits and sharing. | Confirm who owns a document created from the editor and whether ownership changes when the file is moved or shared. |
| Sharing settings | Links or shares that give access to a document without a direct account, which can widen editing beyond the intended group. | Confirm whether shared links can open the editor, whether they can grant edit rights, and how they expire. |
| Collabora Online server access | Whether the Collabora server accepts requests only from the EGroupware host, which limits who can reach the editor endpoint. | Confirm the WOPI host allow list and the network path between EGroupware and the Collabora server in your setup. |
Access control and hardening for EGroupware editing
EGroupware editing through Collabora Online depends on three things working together: which hosts may send WOPI requests, who is allowed to open and edit documents, and whether the editor stays patched. The cards below cover those controls and the checks to run before go-live. Detailed hardening steps belong to the Collabora Online security hardening pages and must be verified against the exact versions you deploy.
Restrict WOPI requests by address
Limit which addresses can send WOPI requests to Collabora Online, so only your EGroupware server and the Collabora servers you operate can reach the editing endpoints. The Nextcloud administration manual recommends this kind of IP restriction for its own integration, and the same principle can be applied to EGroupware by analogy. Confirm with Collabora and your EGroupware version whether the WOPI host allow list is supported, and test that legitimate sessions still open after you apply it.
Use HTTPS for the Collabora URL
Serve the Collabora Online URL over HTTPS and match the protocol used by EGroupware, so browsers and the WOPI exchange do not fall back to mixed-content or plain HTTP paths. The Nextcloud guidance recommends using the same protocol for both sides, preferably HTTPS. Check the certificate chain and renewal process on the reverse proxy in front of Collabora, because an expired certificate stops editing for every user at once.
Limit editing to approved groups
Decide which EGroupware users and groups can open documents in the editor and which of them can edit rather than only view. Nextcloud Office offers this split between using the editor and editing, and EGroupware access rights should be mapped to the same decision before rollout. Ask the integration provider how EGroupware permissions are passed to Collabora, and test with a read-only account and an editing account.
Keep Collabora Online patched
Track Collabora's security advisories and release notes for the branch you run, and schedule point releases as a standing task. The 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623, and that package signing keys were updated for RPM and DEB users. Confirm the current supported branch and update path before you commit to a version, and verify the signing keys on your package sources.
Account for MPL-2.0 licensing
The Collabora Online server code is licensed under the Mozilla Public License 2.0, which governs how you may modify and redistribute the server code. Review your own changes to the editor or connector code against those terms, and record which edition and branch you run, since CODE and the paid Business and Enterprise plans carry different support and update commitments. Ask your legal or compliance team to confirm obligations for your specific setup.
Log access and editing events
Decide what EGroupware and Collabora logs you need to answer who opened, edited or shared a document and when. Confirm which events each component writes, where they are stored, how long they are kept, and whether they reach your central log platform. Test a sample edit session end to end, so the log entries you rely on during an investigation actually exist.
Choosing where Collabora Online runs for EGroupware
Running Collabora Online in a Docker container on the same host as EGroupware is the simplest layout to build and reason about. The editor shares the machine's CPU, memory and network interface with EGroupware and its database, so every request between the two stays local and nothing new needs to be opened to the internet. This model suits small teams and test environments, and it keeps the number of moving parts low during evaluation.
- Network exposure: Only the reverse proxy in front of EGroupware and Collabora needs to be reachable from users. The WOPI traffic between the two services can stay on the host's internal interface, which narrows what an attacker can reach.
- Patching: EGroupware and Collabora share one host, so an operating system or Docker update can interrupt both services at once. Plan a maintenance window that covers both.
- Resource contention: Editing sessions compete with EGroupware's PHP and database work for the same cores and memory. Measure this under your expected concurrency before you commit.
- Load balancing: There is one Collabora instance, so no WOPISrc routing is needed. This is a real simplification, but it also means there is no second instance to take over during a failure.
- Free edition terms: The free CODE image is described by Collabora as suited to testing, home use or small teams and not recommended for production. Confirm which edition fits your use before going live.
Before you choose this model, confirm with your own environment whether one host can carry both workloads at peak use.
A dedicated Collabora server runs on its own machine or virtual machine, separate from EGroupware. The EGroupware server then calls the Collabora server over the network, and users reach the editor through a URL you publish. This layout isolates the editor's resource use and lets you patch each service on its own schedule. It is the usual choice once concurrency grows or when the security team wants the editor in a separate network zone.
- Network exposure: The Collabora host needs an allowed path from users' browsers and from the EGroupware server. Restrict WOPI access to the EGroupware server's address where your network design allows it, as the Nextcloud administration manual recommends for its own Collabora setup.
- Patching: You can apply Collabora point releases, such as those Collabora publishes for its branches, without restarting EGroupware. Subscribe to Collabora's release notes so security fixes reach your change calendar.
- Protocol consistency: Use the same protocol for the Collabora URL as for EGroupware, preferably HTTPS, so browsers do not block mixed content.
- Load balancing: A single dedicated instance still needs no WOPISrc routing. Plan a second instance only if you accept that the switch between instances is a manual step for open documents.
- Cost components: Infrastructure for a second host, its TLS certificates and its monitoring are recurring costs. Ask any partner to list them separately in a quote.
Before you choose this model, confirm the firewall rules and DNS names your security team requires between the two hosts.
Kubernetes suits organizations that already run clusters and need several Collabora replicas. The official Helm chart supports Nginx, HAProxy and OpenShift Router ingress, and it sets resource requests and limits for each pod. The main design point is that Collabora editing sessions are stateful, so scaling and routing need more care than with a stateless web application.
- Autoscaling: The Helm chart README states that horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste. Set the replica count manually and change it only during planned windows.
- Load balancing: The load balancer must route by the WOPISrc parameter, so all users editing one document reach the same pod. Test this routing with two users on one document before you rely on it.
- Sizing reference: The chart README recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. Treat these as the chart's reference values and validate them against your expected concurrency.
- Network exposure: Ingress controllers and network policies become part of the exposure model. Confirm which namespaces can reach the Collabora service.
- Patching: Rolling updates reduce downtime, but active sessions still need a planned window. Confirm how your chosen chart version handles upgrades.
Before you choose this model, confirm that your platform team can operate WOPISrc-aware routing and that your load test matches real editing patterns.
How to test create, open and save before users rely on it
Before EGroupware users depend on the editor, run a short test plan that covers the full document lifecycle: create, open, edit, save and confirm. Start by creating a text document, a spreadsheet and a presentation from inside EGroupware's file manager, not from Collabora Online directly, because the test should exercise the same path your users will take. For each new file, confirm that the editor opens in the browser, that the file appears in the expected folder in EGroupware, and that a reload shows the content you typed. Record the EGroupware version, the Collabora Online version and the browser used, so a failure can be traced to a specific combination later.
Next, open existing files in each format class your users will meet: OpenDocument, docx, xlsx, pptx and PDF. Use a second, separate EGroupware user to edit one of those documents at the same time as the first user, and watch whether both sessions show each other's changes. Then save from one session, check the version stored in EGroupware's file storage, and confirm that the saved file opens again with the expected content. Finally, sign in as a user without edit rights and confirm that the document opens read-only and that no edit controls or save actions are offered. Access rules inside EGroupware and the WOPI settings that connect it to Collabora Online should both be confirmed, because they are separate layers and either can grant or block editing.
Keep the test data representative but not production. Use copies or synthetic documents that include tables, images, tracked content, fonts and the formatting your organization relies on, and never open live business records in a test tenant. Format fidelity, meaning how closely a converted file matches its original, is covered on the file format compatibility page, so this plan only confirms that the workflow works. Ask your DeployOpen contact to confirm the exact EGroupware and Collabora Online versions in scope and whether your EGroupware setup needs any further settings before the test can be run.
Common EGroupware and Collabora Online failures and how to fix them
This table pairs common symptoms in an EGroupware and Collabora Online setup with their likely causes and the first checks to run. Read it from the symptom down, starting with the cause that matches what users report. Detailed steps for each area are in the Collabora Online operations and troubleshooting pages.
| Symptom | Likely cause | Fix or check |
|---|---|---|
| Editor does not load when a user opens a document | The EGroupware server cannot reach the Collabora Online discovery URL, or the URL in EGroupware does not match the Collabora server | Confirm the Collabora server address configured in EGroupware, then test that the discovery endpoint answers from the EGroupware host and from the user's browser network |
| Browser reports certificate errors or blocked mixed content | EGroupware is served over HTTPS but the Collabora URL uses HTTP, or the certificate does not cover the hostname in use | Serve both EGroupware and Collabora over HTTPS with the same protocol and a certificate that matches each hostname, then reload the configuration |
| Documents fail to open with a WOPI or host-not-allowed message | The WOPI allow list on Collabora does not include the EGroupware server address, often because the EGroupware host sits behind a proxy or uses a different public address | Add the address EGroupware uses to reach Collabora to the allow list, including any proxy or load balancer address, and retest with a text document |
| Some users edit fine while others cannot join the same document session | In a multi-replica setup, the load balancer does not route by the WOPISrc parameter, so users editing one document land on different pods | Configure the ingress to route by WOPISrc so all users of a document reach the same pod, and confirm replica count is set manually as the Helm chart requires |
| Changes appear to save but do not persist, or saving reports an error | EGroupware rejects the save callback, the WOPI host cannot reach back to Collabora, or file permissions block writes | Check the save path in the EGroupware and Collabora logs, confirm the WOPI host is reachable from Collabora, and verify the file system permissions for the EGroupware storage |
| Certain user groups can view documents but cannot edit or open the editor | EGroupware access rights for those groups do not grant write or editor rights on the file or folder | Review the group's ACL on the affected folders in EGroupware and compare it with a working group, then test with a single user account |
| Editor works for some file types but not others | The file format is outside the supported set, or the document type is not associated with the editor in EGroupware | Test each format (for example docx, xlsx, pptx, odt, ods, odp) in a controlled folder and check the file type mapping in the integration settings |
| Editor fails after a Collabora or EGroupware upgrade | Version mismatch between the EGroupware integration and the Collabora Online branch, or configuration keys changed in the new release | Check the release notes for both products, confirm the integration matches the installed Collabora branch, and roll back in a test environment before changing production |
Questions buyers ask about the Collabora Online and EGroupware integration
What does it cost to add Collabora Online to EGroupware?
The cost is set by the written scope, not by a list price, and DeployOpen does not publish one. The main components are the work to install and connect the Collabora Online server, the EGroupware configuration, the testing against your own file types, and the infrastructure that runs Collabora. The software side has its own cost lines. The CODE edition is free but Collabora describes it as not recommended for production. For production, the Business plan is listed on the Collabora pricing page at 3 euros per user per month for up to 99 users, and that plan includes long term support, a service level agreement, signed security updates and customer portal access. Ask for a quote that separates one-time work from recurring items such as subscriptions, hosting and support retainers.
What factors make the integration project take longer or cost more?
The number of EGroupware instances, the number of Collabora servers, and the amount of testing needed are the largest drivers. A single EGroupware server with one Collabora server and a standard HTTPS setup is the simplest case. Each additional EGroupware instance, each separate network zone, and each additional Collabora server adds configuration and verification work. Sizing for expected concurrent editing is another driver, since Collabora's Helm chart documentation sets production resource figures per pod that depend on load. Testing with your real document library, including older Microsoft Office files and large spreadsheets, often takes more time than the configuration itself. Hosting in restricted or air-gapped networks adds effort for package sources and certificates.
What must our team provide before the integration work starts?
Your team needs to provide administrator access to the EGroupware server and to the host where Collabora will run, or to the cloud account or cluster that hosts it. You also need a DNS name and a valid TLS certificate for the Collabora server, because the Nextcloud documentation recommends HTTPS for the Collabora URL and the same protocol as the file host. Network changes are usually required so EGroupware can reach the Collabora server and so users' browsers can reach it. Ask for firewall rules and reverse proxy decisions in writing. Finally, provide a set of representative test files covering the formats your users work with, and named testers who can confirm the results.
Can an internal administrator set up EGroupware with Collabora Online alone?
An experienced administrator can often do the setup alone if they already run EGroupware and Linux servers, can manage certificates and reverse proxies, and have time for testing. The setup involves the EGroupware side, the Collabora server, the WOPI connection between them, and access restrictions. The points that usually cause problems are certificate trust, protocol mismatches, and blocked network paths, so the admin should have a test environment before touching production. If your team has no spare time for testing or no one who owns the proxy and certificate work, a fixed-scope engagement can cover the build and verification. Confirm the exact EGroupware and Collabora versions with the vendors before planning, since the integration documentation may differ by release.
Do Collabora's paid plans change how the EGroupware setup is done?
The technical setup is the same whichever edition runs the server, but the licensing and support terms change. The Business plan is listed at 3 euros per user per month for up to 99 users and includes long term support, a service level agreement, signed security updates and customer portal access. For 100 or more users, the Enterprise plan is quoted with volume discounts and adds integration support, customization services and roadmap input, according to the pricing page. Ask Collabora which plan fits your user count and whether integration support covers EGroupware specifically. Production use should not rely on CODE, so plan the subscription as part of the total cost of ownership.
Does DeployOpen support the EGroupware and Collabora setup after go-live?
Yes, ongoing support, upgrades and testing are available as retainers, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. After go-live, the work typically includes applying Collabora security updates, checking that the WOPI connection still works after EGroupware or Collabora upgrades, and re-testing file formats. Ask for a written list of what the retainer covers, how change requests are handled, and which parts remain with your own staff, such as user administration and access groups. DeployOpen does not issue audit reports or certifications, so compliance evidence still comes from independent assessors.
How do we control which EGroupware users can edit documents?
Access control has two layers: EGroupware's own permissions decide who can open and create files in the file manager, and the Collabora integration decides who can launch the editor. Review both layers when you plan the rollout. Restrict the Collabora server to the WOPI hosts that should use it, using allow lists where the platform supports them, and confirm the mapping of EGroupware groups to editing rights during testing. Users who can only view a file should not gain edit rights through the editor. Document the rules, then test them with accounts from each group. Confirm the exact configuration keys with the EGroupware and Collabora documentation for your versions.
How DeployOpen scopes, delivers and supports the EGroupware integration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. For the Collabora Online and EGroupware integration, we start from a written scope that sets out how your EGroupware server, file manager and Collabora Online server will connect and who can reach them.
How we scope
- We confirm your EGroupware version, hosting model and the office file types your users create and edit.
- The written scope names the Collabora Online server, its network path to EGroupware and the access rules to be set.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
- We identify which parts of the setup depend on your EGroupware release and must be confirmed with the vendor.
How we build
- We install and configure Collabora Online in your environment, using the deployment method your team has chosen.
- We connect EGroupware's file manager to the Collabora Online server and test create, open and edit actions for each file type.
- We check that the editor URL, HTTPS settings and allowed hosts match the EGroupware address your users actually use.
- We test access control with users, groups and roles that reflect who should view and who should edit documents.
How we hand over
- Handover includes configuration records, network and TLS settings, and the access model written in plain terms.
- We document the test cases used for document creation, editing and permission checks so your team can repeat them.
- Runbooks describe how to update Collabora Online, rotate certificates and review EGroupware settings after changes.
- Your team receives a walkthrough of the setup, with open items and confirmations listed for follow-up.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retained support can cover checking the integration after EGroupware or Collabora Online version changes.
- We can review access rules periodically as teams, roles and document locations change over time.
- Support scope, response expectations and fees are set in writing, and a quote follows from the agreed scope.
