I am in a workspace with multiple admins. I want to make make myself the main admin, to have a space to work in with some others. However, when I tried it I noticed that I can’t make myself the main admin.
And I also can’t remove the other admins from access, because then it says that there should be at least one admin.
So, I guess this is a bug! 
I’m a little confused about what you’re trying to achieve, since you’ve talked about workspace and space.
Admin is a user role at the workspace level, and every workspace admin has ‘architect’ privileges in every space.
Workspace members (non-admins) can be granted architect access to a space.
There is a requirement for at least one admin in the workspace, but there is no such thing as the ‘main admin’.
It is possible that an admin can have his/her database access removed in a given space, but to do so requires that there exists at least one other user (admin or member) who is an architect in that space and has database access.
I already feared that may message may be confusing. With ‘main admin’ I mean the admin that has access to that particular Space.
If I want to accomplish that (and I am that admin), I want to:
If I start with 1, it warns me that there should at least be one admin & it doesn’t allow me to remove them.
If I start with 2, I type my username but I do not appear among the options. Only other users appear.
As a workaround, I assign another admin, they then remove the other admins, and then they assign me as admin and then they can remove themselves as admin from that space.
I hope that it’s clear now 
Just to reiterate, there is no such thing as an admin for a space.
For your step 1, are you trying to convert existing users from admin to member? Or are you talking about removing access within a single space?
Within a single space. Setting yourself as the only architect, and removing the other admins as architects. We found this bug together on a call.
I’ll add that it’s probably not a bug per se, but a flow that doesn’t work within the confines of the design.
The problem is that you can not configure your own access within a space.
But if you want to set yourself as the only almighty architect and remove database viewing rights from all other admins, it’s impossible.
Indeed, it’s not possible to remove architect rights from admins, but it is possible to remove their access to the data in the space.
This isn’t a bug, this is how it is designed to work.
What is the overall use case you are trying to achieve?
Correct, as an admin, you can’t remove access capabilities from yourself (!)
Thanks for the reply Chris, I appreciate it. However I understand that. I will go to my office in a bit and I will make a gif/video of the problem when I’m there.
Sorry, this is what I meant.
Is there a proper terminology/role for this? Space Architect without Database Access?
I want to be the only admin with Space Architect AND Database Access, and set the other admins to be Space Architect WITHOUT Database Access.
This is impossible right now. This is the use case.
(I can, however, Set someone else to be Space Architect AND Database Access, then remove all admins (myself included) from having Database Access.)
Have you considered demoting the other users from admin to member, and then giving them architect rights (with no data access) in the space(s) they need?
We’ve been trying to make it so that a workspace generally needs as few admins as possible.
I’m a bit confused. Wasn’t there so much work done to allow for the “Hide data from Admins” feature? Why was this done if the solution to this problem is to demote admins to members?
Isn’t this use case the main purpose of that feature? I, as the system architect, need access to everything, and I want to remove the other admins from having access to all the data.
In this particular case, we want to keep admins as admins so that they can create their own spaces for whatever they need. But it may be for billing purposes in other cases.
But also, we’re not trying to get help on this, but are reporting this as a bug/issue. We ended up just sharing it with one person, then that one person shares it with the other. It works. But its weird behaviour/an issue to this newly released feature.
There has been a raft of features developed with the intention that they cover most use cases. We have been working on making it possible for members to do as much as possible without help from an admin, but at the same time recognising that admins are still needed. Allowing an admin to exist without that person seeing sensitive data is a valid use case that we have addressed.
It obviously makes sense that someone who needs to take care of billing is an admin, but I would not advise making people admins just so that they can create a space now and again. Better to have an admin create a space, grant a member architect permissions, and if necessary, that architect (or the admin) can choose to remove the admins’ data access.
You want to be able to disable all other admins’ access to the data, whilst keeping your access intact, right?
If so, then you’re right that it’s not possible without another admin’s help.
I don’t think we would call this a bug, per se, since it is working exactly as designed. But I suppose, it is unnecessary friction.
I’ve modifying the topic title to reflect what I think is more correct. LMK if I’m wrong.
Yes! Exactly :)) Glad we’re on the same page.
I do think this is a pretty big gap in design though. It’s not only about being the ONLY admin with access, but it is about being able to grant yourself access to a space.
In your example:
The admin can remove the data access, but then it is removed for themselves as well. They can’t set up a case (alone) where only they + one member have architect (with data) access to the space.
I’m confused again. We would never allow people to grant themselves access to a space (that they don’t already have) 
I guess you mean that it is not possible to for an admin to restore data access for only themself if data access has been removed for admins in general.
(or, another way, it is not possible for an admin to remove data access for a subset of the admin group)
Agreed. But I don’t see this as a bug. This is the intention. An admin creates a space as a sandbox for another member (non-admin). It is then up to the member to decide who is allowed to see the data in their sandbox. They can remove access for admins, in general, and then share with one specific admin.
One use case where I can see a gap is that it is not currently possible for an admin to create such a sandbox space for themself (= a space in which he/she is the only user that can see the data) if there are other admins in the workspace, without asking one of those admins for help.
Not exactly, I mean this: (I think a video will explain things better) https://youtu.be/6CR_jOuzjiM
At the point you have Architect with Data access (because you are an admin), you should be able to grant yourself Architect with Data access (to your user entity). But currently you can not. I guess this is due to the rule that “You can’t change your own access”. I find it weird that as an architect you can edit other people’s access, but not your own.
I agree with you that it is not per se a bug. I do think that this design over complicates a process which should otherwise be simple. And one which, I think, would be quite common with this new feature.
I just wanted to make the video (finally sitting down in the office after some meetings), thanks for making it! I think that makes our question clear! 
Here is the transcript of your video
This is the biggest issue. So where I can add other people such as different user as an architect with rights and then remove and then they still have architect with rights. I cannot add myself. If you see the users, this is me. This is you. Ron makes systems. If I go back to access, I search for Ron makes I it doesn’t show up but a different user can see me. So in this case I can see Ron make systems and add this person as an architect. The problem is that I cannot give myself access as an architect doesn’t show here. I cannot give myself access as an architect and then afterwards remove this. Now I can because this person is an architect. Now this person this is what we did. this person can go in add this person as an architect. Okay. And then we can uh remove this here. Now I have access with this person. And now I can also remove this person. And now I’m the only one with architect. Right? But you see how many steps we had to take just to give myself an admin with architect and uh the rest with no extended rights.
So the thing is yes this is a case where I am the only admin that has database access but the underlying issue is the fact that I cannot select myself to give myself access uh as an architect with database rights in order to then afterwards remove uh the access from admins. Hope that makes sense
So to clarify, you say that you (Ron Makes Systems) cannot give yourself Architect rights. But since you are an Admin, you already have Architect rights!
Maybe it’s a terminology thing. An Architect is someone who can configure the space/databases. They may or may not have data access. So, for the avoidance of ambiguity, I am going to refer to these as Architect+ and Architect-
This sentence does not make sense. You are asking why an Admin (with Architect+ access via the admin group) cannot grant Architect+ to themself. A simple answer is they can’t because they already are Architect+ (!)
But yes, it is also the case that
Correct, not directly, no. But an Admin can reduce access for all members of the Admin group, themself included.
I think what you mean is that Admins can’t downgrade the rights of the rest of the admin group (from Architect+ to Architect-) whilst leaving their own access intact.
Let’s get back to the root problem. What is the use case you want to achieve?
If the need is for a sandbox space for which a single Admin (out of multiple) makes themself the only user with Architect+ access, then this is indeed a missing gap (or rather, it requires assistance from another admin).
If the need is for a sandbox for a member (with Architect+ rights) where zero, one or all Admins have data access, then this is already possible as described above.
I just want to add here, that although the use cases can only be solved by having two users helping each other, this is a side-effect of not wanting to violate the axioms in the bullet points above, whilst still making the UX/UI not too confusing for most users/use cases.
It is certainly possible that we could hypothesise a feature that would allow someone to convert specific individual admins from Architect+ to Architect-, without having to affect the whole admin group, but we probably won’t work on it any time soon.
OK indeed now two user have to help each other. I just thought it would be great if one user can do this by themselves, making themselves the only admin for that workspace.
Thanks for the help and glad that it’s been cleared up. We will use this workaround now of collaborating with two admins to achieve this goal.