When shared inboxes in OX App Suite for Teams fit a support or sales team
OX App Suite for Teams can be a candidate for a support or sales team that works from one shared address, but whether it fits depends on confirming its shared-mailbox feature set before you commit. The decision turns on one question: does your team need to know who owns each conversation and where it stands, or is a shared address with simple routing enough? A team that loses track of who has replied, or that passes the same thread between personal folders, usually has an ownership problem before it has a tooling problem. Answering that question shows whether a mail-based shared inbox can carry the work or whether a separate helpdesk tool is the better fit.
The core use case is a shared mailbox that several people read, answer and hand over without losing the thread. Consider an illustrative sales team with one inquiries address and four representatives. A prospect asks for pricing, one representative starts a reply, a colleague answers the same message an hour later, and nobody can tell whether the prospect has been contacted. The features that address this are assignment of a message to one owner, a status that shows open, waiting or closed, internal comments that stay out of outgoing mail, and drafts that more than one person can see or edit before sending. Ask Open-Xchange or your integrator to confirm each of these in the release you plan to run, and to state whether they apply to mail only or to the other modules as well.
The people who should read this page depend on who owns the decision. The CIO or head of IT needs to know whether the mail platform in scope can absorb a support workload. The support or sales manager needs to know how routing, reporting and handover will work day to day. Security and identity engineers need to check how access to a shared mailbox is granted and removed. Before you commit, run a short pilot on a copy of one live queue. Test what happens when a team member leaves, whether access follows groups from your directory, and whether sent items show which person replied. OX App Suite supports single sign-on through OpenID Connect, and SAML login is documented for the middleware, so confirm which method your identity setup will use and whether group membership can drive mailbox access.
Shared inboxes usually stop short of a full helpdesk. If your service needs service-level timers, a customer portal, web forms that create records, phone or chat queues, or reporting on resolution time, confirm each of these in writing. If any one is a hard requirement, plan for a separate helpdesk such as the open-source Zammad, and keep the shared mailbox for messages that do not need that workflow. Confirm licensing as well. The Operations Guide notes that certain modules or features may be packaged separately or carry separate fees set in the license agreement, so ask whether shared-mailbox functions are included in your agreement before you plan the rollout.
The platform beneath the mailboxes matters for a team that will depend on them. OX App Suite v8 runs on Kubernetes and is delivered as Helm charts, which require Helm 3.17.0 or newer. It uses MariaDB as its primary data store and Redis 7.4.x for caching and session storage. Persistent data such as PIM attachments must sit on a distributed file system, and shared queues can grow quickly, so choose the storage tier early. Confirm the release channel too. According to the support commitment, v8.47 is the current LTS release, and a standard release is supported for 12 weeks, ending when the third following release becomes available. A team on standard releases needs an upgrade plan that keeps pace with that cadence.
Shared inbox in App Suite or a separate helpdesk tool
This table compares three ways to run a shared support or sales inbox: keeping everything in App Suite for Teams, pairing App Suite mail with a dedicated helpdesk such as Zammad, or splitting routing and reporting into a helpdesk while mail stays in App Suite. Read each row against your team size and reporting needs. The main takeaway is that a second system adds routing and reporting depth, but it also adds a second platform your team must run.
| Factor | App Suite shared mailboxes only | App Suite mail with Zammad | Hybrid: helpdesk routing, mail in App Suite |
|---|---|---|---|
| Typical team size | Small groups where a few people share one or two addresses (illustrative) | Teams with several agents, multiple queues and a need for formal case handling | Larger teams where routing rules and queue ownership need a dedicated owner |
| Reporting needs | Assignment and status visibility inside the mailbox; confirm which reports the Teams features expose | Queue, agent and response reporting in the helpdesk; confirm the report set in the version you deploy | Reporting built in the helpdesk from mail events; confirm which mail metadata reaches it |
| Integration effort | Lowest, because there is no second application, identity source or data store to connect | Mail routing into Zammad, plus SSO and backups for a second system; confirm the mail connection method | Highest, because both systems must agree on mailbox identity, threading and status; design this first |
| Licensing to confirm | Confirm which shared mailbox and team features your license covers, since some modules may be packaged or priced separately | Confirm Zammad's license terms and the App Suite license scope that covers the mail flows it uses | Confirm both license sets and whether the integration needs any module outside your current agreement |
| Who runs the platform | Your platform team runs the App Suite cluster, Redis, MariaDB and file storage | Your platform team runs App Suite plus a helpdesk, with its own upgrades, backups and access model | Two operating owners; agree in writing which team owns the integration and its failures |
| Main risk | Team features may fall short as queues, service expectations and reporting needs grow | Two platforms to upgrade and back up, and more places where mail and ticket state can drift | Status mismatch between helpdesk and mailbox if the sync design is incomplete |
How to set up shared mailboxes on a v8 deployment
This sequence takes a v8 deployment from licensing checks to a tested shared mailbox pilot for support or sales teams. Each step closes with a check you can run before moving on, so configuration problems surface while the platform is still easy to change.
Confirm the license and modules
The platform owner and procurement confirm, in the license agreement, which modules and features the team is entitled to use. Open-Xchange's Operations Guide notes that certain modules or features may carry custom packaging, limitations or separate fees, so shared mailbox and team capabilities should be checked by name rather than assumed from the core product. Ask the vendor to confirm in writing which entitlements apply to your user population and contract. This step is done when a written list of entitled modules is on file with both the platform owner and procurement.
Confirm the v8 release and Kubernetes target
Choose the v8 release your team will run, using the Open-Xchange support commitment as the reference. The commitment lists v8.47 as the current LTS and v8.53 as the newest listed release, and standard releases have a short support window, so confirm which track fits your change schedule. Check that your cluster version falls within the Kubernetes versions v8 supports (N-1 and N-2), and confirm ingress: v8 requires Istio, with a basic ingress-nginx option where Istio cannot be used. This step is done when the platform team signs off a version and cluster matrix.
Deploy the platform with Helm 3.17.0 or newer
The platform engineer installs Helm 3.17.0 or newer and deploys the v8 Helm charts into a dedicated namespace. The charts reference container images, so the images must be reachable from your cluster through your registry or mirror. Set values for hostnames, ingress and the database, cache and storage endpoints configured in the next step. This step is done when the Helm release reports a deployed status and every pod reaches the Ready state.
Configure MariaDB, Redis and file storage
Connect the platform to MariaDB with the InnoDB storage engine, using a supported version line: 10.6.x, 10.11.x, 11.4.x or 11.8.x. Galera Cluster is supported if you need a clustered database. Configure Redis 7.4.x for caching and session storage, either through the littlered operator that is the default or through a custom or unmanaged setup. Attachments and PIM files must sit on a distributed file system: NFS suits small to mid-size deployments, while object storage such as AWS S3, Ceph RadosGW or Scality RING suits larger ones. This step is done when a test attachment uploads, reads back after a pod restart, and the middleware reports healthy database and cache connections.
Create shared mailboxes and team membership
The platform owner creates one shared mailbox for each support or sales queue and creates team groups that match how work is divided. Add members to each team and record who owns each mailbox. The exact administration steps depend on your v8 release, so confirm them against the documentation for that version before the first mailbox is created. This step is done when each mailbox lists only the intended team members and an administrator can explain who has access to each queue.
Configure single sign-on
The identity team connects v8 to your identity provider. OX App Suite supports OpenID Connect for single sign-on, and Open-Xchange documents SAML login configuration for the middleware if your provider requires SAML. Map identity provider groups to the team groups created in the previous step so that membership follows the directory rather than manual edits. This step is done when a test user from each team signs in through SSO and sees only the mailboxes for that team, a user outside the teams sees none, and signing out ends the session.
Test assignment, status, comments and draft co-editing with a pilot
Invite a small pilot group drawn from each team and run a scripted test. Assign an incoming message to a team member, change its status, add an internal comment, and have two pilot users co-edit a reply draft at the same time. Record each action, the expected result and the observed result in a shared test log, and repeat any failed action after the fix. The pilot is complete when every scripted action passes for every team, and the platform owner accepts the log as the basis for opening the queues to all users.
How to control access, audit and data protection for shared mailboxes
Shared mailboxes concentrate customer conversations, attachments and internal discussion in one place, so access control has to cover who joins, what they can change, and what happens when they leave. The cards below cover membership and roles, identity sign-in and offboarding, attachment retention, backup scope, and visibility of internal comments. Work through them together before go-live, because a gap in one area usually shows up as exposure in another.
Mailbox membership and least-privilege roles
Decide who belongs to each shared inbox and what each member may do, such as reading, replying, assigning, changing status or editing co-authored drafts. Keep membership tied to a team or function rather than to individuals where possible, and review it on a fixed schedule. Confirm with Open-Xchange which permissions are available per shared folder in App Suite for Teams and whether they can be scoped more narrowly than your role design requires.
SSO with OpenID Connect and SAML
OX App Suite supports single sign-on through OpenID Connect, and Open-Xchange documents SAML login configuration for the middleware. Choose one protocol for the user-facing login path and confirm which one your identity provider and your App Suite version support for the middleware layer. Test sign-in, session expiry and group or claim mapping in a non-production environment before any shared inbox is opened to staff.
Removing access when staff leave
Access to shared mailboxes should follow the identity record, so disabling the account in your directory should end sign-in and membership together. Confirm how App Suite handles existing sessions, cached tokens and assignments already made to the departing user, and who reassigns open conversations. Include a check that contractors and service accounts with shared-inbox rights are covered by the same offboarding process.
Retention and deletion of attachments
Attachments on shared inboxes are stored in the file layer, and deleting a message does not automatically define how long copies remain. Agree a retention period per mailbox, decide whether deleted attachments are purged or kept for a recovery window, and document who approves exceptions for legal hold. Verify the deletion behavior of your chosen file backend, whether NFS or object storage, because the purge process differs between them.
Backup scope for database and file store
A restore of the mail data needs two consistent sets: the MariaDB database that holds mailbox metadata, comments and assignments, and the distributed file store that holds attachments and Drive content. Restoring one without the other can leave messages that point to missing files or files with no owning record. Define backup frequency, retention, and restore tests for both, and confirm with your storage vendor how snapshots of the file layer align with database backups.
Visibility of internal comments
Internal comments on a conversation are visible to people with access to that shared inbox, which makes membership decisions also decisions about who reads internal discussion. Decide which roles may write, read or delete comments, and whether comments are included in exports or audit records. Test visibility with a user from each role before go-live, and confirm with Open-Xchange how comments are handled when a member is removed from a shared folder.
Limits to confirm in your environment before committing
These checks decide whether OX App Suite for Teams can replace a separate helpdesk tool for your shared inboxes. Each item depends on licensing, release policy, reporting behavior or mail configuration that a feature demo does not show, so settle them in writing with Open-Xchange and in your own environment before you commit.
Assignment, status and comment licensing
The Operations Guide states that some modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Ask Open-Xchange in writing whether assignment, status and comments are included in your license or charged separately, and whether any usage limit applies. Confirm the answer in the quote before you design the workflow around these features.
Supported release and support window
A standard release is supported for 12 weeks, ending with the availability of the third following release. An LTS release is supported until the next LTS release plus six months. v8.47 is the current LTS, v8.35 is discontinued, and v8.53 is the newest release listed, with first customer shipment on 2026-09-23. Confirm which release you will deploy and its end-of-support date, then plan upgrade windows for shared inbox workflows around it.
Reporting and ticket volume limits
Managers usually query shared inbox history for volume, response and workload. Ask Open-Xchange which reporting views exist for assignment and status, how long history is retained, and whether any cap applies to conversations, comments or messages per shared address. Test with a sample of your expected mail load in a non-production environment before you commit to a reporting plan.
Mail routing rules for shared addresses
Shared addresses such as support or sales need predictable delivery to the right team inbox. Check aliases, distribution to several members, and handling of messages that match no routing rule. Confirm with your mail administrator how routing rules, inbound connectors and outbound sending identities behave in your domain and DNS setup, and test with representative sample messages, including bounces and forwarded threads.
Service-level tracking requirements
Confirm whether the helpdesk features cover the service-level measures your team reports, such as first response time, resolution time and breach alerts. Shared inboxes without clock-based tracking often need a separate reporting layer. List the exact measures and escalation rules you need, then ask Open-Xchange to demonstrate each one in your target configuration before accepting a general feature list.
Questions teams ask before hiring help with shared inboxes
What drives the cost of a shared inbox rollout on OX App Suite?
The main cost drivers are the license scope, the number of shared mailboxes and teams, the identity integration, storage, the migration from any existing helpdesk, and the testing needed before users depend on the system. Licensing matters most. The Open-Xchange Operations Guide states that some modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement, so confirm exactly which features your shared inbox workflow uses. Some costs are one-time, such as design, build, migration and cutover. Others recur, such as the license, infrastructure, backups and upgrades. Ask any partner for a written quote that lists each component, who pays for it (your license holder, your cloud provider or the implementation partner), and which items are fixed scope and which are estimates.
How long does an OX App Suite rollout for shared mailboxes take?
Duration depends on scope: how many teams and mailboxes are involved, whether you run a single sign-on integration, how much historical mail and helpdesk data must move, and how many environments you need before production. A pilot with a small group of users is usually planned before a wider rollout, so ask for milestones in the written scope rather than a single end date. Infrastructure readiness is often the longest dependency. The platform needs a Kubernetes cluster that meets the supported version range, Helm 3.17.0 or newer, and either Istio or the basic ingress-nginx option. If any of these are not yet in place, the schedule should show them as prerequisites with owners and dates.
What does the client need to provide for a shared inbox project?
The client provides several decisions and access items that the work cannot start without. First, confirm the license scope with Open-Xchange, including any licensed modules you plan to use. Second, provide identity access: OX App Suite supports single sign-on through OpenID Connect, and SAML login is documented for the middleware, so decide which protocol your identity provider will use and who manages the client registration. Third, make storage decisions. Persistent data such as Drive files and PIM attachments must sit on a distributed file system, either NFS for small to mid-size deployments or object storage for larger ones. Fourth, name pilot users and the shared mailboxes they will test first, along with the owners who will sign off on the workflow.
Can an internal team set up OX App Suite for shared inboxes alone?
An internal team can do this alone if it already runs Kubernetes in production and has people comfortable with Helm charts, Istio or ingress controllers, the Redis and MariaDB versions listed in the requirements, and a distributed file system. The supported MariaDB versions are 10.6.x, 10.11.x, 11.4.x and 11.8.x, and Redis 7.4.x is used by default through the littlered operator. The harder parts are usually migration from an existing helpdesk, the identity integration, and the test plan, because these cross teams and systems. Many organizations keep operations in-house and buy a fixed-scope build or migration. Decide this by listing the skills you already have, the skills you would need to hire, and the time your team can commit during cutover.
Which OX App Suite release should a shared inbox deployment target?
For shared inboxes that teams depend on daily, most organizations prefer a release with a longer support window. Open-Xchange documents that a standard release is supported for 12 weeks, ending with the availability of the third following release. An LTS release is supported until the next LTS release plus six months. The current LTS listed in the support commitment is v8.47 (first customer shipment 2026-03-18), and v8.35 is now discontinued. Confirm the current LTS and the upgrade path with Open-Xchange before you fix the target version. Your plan should also say how often you will upgrade, who tests each release in a non-production environment, and how the upgrade will be scheduled around business hours.
How should shared inbox workflows be tested before go-live?
Test the workflows people actually use, not only whether the platform starts. A practical plan covers mail flow into each shared mailbox, assignment to a person or team, status changes, internal comments, co-edited drafts, and the hand-off from your previous helpdesk for open items. Include failure cases such as a mailbox that receives a large attachment, a user who loses access mid-task, and an identity provider outage. Run the pilot with named users and record defects with owners and severity. Confirm in the written scope which tests are included in the fixed price and which are charged separately, and ask who signs off on acceptance.
What should we confirm about the license before scoping shared inbox work?
Confirm the license terms first, because they determine which features you can use and what you pay for them. Open-Xchange's documentation states that certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Ask the vendor to list, in writing, which modules your shared inbox design needs, including any that are licensed and priced separately, and whether the license covers your planned number of users, mailboxes and environments. Also ask how license changes are handled during the project and whether the license covers non-production environments used for testing. A partner can scope the implementation only after these answers are in writing.
How DeployOpen scopes and delivers a shared inbox rollout
DeployOpen plans OX App Suite for Teams shared inboxes as a written, fixed-scope engagement inside your own infrastructure. We agree which mailboxes, teams, assignment and status workflows are in scope before any build starts, then deliver, document and hand over the result for your operators.
How we scope
- Inventory the shared mailboxes, owning teams and the assignment and status rules each one needs
- Confirm the Kubernetes, Istio or ingress, Redis, MariaDB and file storage targets in your environment
- Agree the written scope, deliverables and timeline with your team before work starts
How we build
- Deploy OX App Suite v8 from Helm charts with the Helm version your environment requires
- Configure shared inbox access, identity integration and co-edited draft settings for each team
- Test assignment, status, comments and drafts with representative users before go-live
How we hand over
- Document mailbox ownership, team roles, assignment rules and the configuration behind them
- Provide runbooks for routine administration, user onboarding and troubleshooting shared inboxes
- Walk your operators through the handover and confirm they can run the environment independently
How we support
- Offer ongoing support, upgrades and testing as a retainer after handover
- Plan upgrades against the Open-Xchange support commitment and its release timelines
- Confirm licensing for any modules or features with Open-Xchange before adding them to the rollout
How comments and co-edited drafts affect data handling
Internal comments and shared drafts create records outside the sent mail, so retention, search and export rules must cover them from the start. A customer message that the team never sends can still contain account details, personal data and internal reasoning about how a case was handled. Before go-live, list every object the shared inbox produces: the received message, the internal comment thread, each draft and its saved revisions, the attachments, and any Documents files opened from the conversation. For each one, confirm which retention policy applies, who can search it, and whether a compliance export includes it. Ask Open-Xchange to document where each object is stored in the target release, because that answer determines which backup and retention jobs must reach it.
Co-editing of office files relies on Documents, the OX App Suite module for editing office files, and that dependency changes the data picture. The edited file, its revisions and its sharing settings sit in the same file layer as Drive files and PIM attachments, which must run on a distributed file system such as NFS for smaller deployments or object storage for larger ones. Retention, backup coverage and capacity planning for that layer therefore apply to the shared inbox as well as to the mail store. Also confirm the licensing position for Documents in your agreement with Open-Xchange, since the Operations Guide states that certain modules may be subject to custom packaging or separate fees set in the license agreement. Get that answer in writing before you design the team's workflow around it.
The integration between mail drafts and Documents is a point to confirm before you rely on it. Co-editing shared office files is a documented capability of the suite, but whether a mail draft can be opened, edited and handed between team members with the same co-editing behavior depends on the target release. Treat this as an open question until Open-Xchange confirms it in writing for your version. Then test it using your actual workflow: two agents editing one draft, a reassignment in the middle of a thread, a send from the shared address, and a follow-up reply to the customer. Record what each step writes, where it appears in search, and whether an export captures the draft revisions and comments. Repeat the test after every release upgrade, because the behavior may change between versions.
Use the test results to make three decisions before rollout. First, set the retention period and deletion behavior for comments and drafts separately from sent mail, and document who approves exceptions. Second, decide which roles may search and export shared-inbox records, and confirm that the export procedure produces the same objects you tested. Third, write a runbook entry for the case where a draft or comment must be removed under a legal or privacy request, including how backups and file revisions are handled. Legal, privacy and compliance leads should sign off on these rules. DeployOpen can prepare the configuration, test evidence and runbooks, while an independent auditor decides whether the controls meet a given assessment.