How a Nextcloud and Zammad integration puts tickets where support teams already work
A Nextcloud and Zammad integration lets support staff see Zammad tickets inside Nextcloud through a dashboard widget, search tickets from Nextcloud, and receive notifications when new tickets arrive. Before any build starts, the team must confirm which method delivers those three functions, because the research behind this page does not establish a specific Nextcloud app or Zammad connector that provides them. Teams that already spend their working day in Nextcloud gain the most, since they can check queues without switching tools. Make the method decision during scoping, so the written scope names the components, their versions and who maintains them.
Zammad is licensed under the GNU Affero General Public License version 3, and it can be self-hosted in infrastructure the organization controls. Nextcloud Server is also licensed under AGPL-3.0, so both products sit under the same license family. Self-hosting both keeps the ticket path inside the organization's own environment instead of routing it through a third-party hosted service. Ask legal to confirm that AGPL obligations fit the organization's policy, especially if the build includes custom code that modifies either product rather than calling it through its interfaces.
Nextcloud and Zammad each keep their own users, groups, permissions and data stores. A Nextcloud account and a Zammad agent are separate records, so the integration must map one to the other and carry that mapping as a maintained artifact. Decide how an agent is matched to a Nextcloud user, by email address, by a stable directory identifier or by a mapping table the team owns. If both systems authenticate against the same directory, matching on that identifier is usually the most stable option. Then test who can see which ticket in each system, because a widget that shows a ticket to a user Zammad would restrict creates an exposure that neither product reports on its own.
Before scoping closes, confirm several points with the method's maintainer and in your own environment. Check whether the chosen Nextcloud app or Zammad connector supports each of the three functions, which Nextcloud major versions and which Zammad lines it supports, and what license it carries. Zammad published security fixes on both its 6.5 and 7.x lines, so the version pinned in the plan must sit on a line that still receives patches. Confirm also how the integration authenticates to the Zammad API, whether its token can be scoped to read only the tickets it needs and rotated without an outage. Nextcloud major releases are supported for one year and must be applied one major version at a time, so the integration's supported range should be checked against that schedule.
What you need in place before connecting Zammad to Nextcloud
The Zammad dashboard widget, ticket search and new-ticket notifications only work when both systems are current, reachable and trusted by each other. Check the versions, accounts, network paths and ownership below before any app is installed, so the integration is not blocked by a missing piece halfway through the build.
Nextcloud server version and stack
Confirm the Nextcloud major version you run against the Nextcloud 35 system requirements, which list PHP 8.5 with 8.3 and 8.4 also supported, and MariaDB 11.8 or PostgreSQL 18 as the recommended databases. Nextcloud 35 was released on 16 September 2026 and reaches end of life in September 2027, so decide early whether the integration targets that release or an older supported line. Also confirm the web server is Apache 2.4 or nginx with php-fpm.
Zammad release line and dependencies
Record which Zammad line you run, for example 6.5 or 7.2, and confirm you apply the security releases for that line. Zammad 7.2 was released on 23 September 2026, with 7.2.1 and 7.2.2 following in October 2026, and security release 6.5.5 was published for the 6.5 line. Zammad requires PostgreSQL 15 or newer and Redis 7 or newer, and supports Nginx or Apache as its reverse proxy, so check those components before you rely on it.
Dedicated Zammad service account
Create a Zammad user that exists only for the integration, with a role limited to the groups and ticket views the Nextcloud users need. Do not reuse a personal agent login, because ticket actions and audit entries would then be attributed to one person. Ask your Zammad administrator to confirm which permissions the chosen widget and search features require, and document the account owner and password rotation process.
Network paths between the two systems
Map which direction each request travels: Nextcloud calling the Zammad API, and browsers reaching Zammad for ticket links. Confirm that firewall rules, proxies and DNS names allow both paths from the subnets where users and the Nextcloud server sit. Check whether Zammad realtime websocket traffic passes through the same proxy, since a proxy that blocks it will not stop the integration but will degrade live updates.
TLS certificates trusted on both sides
Each system must trust the certificate the other presents. Confirm that the Zammad hostname is covered by a certificate issued by an authority that the Nextcloud server trusts, including any internal certificate authority, and that the chain is complete. Test the connection from the Nextcloud server itself, not from a workstation, because a workstation may already trust a root that the server does not.
Named owners for each system
Assign one accountable owner for Nextcloud, one for Zammad, and one for the connection between them. The connection owner handles the service account, API permissions, certificate renewal and change approval for upgrades on either side. Record who approves a Zammad or Nextcloud upgrade that could change the API behavior the integration depends on, so that a release in one system does not break the other without anyone noticing.
Which integration method the Zammad side supports and what to confirm
The first decision is which of three methods your team will build on. The options are a Nextcloud app from the app store, a custom Nextcloud app built on the Nextcloud app framework, or a small service that sits outside Nextcloud and calls the Zammad API. On the Zammad side, the documentation we reviewed confirms two things: a documented API that is used for data migration, and third-party login through SAML and OpenID Connect. It does not describe a Nextcloud dashboard widget or a ticket connector, so whether those features exist depends on the specific app or code you choose. Treat the Zammad API as the integration surface and confirm everything else in writing before the build starts.
For an existing app from the app store, the questions concern the maintainer and the version matrix. Ask who maintains the app, what license it uses, and which Nextcloud and Zammad versions it has been tested against. Then ask how it authenticates to Zammad: whether it uses a personal API token, a service account or an OAuth flow, and where that credential is stored. Request the list of Zammad API endpoints it calls for the dashboard, ticket search and new-ticket notifications, and confirm whether ticket content is cached in the Nextcloud database. Ask what a support agent sees when the app encounters a ticket in a Zammad group that the agent cannot access directly in Zammad.
A small service that calls the Zammad API moves the integration out of the Nextcloud process. It needs its own hosting, service account, secret management, logging and upgrade tracking, and it should read only what its account is permitted to read. The key confirmations are the Zammad role and group permissions assigned to that service account, the API endpoints and rate limits in your Zammad version, and how new-ticket notifications reach Nextcloud, whether by polling, a webhook or another mechanism. Ask the builder to demonstrate that ticket visibility follows Zammad groups, because Nextcloud group membership does not determine who may see a ticket.
A custom Nextcloud app changes who owns the integration over time. Your team, or the partner who builds it, becomes responsible for code that must keep working through each Nextcloud major release. Nextcloud publishes a new major version every four months and supports each for one year. Administrators must upgrade one major version at a time and disable third-party apps until they are confirmed compatible. Each upgrade therefore includes a regression test of the custom app against the new Nextcloud release and the Zammad version in use. Zammad also publishes security releases on more than one line, so the API client needs the same tracking. Plan for ongoing maintenance as a recurring cost alongside the initial build.
Before you choose, collect written answers to the same list for each candidate: maintainer, supported Nextcloud and Zammad versions, authentication method, API endpoints, data stored outside Zammad, permission model and upgrade path. Compare those answers against your own Nextcloud upgrade calendar and Zammad release cadence. Your security team should also review where credentials sit and which logs record ticket access. If an app cannot answer these questions in writing, treat that as a finding in itself. The quote should name the chosen method, the app or code version it delivers, and who maintains it after handover.
Configuration sequence for connecting Zammad tickets to Nextcloud
The sequence starts with access decisions on the Zammad side, moves through a staging build and user mapping, and ends with live notifications. Each step closes with a check you can repeat, so the widget, search and notifications reach only the people your Zammad groups allow.
Confirm the Zammad API access model
Before anything is configured, confirm with your Zammad administrator how the integration will authenticate, either with an API token or an OAuth client, and which API operations the chosen method needs for the widget, search and notifications. Create a dedicated integration account in Zammad with the minimum agent or group rights those operations require, and do not reuse a personal agent account. Confirm that the account can read tickets in the groups you intend to expose and cannot see groups outside that scope. Done means you have a written list of permitted groups and a test API call that returns only tickets from those groups.
Configure groups, roles and the client credential
In Zammad, set up the groups and roles the integration account and support agents will use. Then create the token or OAuth client the chosen method requires, and store its secret in your secrets manager rather than in a configuration file on the Nextcloud host. Confirm that the permissions attached to the credential match the list from the previous step. Done means a request made with the new credential returns tickets from the permitted groups and is refused for any group outside that list.
Install the Nextcloud component in staging
Install the Nextcloud integration component in a staging instance that matches production for Nextcloud version, PHP version and database. Before installing, confirm in the component's documentation which Nextcloud versions it supports. Keep third-party apps disabled until they are confirmed compatible with your current release, and do not install the component in production yet. Done means the component is enabled in staging, its settings page loads without errors in the Nextcloud log, and it appears in the admin list of installed apps.
Set the Zammad endpoint and TLS trust
Enter the Zammad base address in the staging component settings, using the HTTPS address that users reach through the reverse proxy, and add the integration credential from the second step. Make the Nextcloud server trust Zammad's certificate by adding your internal certificate authority to the trust store PHP uses, or by pointing the component at a CA bundle if it supports one. Leave certificate verification on. Done means a test connection succeeds from the Nextcloud host and the Nextcloud log shows no certificate errors.
Map Zammad groups to Nextcloud users
Decide how Zammad agents correspond to Nextcloud accounts. Most organizations match on a shared identifier such as an email address or directory account, and some use group membership to limit which queues each person sees. If your sign-in comes from Keycloak or LDAP, the mapping may originate there, so confirm this with your identity design. Map a small set of named test agents first and record which Nextcloud user sees which Zammad groups. Done means each test user sees only the queues their Zammad groups allow, and a user outside the mapping sees none.
Enable the dashboard widget and search
In staging, enable the dashboard widget and ticket search for the test users. Create a test ticket in a permitted Zammad group and confirm it appears in the widget within the refresh behavior the component documents. Search for the ticket by its number and by a word in its title, and check that the results match what Zammad returns for the same query. Confirm which search path the component uses, including whether it relies on Zammad's Elasticsearch index when that is configured, because the answer determines what you test. Done means the widget shows the test ticket, the search returns it, and a ticket from a non-permitted group is absent from both.
Enable new-ticket notifications last
Turn on new-ticket notifications only after the widget and search checks pass, and start with a single test group. Create a new ticket in that group in Zammad and confirm the notification reaches the Nextcloud test user who should receive it and no one outside the group. Review the notification content for any ticket data you did not intend to expose beyond the group. Extend notifications to other groups only after this check, then repeat the same staged steps in production. Done means the test notification arrives once, to the correct user only.
How Nextcloud users, groups and Zammad agents map to ticket access
This table lists each identity, group, role and ticket field that controls what a Nextcloud user can see in Zammad, along with the system that holds each value and the owner who approves changes. Read it before the build starts, because a mismatch between directory groups and Zammad groups can expose tickets to the wrong people. The exact attribute names depend on the matching method you choose and must be confirmed against your Zammad and Nextcloud versions before you rely on them.
| Element | What it decides | Source of truth | Change approved by |
|---|---|---|---|
| Nextcloud user ID to Zammad agent account | Which Nextcloud user maps to which Zammad agent, so the widget loads only that agent's tickets | Nextcloud user backend (LDAP, OIDC or SAML) and the Zammad user record | Identity team with the Zammad administrator |
| Nextcloud group to Zammad group | Which tickets an agent sees, based on the Zammad groups assigned to the matched account | Directory group membership for Nextcloud, Zammad group settings for ticket scope | Support operations lead, with the directory owner for group changes |
| Zammad role to widget actions | Whether the widget can only view tickets or also change state, priority or owner | Zammad role and permission definitions, confirmed for your Zammad version | Zammad administrator, approved by the support lead and security owner |
| Ticket fields shown in the widget | Which values appear: state, priority, owner, group and last update, visible to every user the widget serves | Zammad ticket object and the widget configuration | Support lead, with security review of any added field |
| New-ticket notification trigger | Which groups or ticket conditions send a Nextcloud notification when a new ticket arrives | Zammad trigger definitions and the Nextcloud notification settings | Support lead, with the Zammad administrator |
| Attribute names and matching method | Which directory attribute, token claim or API identity links a Nextcloud user to a Zammad agent; names must be confirmed | The design record produced when the matching method is chosen | Project lead, with identity and security owners before build |
| Unmatched or deactivated accounts | Users with no matching Zammad agent see no tickets and receive no notifications | Directory account state and Zammad account active status | Identity owner, with HR and IT for the leavers process |
Security settings that limit ticket exposure through Nextcloud
Nextcloud shows Zammad data to people who may never open Zammad directly, so the integration widens the audience for every ticket. These six settings decide who can read what, how the connection is protected and how you prove it works. Confirm each one against your Zammad and Nextcloud versions before go-live.
Least-privilege Zammad group for the integration
Create a dedicated Zammad user for the integration and keep personal agent logins out of it. Assign that user only to the groups whose tickets the Nextcloud widget and search should expose. Confirm in your Zammad version which roles and group permissions the account needs for ticket reads and new-ticket creation, and nothing beyond them. Review its group memberships at each access review, because a later change to those groups changes what Nextcloud users can see.
Token storage and rotation
The integration authenticates to Zammad with a credential that Nextcloud holds in its configuration. Restrict the file permissions on that configuration to the web server user, and keep the credential out of shared notes, tickets and version control. Confirm in the Zammad admin settings how API tokens are created, scoped and revoked in your version. Then set a rotation schedule and a runbook that replaces the credential on both sides in one planned change.
TLS between Nextcloud and Zammad
Nextcloud calls Zammad over HTTPS, and Zammad serves its web and websocket traffic through a reverse proxy such as Nginx or Apache. Serve Zammad on TLS with a certificate that the Nextcloud server trusts, and confirm that certificate verification is enabled in the app. Internal certificate authorities need their root certificate added to the Nextcloud server trust store. Test with the exact hostname the app uses, because a mismatch is a common cause of failed calls.
Search limited to the user's groups
Search results and widget entries should follow Zammad's own access rules, so a Nextcloud user sees only the tickets their matched Zammad identity can read. Test with accounts from each group and confirm that search returns the expected tickets and nothing more, including tickets in restricted groups. Ask the integration provider to document how users are matched between the two systems. Matching on email address alone needs review where people share addresses or aliases.
Logging of integration calls on both sides
Record integration calls in the Nextcloud server log and in the Zammad application and audit logs, so one ticket read or creation can be traced across both systems. Confirm which events each side records, which identifiers appear in each entry and how long each log is kept. Forward both to your central log store, and limit personal data in those entries to what your policy allows. Check the logs during the first weeks of use, not only after an incident.
Third-party login for Zammad agents
Zammad supports third-party login through SAML and OpenID Connect, among other providers. Signing agents in through your identity provider lets you disable a leaver or enforce multi-factor authentication in one place, and it applies to Zammad sign-in as well as the integration. Decide whether a local break-glass login stays available and who controls it. Confirm how group and role mapping from the identity provider behaves in your Zammad version before go-live.
How to test ticket visibility before support staff depend on it
Ticket visibility is the control most likely to fail without anyone noticing, so test it on staging data before any support agent depends on the dashboard widget or search. The plan covers five checks. A user outside the relevant group must not see a ticket. A user inside the group must see it. Search must return only the tickets that user is permitted to see. A new ticket must trigger exactly one notification per recipient. An agent whose access is revoked must lose access on the next request, not at the next login. Write the expected result for each check before running it, so a failure cannot be explained away afterward.
Build the staging data so each check has a clear answer. Create at least two Zammad groups, populate each with tickets, and create Nextcloud accounts that map to them through the identity source your integration uses. Include one account that belongs to no agent group. Confirm with the integration documentation how group membership reaches each side, because a mismatch between Nextcloud groups and Zammad roles is a common cause of tickets appearing where they should not. For search, use terms that appear in both permitted and restricted tickets, then compare the results with the counts you expect from the Zammad side. For notifications, create one ticket and count what each recipient receives in Nextcloud and by email. Then post an update and confirm it does not generate a duplicate notification unless your design intends one.
Revocation needs the most attention because sessions, tokens and cached results can keep working after a group change. Remove a test agent from its Zammad group, then use the dashboard widget and search immediately and confirm both return no access. Repeat the test with an agent whose browser session is already open. Zammad requires Redis 7 or newer for realtime websocket communication, and Memcached is needed when Zammad runs as several instances, such as containers or cluster nodes. In a multi-instance setup, run the revocation test through each instance, because a stale cache on one node is the kind of fault a single-node test misses. Ask the integration team to state how long any Nextcloud-side cache or token remains valid.
Repeat the full set of five checks after every change, not only after the first build. Zammad publishes security releases on more than one line at the same time. Version 7.2 was released on 23 September 2026, followed by security releases 7.2.1 on 6 October 2026 and 7.2.2 on 8 October 2026, while security release 6.5.5 shipped on 15 October 2026. Confirm which line your deployment runs and rerun the checks after each security release on that line. For Nextcloud, upgrade one major version at a time, take a backup before every upgrade, and keep third-party apps disabled until their compatibility is confirmed. If the Zammad connector is a third-party app, leave it disabled until it is confirmed to work with the target version, then run the five checks again before agents return to it.
Load testing should use the sizing agreed for the Zammad deployment, including agent count, ticket volume, and expected peak search and notification rates. Run concurrent searches at that level plus a margin the team agrees on, and send a burst of new tickets to confirm each notification is delivered once without queuing delays agents would notice. Record response times and failures, and check that permission filtering holds under load. A timeout must never fall back to unfiltered results. Elasticsearch is optional for Zammad but strongly recommended, since it provides faster search, reporting and searching of email attachment content. Run the search checks on the configuration you will operate. If you deploy Elasticsearch, repeat the permission tests against its index, because indexed results must follow the same access rules as database search.
Common failures in Zammad and Nextcloud ticket integrations and how to fix them
This table lists six failures seen in Zammad and Nextcloud ticket integrations, with the likely cause, the system to check first and the fix. Work down the rows in order, since the first check is usually the cheapest way to rule out a cause. The main takeaway is that most failures trace back to credentials, search indexing, trust or group membership, so confirm those before changing application settings.
| Failure | Likely cause | Check first | Fix |
|---|---|---|---|
| Widget empty or errors after a Zammad upgrade | The upgrade changed API access or the token was revoked or regenerated | The Zammad API token and the integration account, then the Nextcloud log in data/nextcloud.log | Confirm the token is valid in Zammad, update it in the Nextcloud integration, and read the release notes for the version you moved to before retesting |
| Search returns no results | The Elasticsearch index is empty, stale or unreachable, or the searching user lacks permission for those tickets | Elasticsearch connection and index status in Zammad settings, then the Zammad production log | Restore the Elasticsearch connection, rebuild the index following the Zammad documentation, and test with a user whose ticket access you already know |
| Notifications missing or duplicated | Triggers or background jobs fire in both systems, or the Redis-backed job flow is delayed or misconfigured | Zammad trigger list and background job status, then the Nextcloud notification settings | Keep one notification source for each event, disable the duplicate trigger, and confirm Zammad can reach Redis 7 or newer |
| Certificate errors between Nextcloud and Zammad | The PHP process on the Nextcloud host does not trust the CA that issued the Zammad certificate, often an internal CA | The TLS messages in data/nextcloud.log and the certificate bundle path used by PHP | Add the internal CA to the trust store used by PHP and the web server, restart the services, and test the chain from the Nextcloud host with openssl |
| Users see tickets they should not | Group mapping drifted after Zammad group or role changes, or the widget uses a shared token whose owner has broad access | The owner of the integration token in Zammad, and group assignments on both sides | Map groups explicitly, move to per-user access where your setup supports it, review mappings after every group change, and test with a restricted account |
| Slow widget loads | A multi-instance Zammad deployment has no Memcached, or Redis 7 is missing for realtime traffic | Cache settings in each Zammad node, the Redis version, and the number of running Zammad instances | Add Memcached for multi-instance deployments, confirm Redis 7 or newer is in use, and check reverse proxy timeouts between Nextcloud and Zammad |
Questions support leaders ask before connecting Zammad to Nextcloud
How much does it cost to connect Zammad to Nextcloud?
No single figure covers this integration, because the total depends on several separate costs. Self-hosted Zammad has no license fee, but Zammad sells self-hosted support subscriptions separately: Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, according to Zammad's pricing page. If your Nextcloud is Enterprise, Nextcloud's pricing page lists Standard from 71.29 EUR per user per year for 100 or more users, with a 100-user minimum. Other costs are the infrastructure both platforms run on, which you pay your cloud or data center provider, and the integration work, which DeployOpen quotes from a written scope. Ask any partner to split the quote into one-time build and test work and recurring items such as maintenance and upgrades.
What drives the effort of a Zammad and Nextcloud integration?
The main drivers are the integration method, whether the component is an existing app store item or custom work, the number of groups, the permission model and the volume of notifications. The confirmed integration method decides how much of the work is configuration and how much is development, so confirm it with the app vendor or your own testing before you scope. A custom component adds design, build, review and maintenance work that an existing app does not need. More Nextcloud groups mean more mapping between Zammad teams and Nextcloud access, and a detailed permission model means more test cases. High notification volume raises the cost of tuning and of checking that alerts reach the right people without flooding them. A written scope should state which of these factors apply to your environment.
How long does the Zammad and Nextcloud integration take?
The duration depends on the drivers above, plus the state of both platforms before work starts. A team that already runs current versions of both products and has a test group ready will move faster than one that must first upgrade. Nextcloud does not allow skipping major releases, so if your server is several majors behind, each step adds upgrade and testing time. Nextcloud 35 was released on 16 September 2026, and Zammad 7.2 was released on 23 September 2026, so confirm which versions your environment runs and whether a security release is due. Ask for a timeline in the written scope that lists the phases, the review points, and the dates on which your team must provide access, accounts and sign-off.
What does our team need to provide for the integration?
Four roles matter most. A Zammad administrator owns the ticketing side, including groups, roles, the API access the integration uses and the notification settings. A Nextcloud administrator owns the dashboard placement, app installation, server configuration and upgrade schedule. A security reviewer checks which ticket data appears in Nextcloud, how credentials are stored and who can see what. A test group of support agents and at least one manager uses the search, widget and notifications before go live and reports where the behavior does not match their work. Name these people before the scope is signed, because most delays come from waiting for access, approvals or testers rather than from the technical build itself.
Can our own team connect Zammad to Nextcloud without a partner?
Yes, if your team has the skills and time for the work, and many teams do the integration in house. The test is whether you have a Zammad administrator, a Nextcloud administrator, a security reviewer and a test group who can commit time to the project. You also need a way to back up both systems before change and to roll back if a step fails. Nextcloud's upgrade guidance requires a backup before every upgrade, one major version at a time, and disabling third-party apps until they are confirmed compatible, so any integration app must be checked on each upgrade. If one of these roles is missing, or the integration needs custom development, a partner can cover the gap under a fixed scope. Compare the internal and external options against the same written scope.
Does self-hosted Zammad have a license fee?
No. Zammad is licensed under the GNU Affero General Public License version 3, and self-hosted Zammad has no license fee. What you may pay for is a support subscription, which Zammad sells separately: Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, according to its pricing page. A subscription is a support decision, not a requirement to run the software. Decide whether your team can handle upgrades, patches and troubleshooting alone, and whether you need vendor response commitments. Those answers determine whether a subscription fits your budget. Check the current prices on the pricing page before you approve a budget, because the figures here come from the researched facts for this page.
Which Zammad requirements affect the design of the integration?
Zammad stores its content in PostgreSQL 15 or newer and requires Redis 7 or newer for realtime websocket communication. Nginx or Apache serves as the reverse proxy. Elasticsearch is optional but strongly recommended, because Zammad uses it for faster search, reporting and searching the content of email attachments. Ticket search from Nextcloud depends on this choice, so confirm with your Zammad administrator whether Elasticsearch is in place and sized for the expected load. Memcached is needed for multi-instance deployments such as containers or cluster nodes, while a single installation can use the file system cache. Check these requirements against your deployment method, whether package, Docker Compose or Kubernetes, before the build starts, because each method changes how the services are run and supported.
What should a security reviewer check before go live?
Start with what data leaves Zammad. The reviewer should confirm which ticket fields, customer names and message excerpts appear in the Nextcloud dashboard, search results and notifications, and whether each user sees only the tickets their Zammad role allows. Next, check how the integration authenticates to Zammad, where the credential or token is stored, who can read it and how it is rotated. Confirm that notification content is limited to what the recipient needs. Review the Nextcloud side too, since its upgrade guidance requires disabling third-party apps until they are confirmed compatible, which affects the integration. Keep the evidence from each check in writing. DeployOpen can prepare systems and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification.
How DeployOpen scopes, builds and supports the Zammad and Nextcloud integration
DeployOpen plans and builds the Zammad and Nextcloud integration inside infrastructure you control, so support staff can work tickets from where they already spend their day. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- The written scope names which Zammad and Nextcloud features are in, such as the dashboard widget, ticket search and new-ticket notifications.
- We confirm the Zammad and Nextcloud versions in use and whether each is on a supported release line before design starts.
- We record which Zammad groups, roles and Nextcloud users receive ticket access, and how that access is limited.
How we build
- We set up the Zammad API access and token handling in a test environment before connecting any production Nextcloud instance.
- We test the dashboard widget, ticket search and new-ticket notifications against sample tickets and realistic permission scenarios.
- We check how notifications behave for multiple Zammad instances or clustered deployments, and confirm the caching setup needed for them.
How we hand over
- We document the configuration, API credentials, permission model and the steps to roll back the integration if needed.
- We walk administrators through how to update the Zammad and Nextcloud apps and what to retest after each upgrade.
- We provide a test checklist that your team can rerun after upgrades, backups or changes to either platform.
How we support
- Ongoing support for the integration is available as a retainer, covering updates and fixes agreed in advance.
- Retainers can include checks after Zammad security releases and Nextcloud maintenance releases, scoped in writing.
- Support scope, response expectations and included hours are set out in the retainer agreement before work begins.
