AccessOwl

Simplify access onboarding
Request accesses on-demand
Clean reporting and export
No forgotten accesses anymore

Inspiration

Personal experience with painful user on and offboarding

Mathias & Philip experienced in their previous startups how painful the on- and offboarding processes are: when new people join, they need specific tools depending on their role; when they leave the company, no accesses must be forgotten.

Especially with regulated companies, there are requirements for a proper access management: you need to be able to report who has access to which application - at any time.

Moreover when people requests tools on-demand, there is often an approval process to keep control over licenses and/or data. Sometimes more than one person is involved.

What it does

We built an access management solution for small and medium-sized companies in Slack. We get all the user information from Slack itself. The admin just needs to add request-able applications.

Onboarding

A HR person can trigger a tool onboarding of a new hire - even before that user is in Slack. He/She sets the manager of that person. As the manager usually knows which tools are needed, he/she gets a Slack message and is asked to define the necessary applications for the new person.

Afterwards AccessOwl orchestrates that the right application owners are asked to setup the necessary application accesses.

When the user joins all the accesses are ready :-)

Request access on-demand

Imagine somebody changes the team or starts a new project and need some tools. Now he/she can just request tool access out of Slack by himself/herself:

Use a global shortcut or click on a button on the AccessOwl home tab.
Choose your application.
Choose role/permission, state a reason and submit!

The manager gets an approval request via Slack message and can approve/deny by push on a button. Or talk to the requestee.

Afterwards AccessOwl orchestrates that the right application owners are asked to setup the necessary application accesses.

The user is kept up to date via Slack message in between.

Offboarding

It’s sad but sometimes people leave the company. It’s important that no given access is left behind. The leaver must not have any access anymore.

From the AccessOwl home tab user can be offboarded. After choosing the user, we immediately notify the application owners in charge without telling the user.

The cool thing is that we can even trigger an offboarding automatically when a user was deleted from Slack. As usually no admin forgets to remove Slack users as it’s visible for everyone, this way we ensure no offboarding slides through. 💡

Reporting

In our web interface we provide an easy way to ask questions like:

What are the current accesses of Bob?
Who currently has access to Asana?
Who ever had access to Asana?
Who approved accesses of Bob and why?

Sign in with Slack makes it easy for admins to login without the need to register a separate account. All the reports can be easily exported as CSV file.

How we built it

We spoke to dozens of companies and many experts to get their point of view and insights about their process. Quickly we understood that there is a need in that area and got our proof of concepts partners willing to regularly talk to us.

After several interviews we got a picture how a potential solution could look like and built some mockups. We discussed them with our partners and got feedback which we integrated. Then we started building an MVP as Slack app.

A Slack app has the big advantage that we are as close as possible to the end user. He/She does not need to login or remember a specific URL but can just start by a push on a button.

We stayed in continuous contact with our partners via Slack Connect. We didn’t need to wait for a regular weekly meeting but could ask little things in between. Keeping a steady feedback loop was definitely helpful to build the right product.

Challenges we ran into

Companies don’t know how many apps they have (Shadow IT). Data imports are therefore difficult
Some slack app functions not made for large datasets (e.g. limited drop downs, limited fields)
Need to build a web-app for more granular settings

Slack Limitations

We noticed quickly there are many limitations in the UI of Slack (Block Kit).

We stumbled upon limitations of input block elements with checkboxes/radio_buttons : only 10 options are allowed. We use them to give the user the choice between different roles/permissions when requesting an access. This is sometimes not enough.

Furthermore there is a maximum of 100 options for static_select block elements. We use it to show requestable applications. But the average company has 110 applications according to a report of Bettercloud.

When we onboard a new user the HR person (who usually triggers that process) needs to set the manager of that new user. Unfortunately Slack does not allow defining what kind of users are shown in the users_select block element. It does not make sense to set another Slack App or Slackbot as a manager.

Moreover the length limitations (75 characters) for text and description of option objects are sometimes tough when you need to describe an application or role/permission.

We understand that there is often limited space. Especially when the UI works on Desktop, Web and Mobile. But we’d like to have more freedom to solve user problems.

Shadow IT

Interestingly some companies don’t know which applications and tools they are using. It’s called “Shadow IT”. As we need to know which applications a company has, so that we can show them when somebody requests an access. Therefore we noticed that we need to find a way to add applications in the request process itself. Imagine somebody wants to request a tool access to a tool but can’t find it in the dropdown. We believe people must be always able to request a tool even if it’s not known to the company yet.

Reporting Web Interface

We thought first we can put everything into a Slack app. But the our partners wanted to have a filterable, searchable and sortable reporting to ask questions like:

What are the current accesses of Bob?
Who currently has access to Asana?
Who ever had access to Asana?
Who approved accesses of Bob and why?

And for sure there needs to be an export. There are too many limitations in Slack to fulfil these requirements. At least we integrated Sign in with Slack so that users don’t need to register separately. Now can connect the best things of two worlds: Slack and Web.

Accomplishments that we're proud of

Product Hunt 5th place
Multiple Slack workspaces that have installed it & interest in paying for the app

After we build a first MVP version which adds enough for the customer, we launched on Product Hunt and became #5 Product of the Day. That convinced us that we’re on the right track. Moreover we got more people installing our app into their Slack workspace. That’s how we got more feedback and even some interesting in paying for our little 🦉.

What we learned

User onboarding must be very easy
There is often no single-source-of-truth in regards to app & account data

There are some technical limitations of the Slack platform which might be a showstopper later for potential customers. Sooner or later we need to find workarounds which might make the interface more complex.

The admin user onboarding must be as easy as possible. The install into the Slack workspace is smooth. But then the admin needs to setup all the applications they are using - with details like which roles/permissions exist in that application. We improved that process by providing a list of application template: admin selects a template and all the necessary fields are prepopulated.

But there is more. What about all the accesses of existing (already onboarded) users? In the end the admin wants to have a single source of truth for access management. So we need to find a way to import existing permissions.

What's next for AccessOwl

Signing first customers
Creating a company
Investment

We heard a lot about automated provisioning in our interviews. The main problem for smaller and medium-sized companies is that their SaaS tools don’t provide necessary APIs for it as they don’t pay for the highest subscription. So we think about how we can provide a solution here.

There are also requests from prospects for a more sophisticated approval system. Currently only the manager can approve for a requested access. Some people want to involve application owners too as they usually manage the budget it.

Finally as we received much great feedback we’re looking forward to our first paying customers. So it’s time to create a little company out of it. Maybe even look for some investment to continue developing our Slack app and grow.