Open-source alternative to Dynamics 365 Customer Service

This is the most common starting point when the sales team is not ready to leave Dynamics 365 Sales but the support contract, queues or per-user licensing for Customer Service are the pressure point. Zammad takes over cases, email channels and knowledge content, while Dynamics 365 keeps accounts, opportunities and quotes. The integration then carries the weight, so you need a stable key that both systems store for each customer.

• Pick one authoritative account ID: Use the Dataverse account GUID or your ERP customer number as the shared key, and store it as a custom field on the Zammad organization record.
• Sync in one direction first: Push new organizations and contacts from Dynamics 365 into Zammad through its API, so support agents never create duplicate customers.
• Decide who owns contact edits: Name a system of record for email addresses and phone numbers, or the two systems will drift apart within weeks.
• Plan identity early: Connect Zammad to your identity provider through SAML or OpenID Connect, so agents do not keep a second password.
• Keep a Dataverse export path open: Retain exports of the case history you need for reporting, since the Customer Service data does not move automatically.

Before cutover, confirm with your Zammad partner and your Microsoft licensing contact exactly which Customer Service tables and channels stop, and test the identifier mapping with a sample of accounts.

Moving both functions to one self-hosted CRM removes the cross-system key problem, but it creates a larger cutover. SuiteCRM 8 includes case management alongside accounts and opportunities, so sales and service records share one database and one set of identifiers. Zammad can still run beside it if your service volume or channel needs exceed what the CRM case module does well, so confirm that split before you commit.

• Map Dataverse tables to one schema: Accounts, contacts and cases should share a single customer ID in the new database, which removes the need for a sync job.
• Choose the SAML path deliberately: SuiteCRM 8 supports LDAP with AUTH_TYPE=ldap and SAML with AUTH_TYPE=saml. Confirm the SAML configuration against the 8.7.0+ reference before rollout.
• Plan for the SAML logout gap: From SuiteCRM 8.7.0 onward, IdP-initiated logout and POST binding to the logout service are not supported, so signing out at Entra ID does not end the SuiteCRM session. Tell agents to log out of SuiteCRM directly, and set session timeouts to match your policy.
• Test the migration path: SuiteCRM 7 to 8 is a migration rather than an upgrade, so if your existing data sits there, plan that work separately.
• Stage the cutover: Run a parallel period on a staging instance with real case samples before retiring the Dynamics 365 queues.

Ask your implementation partner to document the logout behavior in your access procedures, and confirm the current SuiteCRM 8 release line before you finalize the design.

Some organizations keep Dynamics 365 Sales as the system of record for revenue and add Zammad only for case handling. This works well when the sales team depends on Dynamics workflows and Outlook integration, and the service team needs email-first ticketing, macros and a self-hosted knowledge flow. The risk sits in the link, so define what travels between the two systems and what never does.

• Define the link object: Sync only the fields agents need to identify a customer, such as account ID, name and support tier, rather than full CRM records.
• Use the Zammad API for write-back: Store the Zammad ticket reference on the Dynamics 365 account so account managers see open cases without leaving the CRM.
• Handle SSO per application: Zammad supports SAML, OpenID Connect and several named providers, so configure it against the same tenant that signs in Dynamics 365 users.
• Choose the search tier with care: Elasticsearch is optional but recommended for search and attachment indexing, and it adds infrastructure that your team must run.
• Monitor the sync: Log failed API calls and alert on them, since silent failures are how account IDs diverge.

Confirm with the Zammad documentation which PostgreSQL, Redis and reverse proxy versions match your deployment, and document who approves changes to the integration.

Whatever split you choose, two design questions decide whether the new setup holds up: how account identifiers stay consistent across systems, and how users sign in once. Identifier drift causes more support escalations than any feature gap, and SSO errors lock agents out during the busiest hours. Treat both as design decisions made before any data moves.

• Freeze the identifier format: Use one stable ID that never changes after creation, and never reuse a retired ID for a new customer.
• Keep a crosswalk table: Store old Dataverse GUIDs alongside new IDs during the migration, so historical cases still resolve.
• Compare SAML and OIDC: Both protocols can authenticate users against Entra ID, but confirm how each system maps group claims to roles before assigning permissions.
• Document session behavior: Record what happens when a user signs out at the identity provider, and tell agents about the SuiteCRM 8.7.0+ limitation.
• Test with real accounts: Use a pilot group with a mix of standard and shared mailboxes to confirm sign-in, logout and role mapping.

Ask your identity team to confirm the claim names and group mappings in writing, and review the SuiteCRM SAML configuration reference with your security architects before go-live.