Zelt tells you the day a new hire starts and the day someone's last day lands. It can even hand that joiner their Google Workspace account and a few core-app logins on the first morning. What it will not do is create accounts for every tool that an employee needs, or revoke all access on the last day. That part still falls to whoever owns IT working through admin consoles one account at a time.
Zelt does more natively than most HR tools. Its Access Management module provisions apps directly, and for the apps it supports it works well. The limit is the catalog. Zelt only publicly mentions about a dozen tools with no connector list available. The rest of your stack still gets set up and revoked by hand. To automate across all your stack, you can layer a tool like AccessOwl, which provisions to 400+ apps.
In this blog:
SaaS provisioning with Zelt's Access Management module
Automating provisioning further with Zelt and AccessOwl
Managing SaaS accounts with Zelt + DIY automation (scripts, API connectors, spreadsheets)
Method 1 - SaaS provisioning with Zelt's Access Management module
Zelt HR
Zelt HR is the system of record for who works at the company. It centralises employee data and runs the people workflows around a hire: custom onboarding flows, time off, documents and e-signatures, reviews, and even payroll, with approvals and audit trails on top.
Automating SaaS onboarding and offboarding with Zelt's Access Management
Zelt's Access Management module goes further than a checklist. It provisions and deprovisions a set of apps directly. Zelt calls itself a "direct integration partner" of the apps it supports, so it connects to each one through its own integration rather than through SCIM or a separate IdP.
That is worth crediting. For the apps it covers, there is no SSO tax to pay and no SCIM connector to stand up in Okta or Entra. Zelt also creates the Google Workspace account on day one and removes it when someone leaves.
The apps it names publicly are the popular core: Slack, HubSpot, Notion, Monday, Intercom, Zoom, GitHub, LastPass, Pipedrive, DocuSign, Xero, and Google Workspace.
What Zelt's Access Management can do
Template access by role and team.
Provision a catalog app automatically when someone joins, through a direct connector, with no SCIM to configure.
Create the Google Workspace account and assign licenses, then remove access on offboarding.
Remove the catalog apps it manages when someone leaves.
Zelt Access Management limitations
The limitation you will run into with Zelt's Access Management is coverage width.
The catalog is small. Zelt names about a dozen popular apps but publishes no full catalog or count.
The Core tier caps it early. On Zelt's Core plan you can connect up to five apps; going beyond that moves you to the Pro plan.
Past the catalog, you are back to manual. There is no SCIM, so any app Zelt does not directly integrate with is an account someone still creates and deletes by hand.
Permissions are coarse. In practice you get admin or standard-employee access, and users report you cannot set finer, segmented permissions per team or per person.
It does not surface Shadow IT. Apps bought outside IT never show up, and those are the accounts that stay open when someone leaves.
For a team with a wide varied SaaS stack this becomes a blocker. From conversations with our customers, teams reach for a tool that can automate the provisioning of SaaS apps when they are rapidly growing, offboarding security/compliance becomes more important, or when it becomes too time consuming for managers to create app accounts by hand.
What that means for you
Under about 30 people with a handful of core apps, Zelt's Access Management covers the bulk of provisioning, and it does it well. Past about 60 employees, in our experience, the uncovered long tail starts to drift.
Some access runs through Zelt, the rest runs through managers and admins, and HR and IT fall out of sync. You usually find the gap at the worst moment: when someone has left and still has access to a tool Zelt was never connected to.
Why teams layer a dedicated SaaS access management tool on top of their HRIS
What most teams do not weigh before buying is the size of that catalog against the size of their stack. A tool that automates a dozen core apps leaves the rest to be created and killed by hand, and the rest is usually most of a growing company's tools.
Khalifah Alsadah, a product manager at Sary, a B2B marketplace that scaled past 600 employees, saw what that gap looks like (how Sary handles access):
"In one instance I found out that a former employee was still using a critical internal system 3 months after he left."
Khalifah Alsadah, Product Manager, Sary
AccessOwl provisions 400+ apps and publishes its full integrations list, so you can check your stack against it before you commit.
Method 2 - Automating SaaS Provisioning with Zelt + AccessOwl
AccessOwl layers on top of Zelt to handle access management for SaaS onboarding, offboarding, and access controls.
The stack most teams actually want is straightforward: your HRIS (here Zelt), your IdP (Google Workspace or Microsoft 365), and your third-party apps all stay in sync. Access should follow templates rather than someone setting up each new hire by hand. Who has access to what, along with requests, approvals, and removals, should be logged instead of scattered across tickets and spreadsheets.
AccessOwl is the layer that does that:
A start or end date in Zelt triggers the whole workflow.
Access templates are matched to HR attributes (role, team, department, entity) and can be tweaked per person.
Requests and approvals happen in Slack or the dashboard, and employees can self-serve.
Onboarding drops to minutes, and offboarding can be one click or fully hands-off.
Every action is logged as it happens, so access reviews become evidence you already have.
You get one place to see who has access to what, including apps outside SSO or SCIM.
Shadow IT that your HRIS and IdP never see gets surfaced.
What onboarding and offboarding looks like with Zelt + AccessOwl
Onboarding, start to finish:
Zelt says a product manager starts Monday.
AccessOwl loads the access template for the role: Notion and the product Slack channels, plus Figma, Linear, and Amplitude.
The relevant managers approve the sensitive a[[s with one click in Slack.
AccessOwl provisions each app through its own integration, so no one opens an admin console, and every action is logged.
Offboarding runs the same way in reverse. On the termination date in Zelt, AccessOwl removes the person's licenses across their apps and reassigns their owned assets to their manager. It also runs a Shadow IT scan that catches apps your IT team may not have known about, including free accounts and username-and-password logins outside SSO.
Leftover access is where breaches start. Even if ex-employees are benevolent, accounts that nobody is monitoring is a common entry point for data breaches. IBM put the global average cost of a data breach at $4.99 million in its 2026 report (IBM Cost of a Data Breach).
What access review compliance looks like with Zelt + AccessOwl
Because every grant, approval, and removal is logged, an access review for ISO 27001 or SOC 2 becomes a report you pull, not a spreadsheet you build. Instead of exporting a user list from each app, screenshotting the ones with no export, and pasting it all together, you have one record of who has access and how they got it. In practice that takes a review from about 2 hours per app down to about 10 minutes per app (detailed guide to SOC 2 access reviews).
Robert Pötzsch, office manager at FinCompare, a 50-person fintech, had offboarding that "could take up to several hours per employee." With AccessOwl it became "a single click and every stakeholder gets the information they need."
How AccessOwl is different from Zelt's Access Management
The core difference is coverage. Zelt provisions a small, unpublished set of core apps; AccessOwl provisions across 400+ apps, including the long tail that does not offer SCIM or hides it behind an enterprise plan. There is no catalog you have to be inside of, and the list is public.
Motion, one of our customers, moved to AccessOwl because it could provision accounts without upgrading each app to its enterprise tier, where other tools it had looked at worked only through SCIM or SAML (Motion's story).
It also surfaces Shadow IT today rather than as a roadmap item, works at the permission level rather than only creating or deleting an account, and lets you tailor a template per person.
AccessOwl is not an IdP. It does not handle logins, passwords, or multi-factor authentication, and it does not manage devices. It sits on top of your Google Workspace, Microsoft 365, or Okta and automates the access lifecycle, and each app takes an initial integration setup.
How AccessOwl integrates with Zelt (and Google Workspace or Microsoft 365)
Zelt stays your source of truth for joiners and leavers. AccessOwl reads those start and end dates and works alongside your existing Google Workspace or Microsoft 365, and Okta too if you run it, rather than replacing any of them. AccessOwl has native integrations with Google Workspace, Microsoft 365, and Okta.
Who this is best for
AccessOwl plus Zelt fits a growing team, roughly 30 people and up, running Zelt with a mix of SaaS apps beyond the core set Zelt provisions. You may have a small IT team owning provisioning, or this might sit with a non-technical operations person.
Method 3 - Managing SaaS accounts with Zelt + DIY automation
Another route teams on Zelt can take is to layer DIY automation on top. If you have technical people, they might own it: tickets in Jira or Linear, spreadsheets, Zapier or Make on Zelt events, or scripts against Zelt's API. Microsoft shops often lean on PowerShell, Google shops on GAM (Google Apps Manager), wiring the APIs themselves.
To be fair, under roughly 30 people or 5 apps, with someone technical who owns it, this is genuinely workable.
Where it breaks as you grow:
No audit trail when a review comes around.
Missed offboarding, the scary one, when a script does not cover an app.
Shadow IT stays invisible.
Brittle maintenance every time an app changes its API.
No approvals and no self-serve.
Key-person risk when the one person who understood the scripts leaves.
Which method is right for you?
Zelt native only | Zelt + AccessOwl | |
|---|---|---|
Under 30 people, mostly core apps | Covers most of your stack; usually enough | Usually too early, unless you are scaling fast |
~50 people, a growing mix of apps | Core apps automated; the rest drifts to manual | Onboards and offboards across the whole stack, no SCIM required |
100+ people | The uncovered tail turns into a compliance risk | Full automation and audit evidence for access controls |
FAQs
Does Zelt offer features to automate provisioning of SaaS apps to automate onboarding and offboarding?
Yes, to a point. Zelt's Access Management module provisions a set of popular apps directly, without SCIM, and handles the Google Workspace account. But its catalog is a small, unpublished core set, so apps outside it stay manual. To automate the rest of your stack, you layer a tool like AccessOwl, which covers 400+ apps and reads Zelt's joiner and leaver events.
If I'm using Zelt, why use AccessOwl over Okta?
Okta Workforce Identity Cloud is the right call for some teams: large or regulated companies with a dedicated identity team and a multi-IdP setup get real value from its depth. For a growing company on Zelt, it is usually more platform than you need, and it carries the SSO tax, where each app moves to an enterprise tier just to connect. If you already run Okta, AccessOwl layers on top and adds app coverage and lifecycle automation without ripping anything out. If you have not rolled out Okta, AccessOwl gives you the onboarding, offboarding, and access control you were after for a fraction of the cost, live in days rather than a months-long rollout.
Can I automate SaaS provisioning on top of Zelt without setting up SCIM for every app?
Yes, and that is the point of a tool like AccessOwl. Zelt already provisions its own catalog without SCIM via direct integration; AccessOwl extends coverage to 400+ apps without SCIM using a different approach (browser RPA).
Our team uses Zelt, how do I make sure all app access is revoked when an employee leaves?
Zelt removes access to the apps it is connected to, like a Google Workspace account. The gap is everything outside their connector catalog. AccessOwl uses the termination date in Zelt to remove licenses across every connected app, reassigns owned assets to the manager, and runs a Shadow IT scan to surface accounts your HR tool never saw.
Does Zelt integrate with Google Workspace or Microsoft 365 for provisioning?
Zelt creates and removes the Google Workspace account natively and can assign licenses. Beyond that directory account, your provisioning reach equals Zelt's app catalog. Google's own admin documentation notes automated provisioning reaches a set number of apps by edition, from 3 on Business Starter up to 100 on Standard and above (About automated user provisioning). AccessOwl extends provisioning past that line, across 400+ integrations.
What access management features does Zelt's module offer?
Zelt's Access Management module provisions a catalog of popular apps through direct integrations, with no SCIM to configure. It templates access by role and team, creates and removes the Google Workspace account, and removes the catalog apps it manages when someone leaves. It does not surface Shadow IT, and its permissions are role-level rather than attribute-based per person.
What are the best tools that integrate with Zelt to provision accounts automatically for onboarding and offboarding?
The category to look at is identity governance and lifecycle automation that reads Zelt as the HR source of truth. AccessOwl is built for this: it turns Zelt's start and end dates into action across 400+ apps, including tools outside SSO and SCIM, and logs every change for access reviews.