Why we split the management of Admin Users and End Users
Tags: strapi, webdev, javascript, node
Published: 2019-07-16 13:31:58

---
title: Why we split the management of Admin Users and End Users
published: true
description: 
tags: strapi, web development, javascript, node
---

Recently, we merged a pivotal change to how we treat **Admin Users** and **End Users**. This post will describe what we did, why we did it and how it affects you as you continue to develop your projects going forward with Strapi. 

With the <a href="https://blog.strapi.io/strapi-beta-is-out/" target="_blank">release of the Beta Version of Strapi</a>, **Admin Users** (also called **Administrators**) and **Users** (called **Users** or **End Users**) are separated. **Admin Users** primarily interact with the Strapi dashboard. **End Users** primarily consume the API or access the front-end. 

We made this split to maintain a separation of concerns going forward. Both **Admin Users** and **End Users** fulfill a different set of features:

For example, **Admin Users** concern themselves with **content contribution** (creating and editing content, moderating, translation, publication, A/B testing, previewing content prior to release, etc.), **Strapi Administration** (API tokens, webhooks, API testing and status checks, logging/monitoring, statistics, etc.) and a last example, **third party providers** ([OAuth](https://oauth.net/), [LDAP](https://ldap.com/), SAML). 

These **Admin User** features are distinct and separate from the features available for the **End User**. 

The features for the **End User** revolve around an authentication and authorization layer that you can build your business logic on top of. Similar to the features we are developing for the **Admin User**, we have goals we want to achieve with the `users-permissions` plugin. For example, providing a fully featured authentication and authorization service with [OAuth2](https://oauth.net/2/) and [OpenID Connect](https://openid.net/connect/), providing an advanced Role and Permissions system, custom policies, managing 3rd party connectors like Facebook and Google.

Of note, by separating the **Admin User** and **End User**, we have made it possible to create a logical integration where **Admin Users** become **End Users**. This also applies where an **End User** becomes an **Admin User**. Granular control will now be possible. 

The separation of the **Admin User** and **End User** occurs at the database level and the UI level. **Admin Users** now occupy an administration panel located under, “**Manage the administrators**”, found under the **username**.

![](https://thepracticaldev.s3.amazonaws.com/i/wp7li8tb4pcddmketo1x.png)

**End Users** are still found as a unique Content Type in the left-hand menu, under **Users**.

![](https://thepracticaldev.s3.amazonaws.com/i/3qf0oc6olstg0tpwfqmj.png)

Aside, from a UI level change, the most fundamental change Strapi developers will confront is the need to create an additional **End User**. For example, if a blog or similar project is being developed that has a need to display the **Admin User** an “author”, a “profile name”, etc. 

Simply put, an **Admin User** can access the Strapi dashboard.  An **Admin User** may create content types, add content, manage API access, install plugins, etc. 

An **End User** can only consume the API. This may include adding content but through the GET/POST methods in a form - not the Strapi dashboard. For example, for an ecommerce account, to leave a comment/review, to be the author of an article or otherwise have a profile. 

---

But what about other blogging platforms? Those that do not separate the Admin Users from the End Users. This is a good point, but these platforms have been primarily developed around displaying website content and blogging. In that context, it might make more sense to keep both **Admin Users** and **End Users** in one database table. Strapi is much more than another alternative for solving blogging needs, we also include that as a capability, but Strapi is designed to do much more with content and APIs.

We made this change to how we handled **Admin Users** and **End Users** as an investment in the long-term [roadmap](https://portal.productboard.com/strapi/1-public-roadmap/tabs/2-under-consideration) of the Strapi project. A quick glance at the roadmap shows an even shorter-term step with the **Administrators Roles & Permissions** feature and then later, other features that are made cleaner in their implementation.  

We felt that providing more granularity and control was worth the trade-off of extra complexity on our side but providing greater flexibility and features for our users. The approach of separating the **Admin Users** from the **End Users** allows for other features. Aside from upcoming features, by separating them, performance isn't affected due to, for example, the database structure.


In summary, separating **Admin Users** and **End Users** in the UI and database opens the door for providing features and functionality sought after by Strapi users. Their separation also avoids performance and database issues down the road.

Strapi is a 360° headless CMS. We are front-end agnostic as a headless CMS should be, but we are also database agnostic, allowing for a practically infinite set-up, configuration, and use. By being agnostic in this way, we are able to fulfill our mission to reinvent the way content is written and distributed to people. Separating the **Admin User** from the **End User** is just one step towards fulfilling the promise of a headless CMS.

*Article written by your [David](https://twitter.com/kai_dawei) in collaboration with [Alexandre](https://github.com/alexandrebodin).*