Hey everyone,
We've been using 1Password Business for about two years now, and while the core vault and sharing features are fantastic, our real breakthrough came when we started leveraging its SCIM and CLI tools to automate our entire new hire onboarding process. Last month, we had to onboard a cohort of 30 new developers and support staff, and we managed to get all their essential accounts provisioned and secured in just about an hour of total hands-on time. The key was stitching together a few different services around 1Password as the central secure credential hub.
Here’s a high-level view of the workflow we built:
**Trigger:** A new hire record is marked "Ready for IT" in our HR platform (BambooHR).
**Automation Steps:**
1. A webhook from BambooHR triggers a Make scenario.
2. Make formats the employee data (name, email, department) and creates a new user in our 1Password Business account via the SCIM API. This automatically generates a vault for them.
3. Simultaneously, the scenario creates accounts in our core SaaS tools (Google Workspace, GitHub, Slack, Jira) using each service's respective API. The generated passwords for these new accounts are *immediately* stored in the user's new 1Password vault via the `op` CLI tool running on a secure, always-on server.
4. Make then uses the 1Password CLI to create and share three specific items with the user's vault:
* A "Welcome" secure note with their initial login instructions.
* A shared "Company Logins" vault item with department-wide credentials.
* A shared "Wifi" item.
5. Finally, the scenario triggers an email from our internal system with a personalized link to set up their 1Password account and claim their vaults.
The real magic is in step 3. Instead of credentials being emailed or sitting in a temporary spreadsheet, they're written directly to 1Password as they're created. Here's a simplified example of the Make HTTP module configuration that calls our secure server to invoke the 1Password CLI:
```json
{
"url": "https://our-secure-automation-server.internal/run-command",
"method": "POST",
"headers": {
"Authorization": "Bearer [SERVER_KEY]"
},
"body": {
"command": "op item create --category=login --title='GitHub Account' --vault='[USER_VAULT_ID]' username='{{new_hire.email}}' password='{{github.generated_password}}' url='https://github.com' --format=json"
}
}
```
Our secure server executes this `op` command using the 1Password Service Account, which has been granted permission to manage items in the specific user's vault. This method is far more reliable and secure than trying to use the API for item creation directly, in our experience.
**Key Takeaways & Pitfalls:**
* The 1Password SCIM API is robust for user management, but for manipulating items within vaults, the CLI has been more dependable for us than the REST API.
* You **must** have a rock-solid, secure environment (like a locked-down cloud server or a private Make/Script) to run the CLI with service account credentials.
* Pre-creating and sharing vault items makes Day One incredibly smooth for new hires. They open 1Password and everything is already there, organized.
* We initially tried using Zapier for this, but hit rate limits and complexity walls with the nested logic. Make's flexibility was essential.
This did require some upfront investment to build, but the payoff in saved IT tickets, eliminated manual entry errors, and improved security posture has been massive. I'm happy to dive deeper into any part of this setup if folks are interested.
api first
api first
Thirty accounts in an hour is tidy. But the "hour of total hands-on time" disclaimer is doing a lot of work. That's just your Make scenario runtime, isn't it? What about the week someone spent building and debugging the API calls before the big day? Or the ongoing maintenance when GitHub changes their auth schema?
—EB
You're absolutely right to highlight the up-front investment. The initial build and the ongoing maintenance are the real costs, and they often get buried in these kinds of posts. That "hour" metric is only meaningful if you amortize it over hundreds of future hires and factor in the risk reduction from eliminating manual errors.
Our team made a similar calculus. We found the break-even point came after onboarding about 75 employees. After that, the marginal cost per new hire is nearly zero, and the consistency in provisioning is invaluable for security audits. The maintenance overhead is real, but it's less than the weekly ticket queue we used to handle for access issues.
The bigger challenge, in my experience, isn't the API glue, but the governance around it. Defining and maintaining the ruleset for who gets access to what based on department, location, and role is a continuous policy effort that sits behind this automation.
Nice! The immediate storage is key. Did you set up specific vault permissions for each department? We tried something similar and ran into issues where new hires could see shared items they shouldn't have until we fine-tuned the groups.
Also, how are you handling the initial 1Password account invite and master password setup for those 30 people? That was our final manual step.
Let's build better workflows.
Storing credentials immediately is crucial for security, but it does depend on the API reliability of each downstream service. A point to consider is what happens if the GitHub account creation fails after the Google password has already been generated and stored. Do you have a compensating transaction to clean up the partially created accounts and stored items? This can create orphaned credentials if not handled.
On your question about initial setup, we solved the manual invite step by using the 1Password CLI within the Make scenario. After SCIM creates the user, we have a step that uses `op user provision` to send the invite directly. The new hire still sets their own master password, but the invitation is automated.
prove it with data