Launch HN: AccessOwl (YC S22) – Automating SaaS Provisioning and Permissioning

Hey HN, we are Mathias and Philip, co-founders of AccessOwl (https://www.accessowl.io/). AccessOwl automates your employees' access to SaaS products. We give you a simple way to provision and deprovision any SaaS tool, as well as to configure permission levels. See a demo here: https://www.accessowl.io/productdemo.

Most of us use SaaS tools for work day-in and day-out. How do we get access to those tools? For the most part, through a colleague or IT admin who creates all accounts and sets permissions manually.

Here’s what it usually looks like for the unfortunate admin: (1) receive a request for a new tool via email, Slack, JIRA or face-to-face. Since you are busy with something else, you write a todo for later; (2) you log in to the tool and realize that the permission that was requested is way too high so you check in with the requestor’s manager; (3) you finally set up the account and document user, tool and permission in a Gsheet/Notion/Airtable.

This quickly becomes a 30m task for a simple access request! This is still the best practice for most people and it sadly also was for us. We were both founders before and experienced the same tedious process in different flavors at our own startups and other companies.

At some point we migrated to Okta and partially automated our provisioning and deprovisioning (permissioning, however, stayed painfully manual). Why only partially automated? Because Okta utilizes the SCIM API which was either not available in our tool stack or required an expensive upgrade to enterprise-subscription (thanks to the “sso tax”: https://news.ycombinator.com/item?id=31175300). And yet, we still missed simple things such as approval steps, a straightforward way to request access, and access reviews.

We talked to hundreds of organizations and saw the same manual processes and self-built scripts everywhere. The pain often starts at growing companies with around 50 employees. At this stage the CTO usually gets fed up with manually (de)provisioning and documenting it in a Gsheet. Another widespread cause of headache are IT security certifications (e.g. SOC2, ISO27001,...), requiring to know which employee has access to what tool, regular access reviews, and timely offboardings.

It seemed crazy that in a world where SaaS has become the norm, there was no great way to manage something as seemingly “trivial”, but also as critical, as user accounts. The core issues are, as always, missing integrations. Despite SCIM being the standard for over a decade, not all applications are utilizing it. Worse, many vendors lock it up in their enterprise plan.

This brought us to our core design principle: AccessOwl has to work with every tool, no matter what integrations are available. We generalize all the available ways of integrations in a single, simple interface. We take care of all the grunt work needed to coax each SaaS tool into doing the right thing. Whether it’s calling public APIs or resorting to Plaid-style automations as a last resort. Our first iteration was a simple workflow in Slack (Request -> Approve -> Manual provision). It covered all access documentation and solved back-and-forth communication between stakeholders. Since then, we have been adding more and more integrations to SaaS tools to directly (de)provision without the use of SCIM APIs. Taking a similar approach to provisioning as “Plaid” did in banking. We’re already covering 100+ tools and counting.

So what does a typical workflow look like?!

Step 1: Request an access, onboarding or offboarding. For this we piggy-back on whatever messaging tool is used in your org (we are starting with Slack, Teams will follow). It’s as simple as clicking a button to get your request started (no more manual JIRA tickets!) and always gets forwarded to the right stakeholders.

Step 2: Provisioning and permissioning. In the most basic workflow the tool owner receives the approved request with all the information to manually provision the account. If and when you arrive at the point where manual provisioning becomes a pain, you can let us automate it for you. The requestor will automatically get process updates and the access will be audit-ready logged in the background.

Prices start at $2.5 per employee per month and we charge a fixed premium for the automation of (de)provisioning based on the total number of employees.

We are excited for the opportunity to share AccessOwl with you! We would be more than excited to hear your thoughts and feedback and your own experiences with SaaS access management!

That's very good and any ISO 270001 certified small-medium company would need that. But it would be better to have stand alone web interface and not only relay on Slack.

Funnily we started with a pure web interface. But after testing it with a bunch of orgs we quickly noticed that some people have issues finding the URL where to request accesses or when they found it to finally sign in. So we came up with the idea of bringing it to Slack: Cool thing is that the user is already logged in and can just interact with AccessOwl. We can easily keep him up2date about his/her access request.

However, I agree we shouldn't solely rely on Slack as orgs without Slack just can't use us at the moment. That's a good point! We already provide an admin interface as web app for easier filtering, reporting etc.

Very relevant tool for this SOC2 compliant org. I have seen lot of general purpose automation tools pitch this but I think domain specific automation like this gives you much better value for money.

Unfortunately not at the moment. But this might come. Feel free to send something via https://www.accessowl.io/career and we'll reach out when this changes :-)