HR-driven IT provisioning
HR changes the record. Every app follows.
HR is the source of truth for who works here. Your directory follows HR. The 20 to 40 apps with no SCIM follow a ticket, days later.
What the rest of the stack cannot reach.
StitchOps takes the event your HR system or directory already emits and completes the provisioning inside the closed apps, on a worker VM in your environment, with evidence back to the ticket.
Trigger from HR or the directory
A new hire, a transfer, or a termination in your HRIS flows to Okta, Entra ID, or JumpCloud. That event triggers the StitchOps workflow.
Provision the closed apps
Vendor portals, thick clients, and on-prem systems get the account, the role, and the group the way an admin would set them.
Day-one access, same day
The workflow runs when the record changes, not when the ticket reaches the top of the queue.
Evidence back to the ticket
Step-level status and evidence references attach to the ticket or audit log so the change is reviewable.
How it works with your stack.
Step 1
HR changes the record
Your HRIS updates the worker. Your directory picks it up as it does today.
Step 2
The directory fires the event
A webhook, a scheduled query, or your IGA tool calls the StitchOps workflow with the worker as a typed input.
Step 3
StitchOps provisions the closed apps
The agent on your worker VM logs in with a vaulted credential and makes the change, step by step, with confirmation gates where you set them.
Step 4
Evidence returns
Status, timing, and evidence references go back to the ticket and the audit log.
How it runs
Described once. Replayed every time.
Tell Stitch the task, review the typed steps, and save it. The agent runs it on a worker VM in your environment with a vaulted credential, and logs every step.
See the platform →What you can finally automate.
Create the new hire in the vendor portals SCIM does not cover, with the right role
Move a transferred worker between roles in the thick client the team uses
Remove a leaver from every closed app the day the HR record changes
Verify day-one access was actually granted and capture the evidence
Governance
Ask for it in plain language.
Claude, ChatGPT or Copilot can run these from your existing assistant. The model picks from typed tools; the agent owns the credentials and stops for confirmation on anything destructive.
Connect your assistant →I found a saved workflow for this. Running it on worker-01.
tool call
workflow_offboard_closed_apps
{ "email": "j.doe@example.com" }
Confirmation required
Step 5 deactivates the user in vendor-portal. This cannot be undone by the workflow.
completed in 5.2s
3 portals · 6 steps · evidence: step_05.png, step_11.png, step_17.png
Done. The user is removed from all three portals. Evidence is attached to run_01j8k.
When the app wants an upgrade first
HR driven provisioning often reaches an app that sells SCIM only on a higher plan. The SCIM tax calculator shows what those upgrades cost across your stack, and the SCIM tax explains the pattern.
Start with one workflow that never had an API.
Fifteen minutes on your top three manual processes. We tell you which one to run first.