Connecting Integrations & Custom MCP Servers
QueueDesk integrates with identity directories and workspace providers so QueAssist can check real facts (is this account actually locked?) and take real actions (reset a password, add someone to a group) instead of just guessing from the ticket text — and so SSO/JIT provisioning and SCIM directory sync work for your team.
This is QueAssist calling out to your other systems. For the opposite direction — an external AI app connecting in to QueueDesk — see AI Agent Access.
1. Supported providers
Go to Settings → Integrations (/admin/settings/integrations) to see the connector list. Three providers are available:
- •Google Workspace — connects via a Google Cloud service account with domain-wide delegation.
- •Microsoft Entra ID (Azure AD) — connects via an Azure App Registration with OAuth client credentials.
- •Custom MCP server — connect any Model Context Protocol server of your own (internal tooling, or a vendor's hosted MCP endpoint) and QueAssist can use whatever tools it exposes.
Each connector shows a status dot: Not connected, Needs credentials (saved but not yet verified), Connection failed, or Connected (verified with a real, successful API call).
2. Connecting Google Workspace
Click the Google Workspace row, then fill in:
| Field | What to enter |
|---|---|
| Service account email | queuedesk-ai@your-project.iam.gserviceaccount.com — the service account you created in Google Cloud IAM. |
| Google Workspace domain | Your Workspace domain, e.g. yourcompany.com. |
| Admin impersonation email | A super admin account the service account impersonates via domain-wide delegation — used to run the live connection test. |
| Service account private key | Paste the full contents of the JSON key file downloaded from Google Cloud IAM. Encrypted at rest — you won't see it again after saving, only whether one is stored. |
Before this will connect, authorize the service account for domain-wide delegation in the Workspace Admin Console (Security → API controls → Domain-wide delegation) with these exact OAuth scopes:
https://www.googleapis.com/auth/admin.directory.user
https://www.googleapis.com/auth/admin.directory.group
https://www.googleapis.com/auth/admin.directory.group.member
Click Save & connect. QueueDesk makes a real API call using these credentials before marking the connector "Connected" — a saved-but-unverified connector shows as "Needs credentials" until that succeeds. If it fails with a Directory API error, double check the impersonation email is a real super admin and that all three scopes above were added (not just one).
3. Connecting Microsoft Entra ID
Click the Microsoft Entra ID row, then fill in:
| Field | What to enter |
|---|---|
| Tenant ID (Directory ID) | From your Entra tenant overview. |
| App (Client) ID | From Entra → App registrations for the app you created for QueueDesk. |
| Client secret | From Entra → App registrations → Certificates & secrets. Encrypted at rest, never shown again after saving. |
| Primary email domain (optional) | Your company's email domain, e.g. yourcompany.com. When set, identity-scoped tools refuse users outside this domain — the same protection as the Google Workspace domain field. Leave blank if you do not need an extra domain check. |
QueueDesk authenticates as this app itself, not as a signed-in user — so on API permissions, every permission you add must be Application type, never Delegated. Delegated permissions are ignored in this flow and are the most common cause of a "token exchange succeeded, but the directory call failed (403)" error. Add these as Application permissions under Microsoft Graph, then click Grant admin consent:
| Permission (Application) | Needed for |
|---|---|
User.ReadWrite.All | Checking account status, resetting passwords, enabling accounts |
GroupMember.ReadWrite.All | Listing and adding group memberships |
Click Save & connect to run the live verification.
4. Connecting a Custom MCP server
Click the Custom MCP server row, then fill in:
| Field | What to enter |
|---|---|
| Name | A short label so you recognise this connection later — shown nowhere but this settings page, e.g. "Internal IT tools." |
| MCP server URL | Must be a public HTTPS endpoint, e.g. https://mcp.yourcompany.com — QueueDesk's servers connect to it directly, so it can't be a localhost or private-network address. |
| Bearer token (optional) | Sent as Authorization: Bearer … on every request, if your server requires auth. Leave blank for a server with no auth. |
Click Save & connect. QueueDesk connects once to discover whatever tools your server exposes — those then appear in the Tools list on this connector exactly like a built-in provider, with the same read/write/sensitive tiers and the same tool-grant toggles described below.
5. Testing and re-verifying a connection
Once a connector shows Connected, its detail view shows when it was last live-verified and a Test connection button — use this anytime you rotate a credential or want to confirm it still works. "Connected" only ever means the most recent test succeeded; QueueDesk never marks something Connected just because you saved a form.
6. Tool grants and permission tiers
Every tool a provider exposes falls into one of three tiers, shown as a colored badge next to each tool in the connector's detail view:
- •Read — safe lookups, e.g. "Check if a user account exists," "List a user's security groups." Auto-executed as soon as the connector is Connected — no separate toggle needed.
- •Write — actions that change something, e.g. "Reset a password," "Add a user to a group." Off by default; you must explicitly flip the toggle for each individual tool before QueAssist can use it. Every write execution is logged.
- •Sensitive — e.g. "Create a Google Workspace support ticket" or "Flag this ticket for HR review." Never auto-executed no matter what — QueAssist always hands the ticket to a human instead. There's no toggle for these; it's a hard rule, not a setting.
Turn on exactly the write tools you're comfortable letting QueAssist use unsupervised — you don't have to enable all of them just because a provider is connected.
Identity scoping: even when a write tool is enabled, QueAssist can only act on a verified identity — never an arbitrary person named in conversation text.
- •Portal chat — the signed-in employee's account only. Asking QueAssist to reset a colleague's password is refused (logged as Blocked in the tool-call audit log).
- •Tickets, agentic resolution, and playbooks — the ticket's subject: Raise on behalf of email first, then Affected user, then the requester, then the inbound-email sender. When an agent opens a lockout ticket on behalf of someone else, QueAssist may act on that person's directory account — that is intentional for helpdesk workflows. See Identity Scoping & Safety for the full locked-out workflow and audit log guide.
Custom MCP servers: before you can enable a Write tool from a custom MCP server, QueueDesk needs to know which input field holds the user's email or username.
1. Open the tool in the connector's Tools list.
2. QueueDesk auto-detects a likely field when possible — you'll see Scoped to: fieldName (auto-detected) with a Change link.
3. Pick No identity needed only for tools that do not act on a specific person.
4. For write tools, confirm or override the field before enabling the toggle.
QueAssist injects the same verified identity into that field server-side — the same rule as Google Workspace and Entra. Write tools stay off until an identity field is set (or explicitly marked as not needed).
7. Disconnecting a provider
Open the connector and click Disconnect at the bottom of its detail view. This removes the stored credential and immediately stops QueAssist from calling any of that provider's tools, whether from agentic resolution or from a playbook step that referenced it.
8. Where connected tools get used
Once a provider is connected and its tools are enabled, QueAssist can use them in two places:
- •Agentic resolution and portal chat — QueAssist decides in the moment which tool to call, based on the conversation, subject to the tiers above.
- •Playbooks — an admin explicitly wires a specific tool into a specific step of a deterministic flow, so it always runs the same way for a given ticket type.
Every call either path makes is logged in the Tool-call audit log on Settings → QueAssist, and both are covered by the Emergency stop kill switch — turning that on immediately halts agentic resolution, playbooks, and every connected integration's tool calls without disconnecting anything.
9. Directory sync & JIT provisioning
When Google Workspace or Microsoft Entra is connected as an identity provider (see SSO & SCIM for the full setup), you additionally get:
- •SSO login — users sign in with their organizational credentials.
- •Just-in-time (JIT) provisioning — a user who signs in via SSO without an existing member profile is automatically created with the Employee role.
- •SCIM directory sync — user creations, updates, and suspensions sync from your directory to QueueDesk in real time.
Next: read AI Agent Access for the opposite direction — external AI apps connecting into QueueDesk — Identity Scoping & Safety for who QueAssist can act on in chat vs on tickets, or No-Code Playbooks to wire these tools into repeatable, deterministic flows.