How we get new hires set up
A new starter's first day touches a surprising number of tools. They need a Google Workspace account, membership of the right groups and aliases, invites to the right Slack channels, and someone has to remember to file a first-week checklist. No single task is big. The trouble is that they are scattered across different systems, and whoever is doing the setup rarely owns all of them. A step slips, and your new colleague spends their first morning waiting for access they should already have.
Our answer is to start the setup from the moment that kicks everything off: a new record landing in our HR system. Here is how we run it on Machine, covering the connections, the steps and the limits, so you can build the same flow for your team.
The problem
Every familiar approach has a hole. A runbook only works if someone follows each line by hand, and it goes stale as your tools change. A no-code automation handles the one tidy case it was built for, but it cannot think about which groups a particular role needs. Give each system a different owner, and the new person's access trickles in bit by bit over their first few days.
We wanted a new hire's accounts, memberships and checklist ready as soon as their record appeared, with the steps you cannot take back held for a person to confirm.
What we built
A new record in the HR system wakes an agent on Machine. Each hire gets their own session: a fresh cloud computer (a sandbox) used only for them, with limited access to the three tools onboarding needs, Google Workspace, Slack and Linear. The agent reads the person's role, then prepares their account, their group and channel memberships, and a first-week checklist, and files it all. Before any account is created or any group is joined, it stops for approval.
How it works
Start from the HR record
Our HR system sends a signed webhook to the project. A new-hire record sets it off, and every time it fires Machine opens a fresh session on its own sandbox, loaded with the person's role, team and start date. Each hire gets their own session on a throwaway machine, and nothing is carried over from one run to the next.
Teach it how you onboard
Which groups go with which role, which channels each team joins and what a good first week looks like are all kept as skills and memory, a playbook loaded into every session. The agent follows it instead of guessing, and the playbook gets better as we refine how we onboard.
Connect only what onboarding touches
Connectors are scoped links to your tools. The keys stay on our servers, so no raw token ever reaches the model. Through them the agent can:
- Set up the Google Workspace account: the mailbox, the aliases and the groups that come with the role.
- Bring them into Slack: invite them to the channels their team uses.
- Create the checklist in Linear: a first-week onboarding project holding the tasks their role calls for.
Hold the steps that grant access
Creating an account and joining groups are what actually hand out access, so both pause at a human approval gate before anything is set up. One person checks the account and the memberships together in one place. Credentials are stored encrypted in the Secrets Manager and only handed to the agents you grant them to.
Have every new hire ready on arrival
Once this is running, a new-hire record lines up the mailbox, the group and channel memberships and the first-week checklist, then waits on a person for the parts that grant access. For a new engineer, that means a Workspace account, the right Slack channels and a Linear onboarding project, all waiting on their first day.
The pattern
Let the HR record start things with a trigger, give the agent scoped connectors to Google Workspace, Slack and Linear, write down how you onboard as skills and memory, and have a person approve every new account and group membership.
Guardrails
An agent that can create accounts and hand out access needs to earn trust. Here is how Machine keeps it in check:
- Isolation. Each new hire is handled in a private sandbox and on a branch of its own. The session can only reach the systems it is scoped to, and it can only send out what it has been explicitly allowed to.
- Scoped secrets. Every key is stored encrypted in the Secrets Manager, passed into the sandbox when the run starts, and only handed to the agents you grant it to.
- Human approval gate. No account is created and no group is joined until a person has approved it.
- Everything is code. The agent's persona, its skills and its permissions for each system are files in the repo, kept in version control. Changing them takes a reviewed change request, never a dashboard click.
The outcome
What used to be a scramble across a handful of tools is now a single setup you can review, ready the moment the record appears, with the access steps waiting for a person. Want it to cover another tool? Connect one more platform.
More use cases
How we answer GDPR data-subject requests before the deadline
Our Machine agent checks each GDPR access or deletion request, finds the person's data across our product database, builds the report well within the SLA and hands it to legal before anything is sent.
How we keep our docs matching what the code does
Once a day a Machine agent reads every commit merged since its last pass, finds the doc pages those changes made wrong, rewrites them and sends you one pull request to review.
How we test every pull request without lifting a finger
Our Machine QA agent works with GitHub and our test environment. For each pull request it checks out the branch, runs the tests, tries the change for real, and posts what it found.
Put your first agentto work today.
- SSO
- RBAC
- Governed agents
- Full audit trail