SyncSignature integrations
Native directory sync with Google Workspace and Microsoft 365. Pattern integrations with the HRIS, CRM, and identity tools that already provision into them. No custom connectors to maintain.
5-seat minimum on Teams. Annual billing. No card required for trial.
How SyncSignature integrates with your stack
SyncSignature integrates with three systems directly: Google Workspace, Microsoft 365, and Azure AD (Entra ID). Google Workspace uses the Admin SDK Directory API for directory reads and the Gmail sendAs API for signature writes. Microsoft 365 and Azure AD use Microsoft Graph API for directory reads against Entra ID, paired with an Outlook add-in deployed via Microsoft 365 Centralized Deployment that installs and stamps signatures client-side inside each user's Outlook. None of these integrations route outbound mail through SyncSignature. Your email content never leaves Google or Microsoft.
For everything else, including HRIS systems like BambooHR and Workday, CRMs like HubSpot and Salesforce, and identity providers like Okta, the integration path is indirect and intentional: those tools already provision employee data into Google Workspace or Microsoft 365, and SyncSignature reads from the directory. You do not maintain a separate connector. You do not pay for an additional integration tier. The data flows through the systems you already trust.
Directory sync (core)
The mechanism behind every other integration on this page.
Directory sync for Google Workspace and Microsoft 365
Read-and-stamp directory sync for Google Workspace and Microsoft 365. No CSVs, no IT tickets, no mail rerouting. 5 to 10 minute propagation across every employee's Gmail or Outlook.
Email platforms and identity directories
These are the integrations SyncSignature builds and maintains directly.
Google Workspace
Single super-admin authentication. Reads the Admin SDK Directory and Gmail sendAs API. Signatures appear in every user's Gmail web, mobile, and connected client. No browser extension. No mail flow rule.
Microsoft 365
Lightweight Outlook add-in deployed through Microsoft 365 Centralized Deployment. Silent rollout to every user's Outlook on desktop, Mac, web, and mobile within 6 to 12 hours. Stamps signatures client-side at compose time. No transport rule, no MX changes, no server-side stamping.
Azure AD (Entra ID)
Direct Microsoft Graph API connection reads users, groups, and profile fields from Entra ID with read-only directory scopes (User.Read.All, Group.Read.All, Directory.Read.All). Pairs with the Outlook add-in for end-to-end M365 deployment. Two separate consent grants.
HRIS and people platforms
If your HRIS provisions into Google Workspace or Microsoft 365, SyncSignature picks up the changes from the directory automatically. The connector layer lives in your HRIS, not in SyncSignature. The full pipeline still works end-to-end.
BambooHR
Provisions employee records into Google Workspace or Microsoft 365 through native sync. SyncSignature reads from the directory and updates signatures within minutes of each change.
Workday
Provisions into Google Workspace or Microsoft 365 through Workday's native connectors. SyncSignature reads from the directory and reflects every title change, role move, or department reorg in the next sync cycle.
Rippling
Provisions employees into Google Workspace or Microsoft 365 from Rippling's identity layer. SyncSignature reads from the directory and updates signatures automatically.
Gusto
Provisions into Google Workspace through Gusto's directory sync. SyncSignature reads from Google Workspace and keeps every signature current.
ADP
Provisions into Google Workspace or Microsoft 365 through ADP's HCM connectors. SyncSignature reads from the directory.
Identity providers
If Okta, OneLogin, or another IdP is your source of truth for users, the standard pattern is: IdP provisions into Google Workspace or Microsoft 365, SyncSignature reads from the directory. You manage users in one place. SyncSignature stays current.
Okta
Provisions users into Google Workspace or Microsoft 365 through Okta's native lifecycle management. SyncSignature reads from the directory. SyncSignature does not pull from Okta directly today.
OneLogin
Provisions into Google Workspace or Microsoft 365. SyncSignature reads from the directory.
JumpCloud
Provisions into Google Workspace or Microsoft 365. SyncSignature reads from the directory.
CRM and sales tools
CRMs are typically the consumer of email signature data, not the source. The standard pattern is: HRIS or directory holds the canonical employee record, SyncSignature renders the signature, and the CRM reflects whatever the user sends. SyncSignature does not push data into a CRM and does not require a CRM connector.
HubSpot
Sales reps using HubSpot Sequences and Sales Hub send mail through Gmail or Outlook with the SyncSignature signature already applied. Signature analytics are tracked at the SyncSignature layer, not in HubSpot.
Salesforce
Salesforce Inbox, High Velocity Sales, and any Salesforce-connected mail client uses the SyncSignature signature applied at the Gmail or Outlook level. No Salesforce connector required.
Pipedrive
Pipedrive's mail features send through Gmail or Outlook with SyncSignature applied. No connector required.
What's not on this list (and why)
SyncSignature does not have a native connector for SCIM provisioning, on-premise Exchange, standalone SAML SSO, or any HRIS, CRM, or IdP outside the indirect pattern described above. If your stack requires a native SCIM endpoint, an Exchange transport rule integration, or a server-side stamping path through a vendor cloud, Exclaimer or CodeTwo are the right call. SyncSignature competes on speed, price, and the absence of mail rerouting. See the full comparison on the Exclaimer alternative and CodeTwo alternative pages.
Trusted by 30,000+ professionals across 1,000+ businesses
Plug SyncSignature into the stack you already run
Connect Google Workspace or Microsoft 365 once. Every HRIS, CRM, and IdP that provisions into those platforms is already wired up.