How Zammad customization stays inside the upgrade path
Most Zammad customization is configuration done in the admin interface and the API, and only a small share needs code. For a support team running a self-hosted Zammad that needs new routing, workflow, field or integration changes, the upgrade path is decided by where each change lives. Triggers, macros, overviews, groups and custom object attributes are stored as configuration in the application's database, so they carry through a release as data. Changes to the application's own code, or to files that ship with it, must be re-checked every time you upgrade. Start by sorting your planned changes into those two groups before anyone builds anything.
Keep a written inventory of every change. List each trigger, macro, custom attribute, group rule, scheduled job and external script that touches tickets, with an owner and a short note on what it depends on. External scripts that call the API are the easiest to overlook. They depend on endpoints and payload fields rather than on the application's internals, so treat them as contracts and record which endpoints and fields they use. This inventory tells you what to retest after each minor or security release, and it shows you where a change has quietly moved from configuration into code.
Several situations usually trigger outside help. The first is any change that requires modifying application code, because that work must be re-applied and re-tested with each release. The second is a workflow that spans several groups, roles and escalation paths, where a small change can alter ticket behavior in ways that are hard to see in the admin interface. The third is an integration with a system that has no built-in connector, which typically means building against the API or writing custom development. The fourth is role mapping for agents and customers when the identity provider design is complex. Ask whether a partner can name which of these apply to your scope before the work starts.
In-house work is a reasonable choice when your team already owns admin configuration, can restore a copy of production into a staging environment, and has someone who reads release notes and tests against them before each upgrade. A partner makes more sense when changes reach into application code, when several integrations must be maintained together, or when internal capacity is thin during the months a new workflow goes live. Ask any partner to separate configuration from code in the quote, to state who runs regression tests for each release, and to say what support covers after go-live. Most engagements are fixed-scope, so these answers should appear in the written scope before work begins.
What Zammad customization covers in a fixed-scope engagement
A written scope for Zammad customization usually groups the work into a small number of packages, each tied to a configuration area and a set of deliverables. The packages depend on each other, so the scope should state which ones are in, how they are tested, and how the configuration is handed over before any change reaches production.
Trigger and macro design
Triggers react to ticket events such as creation or updates, while macros apply a set of field changes, notes and assignments when an agent runs them. The scope should list each trigger and macro by name, its conditions and its owner group. Ask for a documented configuration export and test cases showing each path, including edge cases such as reopened tickets and merged tickets.
Custom object attributes
Custom object attributes add fields to tickets, users or organizations that match your process, such as an incident reference or a contract tier. Each attribute needs a type, a screen placement, and a decision on whether it feeds reporting or integrations. Ask for a data dictionary listing every attribute, its purpose and its permissions, plus a change log for later additions.
Ticket workflow changes
Workflow changes cover states, priorities, escalation rules and the routing between groups. These decisions affect service levels and reporting, so they should be designed with the team leads who own each queue. Confirm which states are added or renamed, how existing open tickets are treated, and whether a rollback plan exists. Request a change log and a handover session with agents and supervisors.
API integrations with your systems
Integrations connect Zammad to systems such as directories, CRM records, monitoring tools or billing through its REST API. The scope should name each system, the direction of data flow, the authentication method, and the fields exchanged. Check how failures are logged and retried, and ask for integration test cases, a credentials handling note, and the source code kept in your repository.
Automation scripts
Scheduled or event-driven scripts handle repetitive work such as reminder notices, stale ticket cleanup or data synchronization that triggers cannot express. Each script should have a defined owner, a schedule, a log destination and a way to disable it. Ask for the script source under version control, a test run record on a copy of production data, and a runbook describing how to recover from a partial run.
Upgrade-safe change control
Customizations that touch core files or undocumented behavior tend to break at the next Zammad release. The scope should require that all changes use supported configuration and API paths, and that each one is retested against the minor and security releases your team plans to apply. Ask for a compatibility checklist and a regression test set that can be rerun after each upgrade.
What drives Zammad customization cost and duration
This table lists the factors that move Zammad customization effort, why each one adds work, and how to keep it contained. Read it before requesting a quote, because the same request can cost very different amounts depending on how these drivers are set. The main takeaway is that naming standards, reuse and early decisions about channels and compliance evidence usually matter more than the raw count of rules.
| Driver | Why it adds effort | How to keep it down |
|---|---|---|
| Number of triggers and macros | Each trigger fires on ticket events and can interact with others, so testing grows with every rule added. Overlapping conditions create hard-to-trace ticket behavior. | Consolidate rules with shared conditions, document the purpose of each trigger, and reuse one macro across groups where the steps are the same. |
| Number and type of custom object attributes | Each attribute needs a data type, a screen placement per role, search and reporting consideration, and migration handling. Select, tree and date types need more validation than text fields. | Standardize attribute naming with a prefix convention, reuse existing attributes before creating new ones, and limit the number of attributes that must be required. |
| Groups and roles the logic must respect | Rules that differ by group or role multiply the number of conditions and test cases. Each permission boundary must be verified for agents, admins and customers. | Use group-scoped macros and triggers only where the business differs, and keep role logic in a small set of documented patterns. |
| Number of external systems in the integration | Every connected system adds authentication, field mapping, error handling, rate limit handling and a separate test plan. Failures in one system can leave tickets in inconsistent states. | Confirm the scope of each integration in writing, start with the systems that drive the most tickets, and define which system is the source of truth for each field. |
| Logic across email, chat, forms and phone | Each channel creates tickets with different data and metadata, so logic written for email may not fire the same way for a web form or phone entry. Each channel needs its own test scenarios. | Write channel-agnostic rules based on ticket fields where possible, and confirm the data each channel supplies before designing conditions. |
| Environments (test, staging, production) | Changes must be built, tested and promoted in order. Without a repeatable promotion path, configuration drifts between environments and fixes are repeated by hand. | Keep configuration under version control where practical, promote changes through the same steps each time, and confirm how your team will handle environment-specific values. |
| Compliance evidence requirements | Evidence such as change records, test results, access reviews and configuration history must be captured as the work happens. Retrofitting evidence after go-live is slower and less complete. | Agree the evidence list at scoping, record approvals and test results per change, and confirm with your auditor which artifacts they expect. |
| Upgrade impact on customizations | Customizations built against the application can need review when Zammad minor, security or major releases are applied. Testing scope grows with the number of custom rules and integrations. | Keep customizations to the documented extension points where possible, maintain a regression test list, and confirm upgrade test steps with your team before go-live. |
How a Zammad customization project runs from workshop to handover
This sequence moves a customization from an agreed understanding of today's support process to a documented, tested and deployed change that your team can operate and extend. Each phase closes with a written output, so you can see what you have received before the next phase begins.
Run discovery on the current support process
DeployOpen runs one or more workshops with support leads, agents and the administrators who own Zammad today. The team maps how tickets arrive, how they are assigned and escalated, which groups and roles handle them, and which existing triggers, macros, schedules and custom object attributes already shape that flow. Where access allows, we review the current configuration export and identify triggers that overlap or conflict. The phase closes with a discovery document that lists the current process, the existing configuration, and the open questions you need to answer before design starts.
Design the target workflow and data model
Using the discovery output, DeployOpen drafts the target ticket workflow, including states, priorities, routing rules, escalation paths and any new custom object attributes. We specify which changes belong in triggers, which in macros, which in API-driven automation, and which should not be built at all because they would make future upgrades harder. You review and approve the design in writing, including who signs off on role and permission changes. The client receives a design specification with a change list, the data model for new attributes, and a record of decisions and their reasons.
Build in a non-production instance
DeployOpen builds the approved changes in a non-production Zammad instance that matches your production version and installation method as closely as practical. Configuration is kept in a versioned form where Zammad allows it, and custom code, such as API scripts or integration components, lives in a repository you control. Build decisions that depend on your environment, such as a dependency on Elasticsearch or a reverse proxy rule, are recorded as they are made. The phase is complete when the build matches the approved specification and the client has access to the non-production instance to review it.
Test with realistic ticket scenarios across roles
We write test scenarios from real ticket examples supplied by your team, covering inbound email, web form and any other channels in use. Each scenario is run as an agent, a team lead and a customer, so that visibility, notifications, customer-facing messages and permissions are checked from every side. Failed cases are fixed and retested, and any behavior that differs from the specification is logged with a decision on whether to change the build or the specification. The client receives a test report listing each scenario, its result and any accepted deviations, signed off by a named tester on your side.
Deploy with a tested rollback plan
DeployOpen prepares a deployment runbook for your production instance, covering the order of changes, a backup taken immediately beforehand, the verification steps to run after the change, and the rollback steps with their trigger conditions. Changes are applied in a maintenance window agreed with you. After deployment, we run the verification checklist against production and confirm that the rollback path works in the non-production instance before it is needed. The client receives the runbook, a deployment record showing what changed and when, and confirmation that the rollback steps were checked.
Hand over with documentation and knowledge transfer
The final phase transfers ownership of the customization to your administrators. DeployOpen delivers documentation that describes each trigger, macro, attribute, integration and API script, the reason it exists, and how to change it safely in future. We run a knowledge transfer session with the administrators who will maintain the system and answer their questions on the record. The phase is complete when your team has walked through the documentation, can explain each change, and has accepted the handover in writing. Ongoing upgrades, testing of future customizations and support after go-live are covered separately and should be confirmed in the written scope.
Which Zammad customization work teams keep in-house and what to outsource
This table compares Zammad customization work that most support teams can run themselves with work that usually needs a partner. Read each row for the skills it requires, then decide where your own staff have the time and experience to own the change over several upgrades.
| Work type | Usually kept in-house | Usually outsourced |
|---|---|---|
| Trigger and macro changes | Adjusting trigger conditions, tuning macro text and changing ticket states using the admin interface; requires support process knowledge and admin rights | Designing trigger logic that spans many groups and escalation paths, then testing it against real ticket volumes before go-live |
| Reporting use | Building reports and dashboards from existing fields and Elasticsearch-backed search; requires familiarity with ticket data and the admin reporting tools | Building custom data exports or external reporting pipelines that read from the Zammad API; requires REST API handling and data modeling skills |
| Routine admin changes | Adding agents, adjusting groups, roles and signatures, and managing channels; requires Zammad instance administration and access control basics | Re-architecting roles, group structures and approval paths across several business units; requires support process design and role-based access expertise |
| Workflow design across groups | Small changes within one group, such as adding a state or updating an assignment rule | Multi-group routing, SLA-driven escalation and handoffs between teams; requires support process design and testing discipline |
| API integrations with ERP or CRM | Simple read-only lookups or manual copy of order or account references into ticket notes; requires basic REST API handling | Two-way synchronization with ERP or CRM systems, error handling, retries and credential management; requires REST API handling, integration design and secure secret storage |
| Custom object models | Adding a few custom object attributes to existing objects through the admin interface; requires data modeling and admin skills | New object types, relationships and validation rules that other features depend on; requires Ruby or Rails familiarity and careful schema planning |
| Upgrade-safe code changes | Keeping configuration in the admin interface where possible and documenting every change; requires change control discipline | Modifying application code, patching behavior or extending models in ways that survive minor and major releases; requires Ruby or Rails familiarity and upgrade testing |
| Test automation | Running manual test cases for triggers, macros and routing after each change; requires a written test plan and staging access | Building automated regression suites for API flows, triggers and integrations, run in CI before each upgrade; requires test engineering and REST API handling |
What breaks Zammad customizations and how to prevent it
Most Zammad customizations do not fail on the day they are built. They fail later, when a release arrives, an admin leaves, or an integrated system changes a field name. The cards below cover the failure modes we see most often and the prevention step for each.
Editing application source directly
Changing Zammad's own application code makes every later release a merge exercise, and the changes are easy to lose during an upgrade. Keep customer logic in the admin interface (triggers, macros, custom object attributes) where the platform supports it, and move anything that needs code into a separate service that calls the Zammad API. Before each upgrade, check that no files in the application tree differ from the vendor release.
Logic owned by one admin
Triggers, macros and automations built in one person's settings context have no documented owner, purpose or review date. When that person changes roles, nobody knows which rule routes tickets or sends customer notices. Assign each rule to a named owner, record its purpose in a shared register, and require a second reviewer for changes to rules that affect routing, escalation or customer messages.
Integrations that break on field changes
Scripts and middleware that read custom attribute names, group names or API endpoints fail silently when an admin renames a field or a release changes a response. Document every field and endpoint each integration depends on, and add a scheduled test that calls those endpoints and checks the expected keys. Where possible, reference stable identifiers rather than display labels.
Customizations untested against the next release
A trigger that works on the current version can behave differently after an upgrade, and the first person to notice is usually a customer. Keep a staging instance on the same version as production, run a fixed set of test tickets through each customization, and repeat the run against each candidate release before it reaches production. Record the results so the next upgrade starts from known behavior.
Parallel security releases on two lines
Zammad published security fixes for the 6.5 and 7.x lines in parallel, including 6.5.5 on 15 October 2026 alongside the 7.2 series. A customization reviewed on one line does not automatically hold on the other. Confirm which major line each environment runs, check every customization and integration against the security advisory for that line, and apply the matching release. Keep the affected version recorded in the change log for each environment.
Customizations without version-controlled exports
When rules, macros and object definitions exist only in the live database, there is no clean way to compare them with a previous state or restore them after a bad change. Export configuration on a schedule, store the exports in version control with the change date and author, and review diffs before import into production. Confirm with your Zammad release that the export format you choose can be re-imported.
What Zammad customizations cost to keep working after go-live
The largest recurring cost of a customized Zammad is regression testing. Each minor and security release can change how triggers, macros, custom object attributes and API calls behave, so every customization needs a test case that someone runs before the release reaches production. Zammad 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. Zammad also published security release 6.5.5 on 15 October 2026, so a team running an older line can receive fixes on more than one track in the same month. Budget testing time for every release cycle, and agree in writing who runs the tests and how quickly a security patch must be validated.
API integrations are the second source of recurring work. A script or middleware service that reads tickets, writes articles or syncs users depends on the Zammad API and on the connected system, such as a CRM, identity provider or monitoring tool. When either side changes, someone must review authentication, field mappings, error handling and rate behavior. Confirm which API tokens belong to which integration, who rotates them, and whether a failed sync raises an alert that a person actually sees. Record each integration's endpoints, data flows and downstream systems so an engineer who did not build it can review it later.
Documentation and named owners carry a cost that teams often underestimate. Each trigger, macro and custom object attribute should have a short record of its purpose, the groups and roles it affects, the business owner who approves changes, and the technical owner who edits it. Without that record, a staff change can leave a trigger that nobody can explain, and that trigger then slows every upgrade. Keep the register current as part of the change process, and review it before each minor release so that ownership gaps surface while there is still time to close them.
Your team also needs the skills to adjust triggers and workflows after go-live, or every small change becomes a project. Decide who may edit production triggers and whether changes pass through a staging instance first. On the vendor side, self-hosted Zammad has no license fee. Zammad sells optional self-hosted support subscriptions named Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, with self-hosted response times of 6 hours, 4 hours and 2 hours respectively, according to the Zammad pricing page. Confirm with Zammad whether custom code, such as scripts you wrote or integrations built for you, is covered by any subscription before you plan around that coverage.
How Zammad customization differs by starting point and environment
Teams moving from Zendesk, Freshdesk or OTRS usually bring automations that do not transfer by default. Zammad includes migrators for Freshdesk, Kayako, OTRS and Zendesk that move tickets, users and organizations, but the trigger, macro and workflow logic from the old system typically has to be rebuilt in Zammad's own model. Sources of legacy logic often include SLA rules, saved views and scripts that call the helpdesk API.
- Inventory first: list every automation, view, macro and integration in the source system, with its owner and the outcome it produces.
- Rebuild and compare: recreate triggers and macros in a staging instance, then run sample tickets through both systems and compare the results.
- Map custom fields: decide which source fields become custom object attributes, which are merged and which are retired, and check how migrated history displays.
- Replace integration endpoints: webhooks, email routing and API scripts that depended on the old system need new targets and credentials.
Confirm with Zammad which migrator version and data scope apply to your source system before you estimate rebuild effort.
A self-hosted instance installed with Docker Compose or system packages gives you the most direct control over customization. You manage the host, the reverse proxy, PostgreSQL and Redis, and the configuration that the application reads. The main differences between the two install methods are where files persist, how upgrades are applied and where add-on settings live.
- Persistent storage: confirm which paths hold attachments and uploaded assets so they survive container replacement or package upgrades.
- Cache design: single installations can use the file system cache, while multi-instance layouts such as containers need Memcached.
- Search backend: Elasticsearch is optional but strongly recommended, and it affects attachment search and reporting, so decide early whether those features depend on it.
- Change control: keep exported configuration, scripts and integration code in version control so each upgrade can be tested on a copy first.
Ask Zammad which configuration changes persist through an image update in your Compose setup and which need to be reapplied after a package upgrade.
Zammad documents a Kubernetes Helm chart, but Zammad support covers only the Zammad application. Storage classes, ingress, node scheduling, cluster networking and secrets handling sit with your platform team or another provider. Customization on Kubernetes therefore has to be planned around that support boundary, not around the chart alone.
- Support boundary: write down which failures Zammad handles and which your platform team handles before go-live.
- Multi-instance requirements: replicated pods need shared PostgreSQL, Redis and Memcached, so any customization that writes local files or relies on local state needs review.
- Shared storage: attachments and custom file assets must sit on persistent storage that every pod can reach.
- Values and overrides: keep custom values files and any sidecar or init changes in version control, separate from chart upgrades.
Confirm with Zammad which chart versions and application releases it supports for your cluster design and how it handles chart-level changes.
Zammad's hosted plans are billed per agent per month and run in a data center in Germany. You do not control the server, so customization is limited to what the application exposes through the admin interface and the API. Changes that need host access, custom code deployed to the server or direct database work may not be possible on a hosted plan.
- Available levers: triggers, macros, custom object attributes and API-based automations are the usual options; confirm which of them your plan includes.
- Outbound connectivity: integrations must reach your systems from the hosted environment, so confirm the allowed endpoints, ports and authentication methods.
- Identity options: confirm which third-party login methods the hosted plan supports before you design SSO flows.
- Data location: document where attachments, backups and logs are kept if residency matters to your auditors or regulator.
Ask Zammad in writing which server-side and extension-style changes it permits on your hosted plan before you finalize the design.
In an air-gapped network, Zammad and its dependencies have to be brought in through an approved transfer process, and anything that depends on internet access stops working. Customization that calls external APIs, hosted identity providers or online documentation needs planning before the build starts. Your team also needs a way to keep the documentation it relies on available and matched to the installed version.
- Artifact transfer: plan how application packages, container images and Helm charts are transferred, scanned and approved for the network.
- Integration reachability: map every system each integration calls and confirm it is reachable from inside the network.
- Local documentation: copy the admin and API documentation your team uses into an internal location and record the version it matches.
- Identity dependencies: SAML or OpenID Connect requires an identity provider inside the network, so confirm which login options work without external services.
Confirm with Zammad which release artifacts and documentation versions can be provided for an air-gapped deployment and how to request them.
What you need to provide before a Zammad customization scope is written
Most delays in a Zammad customization project come from missing inputs, not from the build itself. Before a scope is written, the client should be ready to provide a set of items that let the implementation partner see what already exists, who decides, and what has to keep working afterward. Each item below shortens discovery and reduces the rework that appears when assumptions turn out to be wrong.
Admin access to a non-production Zammad instance. Triggers, macros, object attributes and roles can only be reviewed in a running system. A staging instance that mirrors production configuration lets the partner test changes, measure their effect on ticket flow and confirm behavior before anything touches live agents. Ask whether the staging instance is current with production, including the Zammad version and installed packages, and who holds the administrator account.
A current export or written description of triggers, macros and object attributes. Zammad triggers and macros fire on ticket events and change fields, and custom object attributes extend the data model. Without an inventory, discovery has to rediscover what each rule does and which rules overlap. Ask for the export or a plain list showing each item's purpose, the groups and states it touches, and any rule that is known to be fragile or disabled. Note which items were added by hand and which came from a previous partner, since undocumented changes are the most common source of upgrade breakage.
The support process owner and the approvers. Customizations encode a support process, so someone must be able to answer what happens when a ticket is escalated, reassigned or closed without a response. Name one process owner who makes day-to-day decisions and the approvers who sign off on changes that affect SLAs, routing or customer-facing messages. Without this, the scope will contain open questions that stall approval.
Sample tickets from each channel. Email, chat, web forms and phone-logged tickets arrive in different shapes, with different metadata and attachments. Provide a set of anonymized or test tickets from each channel, including a few that were handled badly. These samples show how the current inbound flow behaves and reveal parsing or attribute problems that a description will not capture.
API credentials and test accounts for connected systems. Integrations with CRM, billing, identity or monitoring tools depend on working credentials and realistic test records. Supply API tokens or service accounts scoped for non-production use, plus test accounts for each connected system. Confirm rate limits, network paths and whether the connected system is available during testing. Missing access is one of the most frequent reasons integration work is re-estimated after kickoff.
A named owner for post-go-live changes. Customizations need someone to maintain them after the project ends, including reviewing them before each Zammad minor or security release. Name the person who will own change requests, testing and upgrade impact. Without a named owner, the scope cannot describe ongoing support clearly, and customizations tend to accumulate without tests or documentation.
What do teams ask before hiring help for Zammad customization?
How much does Zammad customization cost, and what drives the price?
Cost depends mainly on how many workflows change, how many systems connect to Zammad, and how much testing the changes need. Self-hosted Zammad has no license fee, so the spend is the implementation work, the infrastructure you run it on, and any support subscription you buy. The Zammad pricing page lists self-hosted support subscriptions at 2,999 EUR per year (Business), 5,999 EUR per year (Enterprise) and 9,999 EUR per year (Corporation). Confirm with Zammad what those subscriptions include for customization questions. The one-time cost is design, build and testing. The recurring cost is retesting after each minor and security release. Ask any provider for a quote that itemizes triggers, macros, object attributes, integrations, test environments and upgrade testing as separate lines.
How long does a Zammad customization project take?
Duration depends on scope. A handful of triggers and macros on an existing instance takes far less time than custom object attributes linked to an external system with approval steps. The main variables are the number of workflows, the number of external systems and the quality of their APIs, how many agent groups must test, and whether a staging environment already matches production. DeployOpen's engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, so the timeline follows from the scope document. Ask for a phased plan with design sign-off, build, testing by named users and cutover. Be cautious of any timeline quoted before someone has reviewed your current configuration and integrations.
Can our own team customize Zammad, and what should stay in-house?
Yes, many teams can build triggers, macros and simple attribute changes with developers who work comfortably with web applications and APIs, plus an admin who understands helpdesk operations. Keep in-house the parts your staff touch every day: trigger logic owned by a named admin, ticket macros, group and role settings, and knowledge base content. Work that is harder to keep in-house includes integrations with other systems, changes that affect core behavior, and anything that needs a test environment matching production. Those tasks need version control, repeatable deployment and regression tests. Before deciding, check whether your team can run upgrade testing on a schedule. Customization that only one person understands becomes a risk at the next release.
What does the work need from our team before it starts?
Expect to provide named business owners, access and decisions. Useful inputs include a written description of current ticket flows for each channel (email, chat, forms and phone), your group and role structure, a list of external systems with their API details, and a staging environment that resembles production. You need an admin account or an agreed access path, a full backup taken before any change, and someone who signs off on test cases. Agents who handle live tickets should take part in testing because they know the edge cases. Escalation rules, SLA targets and data handling decisions must come from your side. Delays usually trace back to open decisions, so name a decision owner and a deadline in the scope.
Do custom triggers, macros and attributes survive Zammad upgrades?
Often yes, but only if they were built with upgrades in mind. Configuration made in the admin interface is stored in the application database, so it is usually carried through an upgrade. The usual failure points are changes to application code, modified templates and edited core files. Each release can change behavior that a trigger relies on, so test custom workflows in staging after every minor and security release. Keep a record for each customization covering its purpose, owner, dependencies and test cases. Avoid editing Zammad source in place. Before scheduling an upgrade, read the release notes for your target version and confirm the upgrade path and any known breaking changes.
How does the AGPL license affect custom code we write for Zammad?
Zammad is licensed under the GNU Affero General Public License version 3, which adds obligations beyond ordinary open-source licenses when you modify the software and users interact with it over a network. If you change Zammad's own code and users reach that modified version through a network, the license can require you to offer the corresponding source to those users. Configuration through triggers, macros and attributes is generally handled differently from editing source code. Separate programs that talk to Zammad through its API may be treated differently again, depending on how they are built and linked. This is a legal question, not a technical one. Ask your counsel to review the architecture and planned changes before the build starts, and keep modifications in version control so you can disclose them.
Should we customize Zammad through configuration or custom code?
Start with configuration. Triggers, macros, custom object attributes, groups, roles and overviews cover many workflow needs without changing application code, which keeps upgrade testing narrower. Move to custom code only when a requirement cannot be met through configuration, such as a complex integration with an internal system, a specialized channel or a reporting need. Custom code adds maintenance: it needs version control, tests, deployment steps and a named owner, and it can break at upgrade. For integrations, a separate service that calls the Zammad API often limits the impact of change on the helpdesk itself. Document the reason for each code change so a future team can judge whether it is still needed after the next major version.
Does a Zammad support subscription cover our customizations?
Confirm this in writing with Zammad before you buy. The Zammad pricing page lists self-hosted support response times of 6 hours for Business, 4 hours for Enterprise and 2 hours for Corporation. Those figures describe response times for Zammad's support, and they do not establish whether a specific custom trigger, integration or script is in scope. Separately, DeployOpen plans, implements, customizes, hardens, upgrades and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with written deliverables. Ask both providers which party owns each custom component, who answers for failures after an upgrade, and how urgent issues are routed.
How DeployOpen scopes, delivers and hands over Zammad customization
DeployOpen approaches Zammad customization as a fixed-scope piece of work inside your own infrastructure, with each trigger, macro, attribute, workflow and integration agreed in writing before build starts. The work is designed to be tested against new Zammad releases so customizations do not slow down future upgrades.
How we scope
- Inventory the triggers, macros, custom object attributes and workflows your agents need, and record which ones replace manual steps today.
- Agree in writing which external systems, APIs and identity sources the customizations will touch, and who owns each one.
- Confirm the Zammad version and deployment method in use, since package, Docker Compose and Helm installs differ in how changes are applied.
How we build
- Prefer configuration through the admin interface and documented API calls before writing custom code, keeping changes easy to review and reverse.
- Test each trigger, macro and workflow on a staging instance cloned from production data, with agent roles and groups tested separately.
- Pin integration scripts to documented API endpoints and record every change in version control so the build can be reproduced after an upgrade.
How we hand over
- Deliver a written register of every customization, its purpose, its owner and the Zammad version it was tested against.
- Provide test cases and a repeatable checklist your team can run after each minor or security release before changes reach production.
- Walk your administrators through the admin procedures for changing triggers, macros and attributes, and record the knowledge transfer in the handover pack.
How we support
- Ongoing support, upgrades and regression testing of customizations are available as a retainer after go-live.
- Retest customizations against each Zammad minor and security release you adopt, and report any changes that need adjustment before rollout.
- Ask for the support boundary in your quote: which failures are covered by DeployOpen, which by Zammad's own support subscriptions, and which by your team.
