How Zammad connects Microsoft 365 email through the Graph API
Support mail for shared addresses, such as support or billing, often arrives in Microsoft 365 and has to land as tickets in Zammad. The connection method to plan for is Zammad's Microsoft 365 Graph email channel, which reads mailboxes and shared mailboxes through an application registered in Microsoft Entra. That registration is the trust boundary for the whole setup, so the first decision is which mailboxes the application may read and how narrowly its permissions are scoped. Zammad's documentation describes this channel as the forward-looking way to connect to Microsoft 365, and it is the option this page assumes throughout.
At a high level, inbound mail moves in one direction. Zammad authenticates to Microsoft Graph with the registered application, retrieves new messages from the mailbox you select, and creates tickets or adds articles to existing ones. Agent replies go back out through the same Microsoft 365 account, so the mailbox that receives support mail is also the identity that sends it. Confirm for your Zammad version how often inbound retrieval runs, what happens to messages after they are processed, and how any attachment size limits are applied. These behaviors affect both ticket timing and mailbox growth, so test them in your own instance before go-live.
Zammad provides a folder picker for the channel, so you choose the folder it reads during setup. Decide early whether Zammad should read the whole inbox or a dedicated support folder that mail rules fill. A dedicated folder keeps unrelated messages out of the ticket pipeline and simplifies audit questions, but it depends on rules that someone must own and document. Shared mailboxes are a main reason to choose this channel. Zammad's documentation says the Graph channel offers better shared mailbox support and can save license costs, so confirm the licensing position with your Microsoft 365 administrator before you assume any savings.
The main trade-off is the From header. With the Graph channel, Microsoft replaces the From header of outgoing messages with the configured display name of the Microsoft 365 account, which the IMAP variant avoids. Customers therefore see the account's display name on replies, whichever agent wrote them. Decide before the build whether that fits your brand and whether agents must be identifiable in replies. Set the display name deliberately in Microsoft 365, then send test replies to external addresses across several mail clients to confirm what customers actually see.
The work covers three areas. Identity setup means registering the Entra application, granting Graph permissions for the mailboxes in scope, and agreeing who holds the client secret or certificate and when it is rotated. Channel configuration means creating the channel in your Zammad instance, selecting the folder, and assigning the group that receives the tickets. Testing means sending inbound messages with attachments, replying from Zammad, and checking that customer follow-ups attach to the existing ticket. DeployOpen plans and implements these steps in your own Zammad instance. Your team provides tenant administrator access and mailbox owner sign-off, and the scope and deliverables are agreed in writing before work starts.
What you need in place before connecting Microsoft 365 to Zammad
The Graph channel depends on three things being ready at once: a working Zammad instance, a Microsoft 365 tenant where an administrator can grant consent, and a network path that lets Zammad reach Microsoft over HTTPS. Work through the cards in order, because a gap in one area usually surfaces as a confusing error in another.
Zammad instance on a supported release
Confirm that the Zammad instance you plan to connect is running a release that still receives fixes, and that the Graph channel is available in that release. Check the Zammad admin documentation for the channel's current behavior before you start, because channel options can change between releases. Plan the connection in a non-production instance first if your production instance is on an older line.
PostgreSQL 15 or newer
Zammad stores its content in PostgreSQL, and the software requirements page sets PostgreSQL 15 as the minimum supported version. Confirm the server version and that the database backup you rely on covers it before you add a new channel, because the channel writes ticket and article data as soon as mail is fetched. Check the requirements page for the current minimum before you finalize your build.
Redis 7 and the reverse proxy
Redis 7 or newer is required for realtime websocket communication, so agents will not see new mail arrive in the interface without it. Nginx or Apache must sit in front of Zammad as the reverse proxy, and its websocket and upload settings affect how the channel status and attachments behave. Verify both services on the same host or cluster that will run the Graph connection.
Microsoft 365 tenant and administrator access
Someone with administrator rights in the Microsoft 365 tenant must be able to register an application in Microsoft Entra and grant admin consent for the permissions Zammad requests. Agree in advance who holds that role, how the consent request will be approved, and who keeps the client secret or certificate after setup. Confirm the current permission names and admin consent steps against the Zammad admin documentation and Microsoft's own documentation, not this page.
Mailboxes and shared mailbox licensing
List every mailbox and shared mailbox you intend to connect, and note which Zammad group will handle each one. Licensing for shared mailboxes differs from user mailboxes and is a key reason teams choose the Graph channel, so ask Microsoft or your licensing partner to confirm what your tenant needs. Do not assume a license model from this page, and confirm the Graph-related licensing rules with Microsoft's documentation before you buy anything.
Outbound HTTPS and public URL
The Zammad host must reach Microsoft login and Graph endpoints over outbound HTTPS, so review egress firewall rules, proxies and DNS resolution on that host. Set the external URL in Zammad to the public address your users and Microsoft will use, and make sure that address resolves to the host. Install a valid certificate for that name, because a mismatch between the URL and certificate can break the redirect step during connection setup.
Why the Graph channel is the option to plan for compared with IMAP
For a new Zammad deployment that connects to Microsoft 365, plan around the Graph channel first and treat the IMAP variant as the fallback. Zammad's admin documentation describes the Microsoft 365 Graph email channel as the future-proof way to connect to Microsoft 365. It also names two practical reasons: better support for shared mailboxes, which can reduce the number of licensed accounts you need, and a folder picker that lets you choose the inbox folder during setup instead of relying on a fixed name. Both points affect how you design the mailbox model before anyone configures a channel.
The first decision point is the From header. With the Graph channel, Microsoft replaces the From header of outgoing emails with the configured display name of the Microsoft 365 account. The IMAP variant does not have this behavior. If your support team sends replies from a shared address such as support@ and customers expect that exact sender identity, test a reply on the Graph channel before you commit. Confirm with your mail administrator which display name Microsoft will apply, and decide whether that is acceptable for your customers, your brand and any mail-routing rules that match on the sender.
The second decision point is what happens to existing IMAP channels. Ask whether current IMAP channels will be migrated to Graph, left running until a cut-over date, or closed once new Graph channels are verified. Running both in parallel for the same mailbox can cause duplicate ticket creation or split replies, so write down which channel owns each mailbox and when the old one is disabled. Also check how existing ticket threads and reply-to addresses will behave after the switch, and test that outbound mail still reaches customers from the expected address.
The license position needs its own check. Do not assume that moving a shared mailbox to the Graph channel will reduce your Microsoft 365 costs. Ask Microsoft and your reseller which licenses your shared mailboxes need under your current agreement, and whether any change in how Zammad accesses them alters that position. Record their answer in the decision document so the cost case is based on the confirmed terms rather than on the product description.
Before you finalize the choice, confirm every behavior described here against the Zammad documentation for the exact release you will run. Channel options, folder selection and sender handling can change between releases, and the admin documentation for Microsoft 365 Graph email is the authoritative reference for your version. Run a pilot with one shared mailbox, send and receive test messages, and check the From header, folder selection and thread continuity before you move the remaining mailboxes.
Configuring the Microsoft 365 Graph channel in Zammad, in order
This sequence takes an administrator from a confirmed Zammad release to a verified mailbox channel, with inbound and outbound tests passed. Each step closes with a check, so the team knows whether to continue before the next dependency is built.
Confirm the Zammad release and admin role
Confirm that your Zammad instance runs a release whose documentation covers the Microsoft 365 Graph channel, and that the person doing the setup holds an administrator role in Zammad. Read the channel section of the admin documentation before you start, so the team works from the current steps and field names. Done when an administrator can open the channel settings and see the Microsoft 365 Graph option listed among the available email channels. If the option is missing, stop and check the release before continuing.
Register the Entra application and record identifiers
A Microsoft Entra administrator registers an application for Zammad in the tenant that owns the mailboxes. Record the tenant and application identifiers the registration produces, and store them with the rest of the configuration record so the team can find them during later troubleshooting. Done when the application appears in the Entra app registrations list and its identifiers are written into your secure record. No secret or certificate should be attached yet.
Grant the permissions the channel documents
Add only the Microsoft Graph application permissions that the Zammad channel documentation lists for mail access, then have a tenant administrator grant admin consent. Confirm the exact permission names in the admin documentation on the day you build, because the list is defined by the vendor and can change between releases. Done when every listed permission shows as granted with admin consent in Entra, and no additional permissions appear on the application.
Create a client secret or certificate securely
Create either a client secret or a certificate for the application, following your organization's rules on credential type, lifetime and storage. Place the value in your approved secrets store, record the expiry date in your renewal calendar, and keep it out of tickets, chat and shared documents. Done when the credential is stored with a named owner and a renewal reminder is set, and the value is ready to enter in Zammad during the next step.
Add the channel and select the inbox folder
In Zammad, add a Microsoft 365 Graph channel and enter the identifiers and credential from the earlier steps, then save. Open the folder picker and select the mail folder that should feed tickets, which is usually the inbox of the mailbox in question. Done when the connection status reads as connected and the picker shows the intended folder as the selected source. If the connection fails, check the permissions and consent before changing the Zammad settings.
Set the mailbox, shared mailbox and sender name
Enter the mailbox address, or the shared mailbox address if the channel serves a shared queue, and set the sender display name that customers should see on replies. Map the channel to the target group so that inbound tickets land in the correct queue. Done when the saved channel shows the intended mailbox, display name and group, and the support lead confirms that the display name matches approved sender wording. Use the admin documentation for the exact field names.
Send a test ticket inbound
From an address outside your organization, send an email to the configured mailbox and allow the channel to process it. Then open the ticket list in Zammad and find the new ticket. Done when a new ticket exists, it sits in the expected group, and its sender, subject and body match the test message. If the ticket does not arrive, check the connection status and the folder selection before changing any other setting.
Send a test reply outbound
Reply to the test ticket from Zammad and check the message as the external recipient receives it. Microsoft replaces the From header of outgoing mail with the display name configured on the Microsoft 365 account, so confirm that the sender shown matches the name set in Zammad and the name the account owner expects. Done when the received reply shows the expected sender, and the team records the result as the sign-off for the configuration.
Which Microsoft 365 mailbox fields map to Zammad channels, groups and tickets
This table maps the Microsoft 365 and Entra values you collect to the Zammad channel settings, groups and tickets they control. Read each row as a field, the Zammad setting it feeds and the check to run in your own tenant before go-live. The main takeaway is that the sender name and shared mailbox licensing behave differently from the IMAP route, so confirm both early.
| Field or behavior | Zammad and Graph API mapping | What to confirm in your tenant |
|---|---|---|
| Entra application identifiers | Application (client) ID, directory (tenant) ID and client secret from the app registration go into the channel settings. | Confirm the app registration exists, the secret has not expired and the granted permissions match the Zammad admin documentation. |
| Mailbox address | The address of the mailbox or shared mailbox that the channel reads sets which Microsoft 365 mail Zammad picks up. | Confirm the address matches the Microsoft 365 object exactly and that the app identity can access it. |
| Inbound folder | The folder picker selects the Microsoft 365 folder whose messages appear in the inbox agents work from. | Confirm which folder receives new requests and whether mail rules move messages before Zammad reads them. |
| Group assignment | Incoming tickets from the channel are assigned to the Zammad group you select for it. | Confirm the group exists, the right agents are members and the group matches the team that owns the mailbox. |
| Shared mailbox addresses | The Graph channel supports shared mailboxes, which the Zammad documentation says can save license costs over IMAP. | Confirm the license entitlements for shared mailbox access with Microsoft for your tenant, since savings depend on your current licensing. |
| Sender identity | Microsoft replaces the From header of outgoing replies with the display name configured on the Microsoft 365 account. | Confirm the display name is the one customers should see, because the IMAP variant avoids this limit. |
| Reply threading | Customer replies are attached to existing tickets through the ticket reference in the message, not through a new ticket. | Send a test reply from an external client after setup and confirm the existing ticket updates. |
Securing the Entra app registration and mailbox access in Zammad
The Graph channel gives Zammad a standing identity in your Microsoft 365 tenant, so its access is the access you grant and can revoke. The six areas below cover what the app can reach, how its credential is stored and rotated, who can change the setup inside Zammad, what Entra records, and what personal data lands in tickets. Because Zammad runs in your infrastructure, you own each control and each security release.
Least-privilege permissions and mailbox scope
Grant the app only the Graph application permissions the email channel needs, and check each one against Microsoft's current permission reference before consent. Application permissions apply tenant-wide unless you restrict them, so confirm how to scope access to the specific mailboxes Zammad monitors, whether through Exchange Online access policies or another mechanism. Then test that a mailbox outside that scope is refused. Ask Zammad's admin documentation which permissions the Graph channel requires in your version.
Client secret or certificate rotation
Decide whether the app authenticates with a client secret or a certificate, and record the expiry date of your choice in a calendar or monitoring system before the credential is created. Credentials expire on a fixed schedule set when they are issued, and an unnoticed expiry stops mail sync in a way that may not be obvious from the ticket queue. Plan a rotation that adds the new credential, updates the Zammad channel, confirms that inbound mail still arrives, and only then removes the old one. Confirm which credential types the Graph channel accepts in your version.
Secrets manager storage
Keep the client secret or certificate private key out of configuration files, environment files committed to source control, and deployment scripts. Store it in the secrets manager your organization already runs, such as OpenBao, a cloud key vault or an enterprise vault, and inject it at runtime. Confirm where Zammad keeps the credential once it is entered in the channel form, because database backups may then carry it. Also confirm which injection method your Docker Compose or Helm setup supports and who can read the secret at each stage.
Admin role separation in Zammad
Limit who can open the Microsoft 365 channel settings and who can change the folder selection, display name or mailbox assignment. Keep the Zammad admin role separate from day-to-day agent roles, and give channel setup to a small group that does not work tickets. Review that group when staff change roles, because a change to channel configuration can redirect which mail reaches which queue. Confirm the admin permissions available in your Zammad version and whether group-based roles cover channel settings.
Entra sign-in audit logging
Review the sign-in logs for the app registration in Entra, which record authentication made by the application identity rather than by a user. Confirm the retention your tenant and license provide before you rely on those logs for an investigation, and set retention in line with your log policy. Forward the logs to your SIEM if your security team monitors there. Alert on unusual sign-in locations, repeated failures or sudden changes in volume. Confirm which sign-in log categories cover service principal activity in your tenant.
Attachments and personal data in tickets
Mail channels bring attachments and customer personal data into tickets, so decide what is stored and for how long before go-live. Zammad uses Elasticsearch to search the content of email attachments, which extends where personal data can be found, so confirm how that index is secured and what it retains. Set deletion rules in line with your privacy notice, and restrict attachment download to roles that need it. Keep the Zammad release current with the security releases the vendor publishes.
Planning around the From header limitation on outgoing replies
Decide how replies will appear to customers before you cut over, because the Graph channel changes the sender identity. Zammad's admin documentation states that, with the Microsoft 365 Graph channel, Microsoft replaces the From header of outgoing emails with the configured display name of the Microsoft 365 account. The IMAP variant avoids this behavior. In practice, the display name on the mailbox account becomes the name every customer sees on every reply sent from Zammad. For a shared mailbox such as a support address, that name is part of your public support identity, so review it during design alongside the Entra app registration and folder selection, before agents start answering tickets.
The business impact is mostly about recognition. A reply that arrives under a name the customer does not associate with your support team can look unexpected, and that can reduce trust in the message. Recipients' mail filters and clients also group and score messages partly on sender details, so an unfamiliar sender name may affect where replies land or how they thread in a customer's inbox. Treat these as points to test before assuming an outcome. Illustrative example: a shared mailbox called Support Desk whose account display name reads Corporate IT Operations would send every customer reply under that second name, which a customer who only knows the support address may not recognize.
You have three options to evaluate. First, accept the display name and tell support staff what customers will see. This needs no tenant change, but it makes the account display name a visible part of your support brand. Second, align the account display name with the name customers expect, such as your support team's name. Confirm with your Microsoft 365 administrator what else uses that display name, including calendars, other applications and directory entries, because changing it affects all mail sent from that account. Third, choose the IMAP variant where sender identity matters most, accepting its own setup and operating trade-offs. Zammad positions the Graph channel for better shared mailbox support and possible license savings, so weigh those benefits against your sender requirement.
Test before you commit. Send replies from a test ticket to recipients outside your organization, using the mail providers your customers use, and check the From name, reply threading and whether the message lands in the inbox or in a spam or junk folder. Repeat the test for each mailbox you plan to connect, because a shared mailbox and a personal mailbox can carry different display names. Confirm the behavior in your own tenant, since the result depends on your Microsoft 365 configuration and the account you connect, and record the sender name observed in each test.
Document the decision in a form support staff can use. Record which option you chose, the display name customers will see for each connected mailbox, who owns changes to that name in Microsoft 365, and the date of your last test. Give agents a short, approved answer for customers who ask why a reply shows an unexpected name, and tell them where to report a new sender issue. Review the record after any change to the account, the Graph channel configuration or the Zammad release in use, because any of these can alter the sender name customers see.
Troubleshooting Microsoft 365 email connections in Zammad
This table lists nine failures seen when Zammad connects to Microsoft 365 mail through the Graph API, with the likely cause, the fix and the check that confirms it. Work through the causes in order, since consent and identifiers block every other step. Most issues resolve in the Entra app registration or the channel settings, so confirm each fix with a test message before moving on.
| Symptom | Likely cause | Fix | Confirm with |
|---|---|---|---|
| Admin consent not granted | The application permissions were requested, but a tenant administrator never approved them in Entra. | Have a tenant administrator grant admin consent for the application permissions in the Entra app registration. | The channel reports no connection error after a test fetch, and Entra shows consent granted for the app. |
| Wrong tenant or application identifier | The tenant ID, client ID or secret was copied from another app or tenant, so token requests fail. | Copy the directory (tenant) ID and application (client) ID from the correct app registration and re-enter them. | Entra sign-in logs show requests under the expected app, and the channel connects successfully. |
| Expired client secret | The client secret passed its expiry date in the app registration, so sign-in to Microsoft fails. | Create a new client secret, enter it in the channel, and set a reminder before the new secret expires. | A test connection succeeds, and Entra sign-in logs show successful sign-ins after the change. |
| Mailbox lacking access for the application | The app has consent but is not permitted to read the mailbox, which often happens with shared mailboxes. | Grant the application access to that specific mailbox using the access scoping your tenant uses, and confirm the address matches. | A test message sent to that mailbox becomes a ticket, and sign-in logs show no access-denied errors for it. |
| Wrong folder selected, no tickets appear | The folder picker points to a folder where mail does not arrive, such as Sent Items or Archive. | Reselect the inbox folder in the channel settings, save, and send a test message to the monitored address. | The test message appears as a ticket, and the folder named in the channel matches where Outlook receives mail. |
| Mail stuck in a sub-folder | An Outlook rule or a user moves incoming mail into a sub-folder that the channel does not read. | Select the sub-folder in the channel settings, or remove the Outlook rule that moves mail before Zammad fetches it. | A test message moved into the sub-folder becomes a ticket, and the Outlook rule list shows no unexpected moves. |
| Outbound replies show an unexpected sender name | The Graph channel replaces the From header with the display name of the Microsoft 365 account, unlike the IMAP variant. | Set the display name on the Microsoft 365 account to the name customers should see, then test before go-live. | Send a test reply to an external address and check the From header in the received message. |
| Outbound HTTPS blocked by a proxy or firewall | Zammad cannot reach the Microsoft sign-in and Graph endpoints over HTTPS, so fetching or sending fails. | Allow outbound HTTPS from the Zammad hosts to the Microsoft endpoints your security team approves, or set the proxy Zammad uses. | Run a connection test from the Zammad host, then check channel status and the Zammad log for timeouts. |
| Duplicate tickets from forwarded or looped mail | Mail forwarded back to the monitored address, or auto-replies that trigger further mail, creates new tickets. | Remove forwarding that returns to the monitored address, and confirm auto-reply and loop handling stop Zammad answering its own mail. | One test message creates exactly one ticket, and article headers show no automatic reply markers. |
Questions buyers ask before connecting Microsoft 365 email to Zammad
How much does it cost to connect Microsoft 365 email to Zammad?
Self-hosted Zammad has no license fee, so the cost of the Graph connection is mostly labor and the infrastructure you run. Optional self-hosted support subscriptions are named Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, according to the Zammad pricing page. A subscription covers vendor support, not the work of registering the Entra app, designing folders or testing mailboxes. Hosted Zammad plans are billed per agent per month instead. Integration labor is separate and priced from a written scope. Ask for a quote that lists tenant access, mailbox count, folder design, testing and handover as separate lines so you can see what each part costs.
How long does a Microsoft 365 Graph email integration take?
The duration depends on four things: how quickly you can grant tenant access, how many mailboxes and shared mailboxes are in scope, how the inbox folders are designed, and how much testing each mailbox needs before cutover. Approval steps inside your organization often take longer than the technical setup, so start those early. Mailbox owners should confirm which folders hold support mail and which should be ignored. Ask for a timeline in the written scope that lists each phase and the customer input it waits on, and plan your own calendar from that document.
What do we need to provide before the Graph email work starts?
You need an Entra administrator who can register the application and grant the consent that Graph access requires, plus a named owner for each mailbox in scope. Mailbox owners confirm which folders should create tickets and which should be skipped. Your team also decides the sender identity agents reply from, because the Graph channel uses the display name of the Microsoft 365 account in the From header. Decide whether each queue is carried by a shared mailbox or a user mailbox. Provide a test mailbox and a change window for cutover, and name the person who approves the final go-live.
Can our own admin connect Microsoft 365 email to Zammad alone?
Yes, a capable administrator with Entra and Zammad experience can follow the Zammad admin documentation for the Microsoft 365 Graph channel and complete the basic setup without a partner. The documentation covers channel configuration and the folder picker. What a partner adds is planning and verification: a folder and queue design that matches how your team works, a test plan that covers replies, attachments and shared mailboxes, a written record of the app registration, and a handover your team can repeat for the next mailbox. Confirm that your admin has time for testing and that someone owns each mailbox after go-live.
What support response times come with a self-hosted Zammad subscription?
Zammad's pricing page lists self-hosted support response times of 6 hours for the Business subscription, 4 hours for Enterprise and 2 hours for Corporation. These figures come from the vendor and apply to Zammad support requests, not to integration work, which is scoped separately. Check the current terms on the pricing page before you sign. Also confirm whether the subscription covers Graph channel configuration in your environment, and ask how a Microsoft 365 issue is routed when the cause sits in Entra rather than in Zammad. Get the severity definitions in writing.
Does the Microsoft 365 Graph channel change the From header on replies?
Yes. With the Graph channel, Microsoft replaces the From header of outgoing emails with the configured display name of the Microsoft 365 account, so the sender name customers see may not match what agents expect. The IMAP variant avoids this replacement. Decide before go-live whether that display name is acceptable for each queue, and whether a different sender identity, a reply-to setting or IMAP for specific mailboxes fits your requirements. Send test replies from each mailbox to confirm what recipients see. Document the decision so future mailboxes follow the same rule.
Who owns the integration after go-live, and what does it cost to run?
Your team owns the running system: mailbox access, app registration secrets, folder rules and the Zammad instance itself. Recurring costs come from your hosting, staff time and any support subscription or hosted plan you choose. Hosted Zammad plans are billed per agent per month, with Starter at 7 EUR (annual billing) for up to 5 agents, Professional at 16 EUR for up to 35 agents and Plus at 25 EUR for unlimited agents, according to the Zammad pricing page. Ask any partner for a quote that separates one-time setup from recurring support, and confirm who rotates credentials and reviews folder rules over time.
How DeployOpen scopes and delivers the Microsoft 365 Graph integration
DeployOpen plans and delivers the Zammad Microsoft 365 Graph email channel inside your own infrastructure, starting from the mailboxes and shared mailboxes you need to connect. Work is agreed as a fixed-scope engagement with written deliverables, and ongoing support is available as a retainer once the channel is live.
How we scope
- Inventory the mailboxes and shared mailboxes that Zammad must read and reply from, with their owners and intended queues.
- Define the Entra app registration, permission grants and tenant access model the written scope will cover.
- Record the folder selection for each inbox and how the From header limitation will be explained to support and sales teams.
How we build
- Configure the Microsoft 365 Graph email channel in your Zammad instance and connect each agreed mailbox or shared mailbox.
- Test inbound fetching, folder selection, threading and outbound replies against a staging copy of your Zammad installation.
- Confirm the display name on outgoing messages and document any remaining differences from the IMAP channel in your environment.
How we hand over
- Deliver a written configuration record covering app registration settings, mailbox mapping, folder choices and test results.
- Document the secret rotation steps, owner contacts and the procedure for adding a new mailbox to the channel.
- Walk your administrators through daily checks and the troubleshooting steps for failed fetches or unexpected sender names.
How we support
- Offer ongoing support for the channel as a retainer, covering configuration changes and Zammad upgrades that touch email.
- Review the Graph channel after Zammad version upgrades and after changes to your Microsoft 365 tenant policies.
- Ask for a quote from the written scope, which states what recurs and what is a one-time build cost.
