How Zammad LDAP and Active Directory user sync works
Zammad can pull agents and customers from Active Directory or another LDAP directory through its directory integration, so the main work is mapping, scoping and testing, not building custom user creation. The supported method is the directory connection in Zammad's administration area. Confirm the exact settings, the sync behavior and how each release handles them against the Zammad admin documentation for your target version before you plan the build. Treat any screen layout or field name you read elsewhere as provisional until you have checked it in your own instance, because connector details can change between releases.
Start with scoping, because it decides how many accounts the sync touches. Identify the organizational units or containers that hold agents and the ones that hold customers, and decide whether disabled accounts, service accounts and shared mailboxes should be excluded. Ask your directory team for a read-only service account with a clear owner and password rotation process. Then agree which directory attributes supply the login, email address, full name and phone number, and confirm how nested groups are read in your directory. Write these decisions down, since they become the test cases for the rollout.
Group mapping is where most access risk sits. Decide which directory groups should grant agent access and which should grant customer access, and assign Zammad roles and groups only where a documented business need exists. A user who belongs to several mapped groups may receive combined permissions, so test those cases with dedicated test accounts in a staging instance. For example, an illustrative case might be an account in both a support tier group and an administrator group, and you should confirm how Zammad resolves that conflict in the version you run. Review administrator mappings separately and keep them to the smallest set of people.
Plan for the limits before you promise a timeline. Confirm with the Zammad admin documentation whether the sync runs one way from the directory into Zammad, whether it deletes or deactivates users removed from the directory, and whether several directories can be connected at once. Also confirm whether organization assignment can be driven from directory data, since that mapping may need manual work or a separate process. Each open question changes the testing plan and the effort, so resolve them in the scoping stage and record the answers in the written scope.
What you need before connecting Zammad to a directory
Connecting Zammad to a directory depends on three groups of prerequisites: the Zammad hosts and their data services, network and trust access to the directory, and decisions the directory owner makes about identities and groups. Settle each one before configuring sync, because the mapping can only be tested against accounts and paths that already exist. Confirm directory-side items with the directory team before you assume any default.
Supported self-hosted Zammad release
Plan the sync on a self-hosted Zammad instance running a release line that is still supported, and record the exact version in your change plan. Zammad has published security fixes for more than one release line at the same time, so check the release notes for the line you run and for any line you may move to. If your instance is behind on security fixes, close that gap first, because directory credentials will sit in the same application. Confirm the upgrade path with your Zammad administrators before sync testing begins.
PostgreSQL 15 and Redis 7
Zammad stores its content in PostgreSQL 15 or newer and requires Redis 7 or newer for live websocket communication. Confirm both versions against the software requirements for the Zammad release you plan to run, and check them before the directory integration adds load. Sync jobs create and update user records in PostgreSQL, so a database that is already short on capacity or backup coverage is a weak starting point. Ask your platform team who owns these instances and how they are backed up.
Read-only bind account
Zammad needs a bind account to query the directory during sync. Request a dedicated service account that can read user and group objects under the search base and nothing more, and do not reuse a personal or administrator account. Ask the directory team which read permissions the account needs, which attributes it can see, and whether its password follows a renewal or rotation policy. Do not assume that a default account has these rights. Store the credential in your secrets process and keep it out of shared runbooks.
Network path to the directory
Zammad application hosts must reach the domain controllers or LDAP servers on the ports your directory uses. Map the path from each Zammad host, including any firewall, load balancer or segmented network between the application tier and the directory tier. Test with the exact host name the directory team plans to publish, since a connection by IP address may succeed while the name check fails later. Ask which domain controllers or LDAP servers should be used, and whether the sync should target one server or a DNS name that resolves to several.
TLS certificates Zammad hosts trust
Confirm with the directory team whether LDAPS, meaning LDAP over TLS, is required for the bind and the sync, and whether plain LDAP is permitted at all. Then make sure every Zammad application host trusts the certificate chain the directory presents, including any internal certificate authority. Check that certificate names match the host names you will configure, and plan renewal, because an expired certificate will stop the sync without any change in Zammad. Do not assume either answer from a general rule.
Directory owner's identity inputs
Get three inputs from the directory owner before configuring anything. First, the base DN or search base that holds agent and customer identities, so the sync does not read the whole tree. Second, the user and group object classes that hold those identities, which can differ between Active Directory and other LDAP servers. Third, an agreed list of groups that should map to Zammad roles, with one named owner who approves changes to that list. Record all three in the change plan so the first test run can be checked against them.
What one-way sync means for agents and customers
The directory is the source of truth for identity attributes, group membership and account state. Identity attributes include fields such as login name, email address, first and last name, phone number and department, as mapped in your configuration. Group membership decides which directory groups a person belongs to, and account state records whether the person is active or disabled in the directory. Once a field is mapped from the directory, the directory value is the one that counts. Before go-live, list every mapped attribute and name the team that owns the correction process for each one.
Several things stay managed inside Zammad. Ticket data, including articles, attachments, tags, priorities and time entries, is created and changed by agents and customers in the helpdesk. Local preferences such as notification settings, signatures and language choices remain with the Zammad account. Roles assigned directly in Zammad also stay there. Group-to-role mapping is the one place where directory data controls a role, so agents should understand that a role changed in the directory will follow the next sync. Confirm which of these items your team plans to manage inside Zammad and document the list.
One-way sync has a direct consequence for administrators and agents. Any change made in Zammad to a synced field is overwritten on the next run. For example, an illustrative case: an agent corrects a customer's phone number in the Zammad admin interface, and the old number returns after the next scheduled sync because the directory still holds it. Agents need a clear rule that corrections to synced fields are made in the directory, and administrators need a way to tell which fields are synced. Plan the training and the support instructions around this rule, not after the first complaint.
Removing a user or group in the directory also affects the Zammad account on the next sync, but the exact result depends on the configured behavior for updates, deactivation and deletion. Ask whether a removed account is deactivated or deleted, what happens to tickets owned by that agent, and whether customer records remain linked to their tickets. Ask the same questions for a group that is removed or renamed, because role mapping depends on it. These answers differ by release and configuration, so confirm them with a test directory before you promise them to a client.
Run a test before the production sync is enabled. Create a test directory with a changed attribute, a removed user, a disabled user and a removed group. Run the sync, then record what Zammad did to each account and to the tickets linked to them. Repeat the test on the Zammad release you will run in production, because behavior can change between releases. Store the results in the runbook and agree the wording you will give the client, so the operating model reflects what the system does rather than what the documentation summary suggests.
How to configure the sync in the right order
This sequence moves the sync from a test directory to full production scope in small, checkable stages. Each step ends with a comparison between the directory and Zammad, so mismatches surface while they are still easy to fix. The result is a connection that imports only the users and groups you intend, with attributes and roles you have verified.
Confirm the directory and bind account in a test tenant
Before touching production, the directory team and the Zammad admin confirm the server address, the encryption method, the base DN for users and groups, and a read-only bind account. Test in a non-production Zammad instance or test tenant so a wrong credential or base DN cannot lock out agents or create stray accounts. Ask the directory team to confirm that the bind account can read every attribute you plan to map, including the group membership attribute your directory uses. Done when a test connection succeeds and a manual search returns the expected test users and groups.
Add the directory connection with a limited search base
In the directory integration settings of Zammad, create the connection using the bind account and a search base narrowed to one organizational unit that holds a small, known set of test users. Keep the filter strict so the import cannot pull in service accounts, disabled accounts or unrelated groups. The exact fields and menu path depend on your release, so confirm them in the Zammad admin documentation before you save. Done when the connection saves without error and the test query lists only the accounts inside that unit.
Run a dry or small-scope import
Run an import limited to the test search base, using a dry run if your release offers one. Record how many users and groups the run reports, then compare that count with the same query run directly against the directory. Confirm whether the import creates new accounts, updates existing ones or both, because this determines what can change in your live helpdesk later. Done when the counts match the directory query and you have a list of created and updated accounts ready for review.
Verify attributes on sample users
Pick a sample that covers agents, customers, a user with a missing email address and a user in a nested group. For each one, compare name, email, login, phone and the directory identifier in Zammad against the directory entry. Check that agents and customers landed in the correct account type and that no duplicate identities appeared for people who already had a Zammad account. Done when every sampled user matches the directory on the mapped fields and every mismatch has a recorded cause and fix.
Map directory groups to Zammad roles
Map each directory group that should grant agent access to the matching Zammad role and group assignments, and leave everyone else as a customer or unassigned. Keep the mapping list short, written down and tied to a named owner for each directory group. Confirm in the admin documentation how your release evaluates nested groups and users who belong to several groups, then test one user in two mapped groups. Done when a sample of agents shows the expected roles and group access, and a user in an unmapped group gets no elevated access.
Widen the search base to full scope
Expand the search base in stages, first to the parent organizational unit that holds the intended population, then to the full set of units agreed with the directory owners. After each expansion, rerun the comparisons from the earlier steps: user count, group count, and a sample of attributes and roles. Watch for accounts that now appear outside the intended population, such as service accounts or contractors who were not agreed to be included. Done when the full-scope comparison shows only the expected accounts and the directory owners have signed off on the population.
Schedule recurring sync and confirm the first run
Set the recurring sync interval in the same integration settings, and document who owns the schedule and who is alerted when a run fails. Let the first scheduled run complete, then repeat the sample comparison to confirm nothing changed unexpectedly. Because the sync flows from the directory into Zammad, changes made directly to synced accounts in Zammad may be overwritten, so plan deprovisioning in the directory as its own process. Done when two consecutive scheduled runs produce the expected counts and the sample check passes.
Mapping directory groups and attributes to Zammad roles
This table compares directory attributes and groups with the Zammad field or role each one would feed, and names who owns the source value. Read each row as a question to settle before configuration: who owns the value, whether it stays stable, and how Zammad will use it. The main takeaway is that role assignment should follow a written role model, and the customer and agent split needs a rule of its own.
| Directory source | Zammad field or role | Who owns the source value |
|---|---|---|
| Login name (sAMAccountName or uid) | Unique login name for the Zammad user record | Directory administrators. Confirm the value is unique and stable across every synced directory. |
| Mail address (mail or userPrincipalName) | Email address on the user record, used for ticket matching and notifications | Identity team. Confirm which attribute is authoritative when mail and userPrincipalName differ. |
| Display name (displayName or cn) | First and last name fields on the user record | HR or directory administrators. Confirm whether name changes flow in on each sync run. |
| Department or job title | No fixed mapping is assumed here. Confirm the target field, tag or whether the value stays unmapped. | HR system of record, passed to the directory. Confirm the attribute is maintained at source. |
| Group membership (memberOf) | Input for role assignment, used only after the group-to-role table is approved | Directory team owns membership. Support lead owns which groups grant access. |
| Group-to-role mapping | Each Zammad role, the groups that grant it and the approver for changes, set out in a written role model | Support operations lead signs off the role model. Directory team implements the group links. |
| Customers versus agents | Needs its own rule: which group or attribute marks an agent, which marks a customer, and how users in neither group are handled | Support lead and directory owner, decided jointly. Confirm sync behavior for users who match both or neither. |
| Directory organizations (OU or company attribute) | Confirm how directory organizations are represented in Zammad for the target release before mapping. Do not assume an organization mapping exists. | Platform owner, checked against the Zammad documentation for the release in use. |
Handling more than one directory without duplicate customers
The most important decision in a multi-directory setup is the unique identifier and the precedence rule, and both must be settled before the first import. If agents sit in one Active Directory forest and customers sit in another LDAP directory or a separate AD domain, the same person can exist in both with different login names or mail addresses. Without an agreed match rule, that person can appear as two Zammad users, and their tickets, ownership and notifications split across the two records. Illustrative example: an employee who is "jsmith" in one domain and "john.smith" in another would look like two people unless the sync matches on a shared attribute. Confirm in the Zammad admin documentation how the application matches an incoming record to an existing user before you write any mapping.
Login names are a poor identifier in this setup because they are local to each directory. Look for an attribute that is unique and stable across both sources, such as an employee number, a governed corporate mail address or a customer account ID that your CRM also holds. Check the data before you commit: count how many accounts share a mail address, identify shared or role mailboxes, and find contractors who may hold accounts in more than one place. Then write a precedence rule that answers one question for each person: which source is authoritative for their role. A common pattern is that the agent directory controls agent records and the customer directory controls customer records, but your own policy should decide this. Record the rule in your change log so that later changes are reviewed against it.
If FreeIPA is the customer directory and Active Directory holds the agents, a cross-forest trust is one way to let identities resolve across the two. FreeIPA's trust documentation states that the IPA domain must use a DNS domain that does not overlap with any domain in the AD forest. Overlapping names are hard to fix after deployment, so check your DNS namespace before you install FreeIPA. Also confirm whether a trust is needed at all for the sync design. Zammad can often read each directory with its own bind account over LDAP, which would avoid a trust entirely. The answer depends on how Zammad connects to each source in your version and on your network and authentication policy, so verify it with the Zammad documentation and your directory team.
Test the rule on a copy of the data before a production import. Run the sync against a test group that includes people who exist in both directories, then check that each person resolves to one Zammad user and that the authoritative source wins on name, mail address and group membership. Confirm what happens when an account is disabled in one directory but still active in the other, since that can leave a customer able to log in or an agent without access. Keep the results with the mapping document, and ask any implementation partner to show the duplicate check, the precedence test and the rollback steps as written deliverables before go-live.
Hardening the directory connection and the accounts it creates
A directory sync gives Zammad a standing trust relationship with your identity store, so the connection and the roles it can grant need the same scrutiny as any other privileged integration. The controls below cover how the bind account is scoped, how the connection is encrypted and where its secrets live, which directory groups can become Zammad roles, and how sync results and role changes are reviewed afterward. Confirm every setting against the Zammad admin documentation and your directory team's policy before you change production.
Scope the bind account to the search base
The bind account should hold only the read rights needed to query the users and groups inside the search base that Zammad imports from. Ask the directory team to create a dedicated service account that is not a personal account, has no write permissions, and cannot read sensitive attributes outside the fields the sync maps. Confirm the exact attributes Zammad requests with the admin documentation and the directory team's policy, then test the account against a narrow search filter before using it for a full sync.
Encrypt the directory connection
Connect to the directory over LDAPS or StartTLS, and enable certificate validation so Zammad checks that the server certificate chains to a trusted authority and matches the host name. Plain LDAP sends the bind credentials and directory data without protection and should not be used for a production connection. Ask your directory team which certificate authority issues the domain controller certificates and whether Zammad's host trusts that chain.
Keep the bind password out of tickets and scripts
Store the bind password only in the secrets handling that Zammad's admin settings and your deployment method provide, and confirm how that storage is encrypted and who can read it. Do not paste the password into support tickets, chat threads, sync scripts, shell history or configuration files committed to version control. Plan a rotation step for the bind account and check that the rotation procedure updates the stored secret in every Zammad environment, including staging.
Restrict which groups grant roles
Group-to-role mapping decides who becomes an agent or an administrator, so limit it to a short, named list of directory groups owned by people who approve Zammad access. Remove broad groups such as all employees or all contractors from role mappings, and confirm with the directory team who can add members to each mapped group. Review the mapping whenever a group changes ownership or a new Zammad role is introduced.
Treat directory compromise as Zammad access
If an attacker controls a directory account that belongs to a mapped group, the next sync can give that identity an agent or administrator role in Zammad. A broad mapping therefore extends the blast radius of a directory breach into the helpdesk, where customer data and internal notes are stored. Document this dependency in your threat model, and confirm with the security team how quickly a disabled directory account is reflected in Zammad after the next sync run.
Review deactivated and orphaned accounts
After each sync, review accounts that were deactivated because their directory entry disappeared and accounts that no longer map to any directory object. Check that deactivated agents no longer hold open assignments or administrator rights, and decide with the service desk owner how orphaned customer records are retained or removed. Confirm the deactivation behavior in the admin documentation, since it determines what this review must look for.
Log sync runs and role changes
Keep records of each sync run, including its start and end time, the bind account used, the number of accounts created, changed or deactivated, and any errors. Also keep a record of every change to a role assignment, so that an unexpected administrator grant can be traced to the directory group that caused it. Confirm where Zammad writes these entries, how long they are retained, and whether they reach your central log platform.
Common sync failures and how to fix them
This table lists the sync failures most often seen when Zammad reads users and groups from Active Directory or another LDAP directory, with the likely cause and a check that confirms each fix. Read each row as a diagnostic path: test the directory side from a Zammad host first, then check the Zammad side. Most failures trace to bind credentials, certificate trust, search scope or identifier choices, so test these before go-live.
| Failure | Likely cause | Fix to verify |
|---|---|---|
| Bind failures | Wrong bind DN or password, a locked or expired service account, or a search base the account cannot read. | Run an LDAP search from a Zammad host with the same bind DN and password. Confirm the account can read the search base and is enabled and unexpired in the directory. |
| Certificate errors on LDAPS | The internal CA is missing from the trust store on Zammad hosts or container images, or the certificate name does not match the configured host. | Add the CA chain to the OS trust store on every Zammad node. Run openssl s_client against the directory host and port and confirm the chain verifies and the certificate name matches the configured host. |
| Users missing after sync | The search base is too narrow, or the user filter or object class (such as user or person in AD) excludes the accounts. | Run the configured filter with ldapsearch and compare the result count with the expected users. Adjust the base and filter until a named test user appears, then run a sync and confirm the user in Zammad. |
| Group membership not applied | Zammad reads only direct membership, so users in nested groups never receive the mapped role. | Identify which membership attribute Zammad reads. Test a user who sits only in a nested group, confirm the directory returns that membership, then run a sync and check the resulting role. Ask your directory team which membership lookup your directory supports. |
| Duplicate accounts | Mail addresses differ in case, use aliases, or change between directory and Zammad, so one person matches two identifiers. | Choose one unique attribute as the identifier and normalize its case. Export possible duplicates before enabling sync, merge them in Zammad, then confirm one account per person after a test sync. |
| Disabled accounts still active | The integration does not deactivate accounts disabled in the directory, or the filter drops disabled users before Zammad sees them. | Disable a test account in the directory, run a sync and attempt a sign-in in Zammad. Confirm access is blocked. If the sync does not deactivate accounts, document a manual leaver process with a named owner. |
| Role changes lost after one-way overwrite | Each sync overwrites local role edits made in Zammad, so manual changes revert to the directory state. | Decide which system owns roles and document it. Change a group in the directory, run a sync and confirm the new role. Make a local role edit on a test user and confirm whether the next sync reverts it. |
Working around the absence of organization mapping
Plan for customer grouping before the sync is built, because the directory's organizational units or departments may not map directly to Zammad organizations in the release you deploy. If they do not, the sync will create and update users without placing them into the company records your team uses for reporting, SLAs and shared views. Treat this as a design decision with a named owner, not a detail to settle during testing. Confirm the current behavior of organization assignment from directory attributes in the Zammad admin documentation for the exact release in scope, and record the answer in the written scope.
Three approaches are worth evaluating. The first keeps the organization in a custom field on the user object, populated from a directory attribute such as a department or company value, so the sync carries the grouping as data and reports can filter on it. This works well when the directory is the source of truth, but it requires agreement on which attribute holds the value, how blank or inconsistent values are handled, and whether the field is read-only for agents. The second assigns the organization manually for a small, stable set of customers, which is practical when the customer count is low and changes rarely. The third limits the LDAP or Active Directory sync to agents and manages customers through another route, such as email-created users or an import of a maintained list.
Each option has a recurring cost. A custom field depends on attribute hygiene in the directory, so someone must own that data and review it after reorganizations. Manual assignment adds administrative work every time a customer is added or moves, and it needs a documented procedure so the process survives staff changes. Limiting the sync shifts customer lifecycle work to another system and can split the audit trail for who had access when. Ask the implementation partner to show how each option behaves for users who change departments, leave the company, or belong to more than one group, and to price the ongoing upkeep of the chosen approach as part of the quote.
Before build, make the decision explicit in the written scope. Name the approach, the directory attributes or lists involved, the Zammad release it was checked against, the person responsible for maintaining the source data, and the test cases that prove the grouping works, including a sample of customers from each directory branch. If the approach depends on a Zammad capability that the admin documentation describes only in general terms, record that as an open item to verify on a test instance rather than assuming it works. A clear statement at this stage prevents rework after customers have already been imported.
Questions buyers ask before syncing directory users into Zammad
How much does it cost to sync Active Directory users into Zammad?
The cost has two parts: the Zammad software and the work to connect it to your directory. Self-hosted Zammad has no license fee, since the software is licensed under the GNU Affero General Public License version 3. If you want vendor support, Zammad's pricing page lists 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. The implementation cost depends on the number of directories, how clean the user attributes are, how many groups must map to Zammad roles, whether customers are included in the sync, and how much testing your change process requires. Ask for a quote built from a written scope that lists each of these items, and separate one-time setup from any recurring support or maintenance.
How long does a directory sync project take to finish?
Duration depends on the scope you agree in writing before work starts. Most engagements are fixed-scope, so the timeline comes from the agreed deliverables rather than from a guessed figure. The main drivers are the number of directories, the state of the attributes that identify users, the number of groups that need a role decision, whether customer accounts are in scope, and how long your change window and testing cycle take. Expect delays when the role model has no named owner or when directory access is granted late. Ask for a timeline with milestones tied to the client inputs, and confirm which dates depend on your team and which depend on the delivery work.
What does the client need to provide before directory sync work starts?
The client provides access, decisions and a place to test. You need read-only directory access with a service account that Zammad can use to bind, plus the details of the certificate authority if the connection uses LDAPS. You also need a named owner who can sign off the role model, meaning which directory groups become agent roles, which become administrators, and which apply to customers. Test accounts should cover active, disabled and expired users, and a test directory or staging copy helps avoid exposing production data. Finally, agree on a change window for the production cutover and a rollback plan. Confirm the exact access your directory team can approve, since their policies may limit service account rights.
Can our internal team set up directory sync without a partner?
Yes, an internal team can do this with the Zammad admin documentation and a test directory. The setup involves configuring the directory connection, choosing which attributes and groups to import, and mapping groups to roles. Your team will need someone who understands your directory schema and someone who can make role decisions for the helpdesk. A partner adds the most value in the role model design, the attribute audit, structured testing across edge cases and the production cutover. It also helps when several directories or customer accounts are involved. Decide early which parts your team will own, and ask any partner to document the configuration so your administrators can maintain it later.
Does one-way sync mean changes in Zammad flow back to the directory?
No, a one-way sync reads from the directory into Zammad and does not write changes back. Users, groups and attributes are read from Active Directory or LDAP, so account creation, password resets and group membership remain managed in the directory. Changes made to imported users inside Zammad will not update the source record. This affects how you handle offboarding, because a disabled account in the directory must stop access in Zammad through the sync cycle, not through a manual edit. Confirm the current sync direction, deactivation behavior and update interval in the Zammad admin documentation for your release before you finalize the design.
What happens when a directory has no organization field?
Zammad does not map directory attributes to organizations, so customer grouping needs a separate plan. Organizations in Zammad group customers for reporting, permissions and ticket visibility, and a plain directory import does not create that structure on its own. Common approaches include mapping a department or company attribute to a value you maintain, or assigning organizations through a documented process after import. Each approach affects maintenance, because new users must land in the right organization without manual work. Ask for a written decision on this point during scoping, and check the current Zammad behavior in the admin documentation so the design matches the release you plan to run.
How should we test directory sync before go-live?
Test in a staging Zammad instance against a test directory, then repeat the checks against production data in a read-only way. Cover the core cases: a new agent receives the right role, a user moved between groups loses the old role, a disabled account stops working, and a customer appears with the correct email and identity. Test group nesting, duplicate email addresses and accounts without a mail attribute, since these often cause import errors. Keep a record of each test, the expected result and the observed result. Plan a rollback path, such as disabling the sync job and reverting role changes, and confirm who approves the go-live decision.
Should we sync several directories into one Zammad instance?
Syncing several directories is possible in principle, but each one adds mapping work and identity risk. The topic scope covers handling more than one directory, so the design must decide how to handle users who appear in two sources, which source wins when attributes conflict and how groups from each directory map to the same roles. Duplicate identities are the most common problem, because one person can exist in two directories with different email addresses. Count each additional directory as a separate set of attribute and group decisions in your scope. Confirm in the Zammad admin documentation how multiple directory sources are configured in your release and what precedence rules apply.
How DeployOpen scopes and delivers the Zammad directory sync
DeployOpen plans the directory sync as part of the Zammad deployment, in infrastructure you control, so agent and customer accounts can follow changes made in the directory. Each engagement starts from a written, fixed scope that names the directories, group-to-role mapping and the one-way sync limits your team has to accept. Ongoing support and upgrades are available as a retainer.
How we scope
- The written scope names each directory, its domain or base DN, and the accounts in and out of sync.
- Group-to-role mapping is agreed up front, so agent and customer roles are decided before any import runs.
- The scope records that sync is one-way and that Zammad has no organization mapping, so those limits are signed off.
How we build
- Directory access uses a bind account with the narrowest read rights, reviewed with your directory team before connection.
- Group filters, attribute mapping and role rules are configured in a staging Zammad instance first.
- Each additional directory is tested for duplicate accounts and conflicting identifiers before it joins the sync.
How we hand over
- Sync jobs, mapping tables and the bind account's rights are documented in a runbook your team owns.
- Test cases cover joiners, leavers, role changes and a directory outage, with results recorded for your review.
- Your team receives a walkthrough on running a manual re-sync and checking which accounts a directory change affected.
How we support
- Ongoing support under a retainer can cover directory schema changes, Zammad upgrades and sync failures.
- Upgrade checks re-test the sync configuration before a Zammad upgrade reaches production.
- Ask the quote to name each directory, mapping rule and retainer term, so the written scope is complete.
