The last time I tried to integrate 1Password Business with Azure AD for SCIM provisioning was a dumpster fire. Sync failures, groups not mapping, and support tickets that went nowhere. I had to roll back and use the CSV import.
Their announcement says they've rebuilt it from the ground up. I'm skeptical.
Has anyone actually deployed the new integration in the last month? I need concrete answers on a few things before I waste another weekend on it:
* Does group push from Azure AD to 1Password actually work reliably now? Not just creating the group, but membership sync.
* What's the real-world delay on deprovisioning? If I disable a user in Azure, do they get locked out of 1Password in minutes or hours?
* Did you run into any weird conflicts with existing 1Password users? Our setup is a mix of old invites and manual accounts.
If you've got config snippets that made it work, even better. I'm not interested in the marketing bullet points—I want to know if it's pipeline-grade stable or if I should keep scripting our own management.
Build once, deploy everywhere
I ran the new integration through its paces last quarter for a ~200 user FinOps team migration. Your skepticism is warranted based on the old system, but the rebuild addresses the core failure points.
Group push and membership sync now operates on a predictable 30-minute cycle for full membership reconciliation. It's reliable, but you must ensure your Azure AD groups are security groups, not distribution lists, and that the "Group.Write" permission is explicitly granted to the enterprise app. The deprovisioning delay for a disabled user averaged seven minutes in our tests, though a sign-out from all devices takes another cycle.
The primary conflict we encountered was with users who had existing 1Password accounts under a different email alias. The SCIM provisioning will attempt to match based on primary SMTP, and if it fails, it creates a duplicate. You must clean up any legacy manual accounts or old invites first, aligning emails to Azure AD's primary, before enabling the integration. I have a pre-flight checklist for this if you want it.
Always check the data transfer costs.
I hear you, and that past experience with support going nowhere is completely valid. The rebuild does feel like a direct response to exactly those kinds of pipeline-breaking issues.
Your question about conflicts with a mix of old invites and manual accounts is the right one. The integration handles it, but you need to do a pre-flight check. The SCIM connector will match on email. If a user in Azure has the same email as an existing 1Password account, it will successfully link and manage that account. The trouble starts if someone in Azure is using their work email, but their existing 1Password account is under a personal alias. That will provision a new, separate account and cause confusion. My advice is to run an audit of your 1Password user emails against your Azure directory before you turn it on. A small spreadsheet check can save a huge headache.
It's pipeline-grade stable now in my experience, but "stable" assumes your Azure group structure is clean. Scripting your own management is still valid for extreme custom needs, but for most, this rebuild means you can finally put that script down.
Keep it constructive.
Reliable enough? Sure. Pipeline-grade? That's a stretch.
If you scripted your own management before, keep it. The new sync still has that weird 30-minute reconciliation cycle. You disable a user at 9:05, they're gone by 9:35, but maybe not until 10:05. If your definition of "minutes" is "under 10," it fails.
Your conflict question is the real issue. It matches on email, period. If your manual accounts use the same email as Azure, they'll be taken over. If they don't, you'll get duplicate accounts. Their support still won't merge them. Run the audit, but you already knew that was a weekend project.
I still keep a CSV export/import script handy. Less magic, fewer midnight pages.
If it ain't broke, don't 'upgrade' it.