Users & Groups FAQ
Answers to common questions about external users, using the same admins across tenants, and how permissions and groups behave.
Adding external users
| Topic | Details |
|---|---|
| What is an external user? | A user who already exists in Xyte under another tenant. |
| External Users & Groups section (settings page) | View-only. It shows which external users/groups are already added to the tenant — they are not created from here. |
| Add an external user directly to a space | Space → Settings → Access → Manage User Access, then add the external user to the relevant space. This is space-level access. |
| Add via a group (alternative) | Settings → Users & Groups → Groups — create a group; when adding members you can choose internal or external users, then assign the group to the space. Use a group with tenant-wide access to grant access to the whole tenant. |
| Still seeing an error? | Share the exact error message or a screenshot so it can be reviewed. |
Conditions for adding an external user to a group
An org admin can add an external user to a group only when the user's email resolves to exactly one eligible, active user.
| Topic | Details |
|---|---|
| Who is eligible? | An active user who already exists in Xyte and is (a) a partner user, (b) a member of a Connect+ organization connected to yours, or (c) on a private cloud, a member of another organization in the same private cloud. |
| Is a support license required? | No. A support license/seat is not required to add an external user. |
| "User not found" | No active user with that email is eligible (not a partner user, not a member of a connected Connect+ organization, and not a member of another organization in the same private cloud). |
| "Provided email is ambiguous" | The email matches more than one eligible active user (e.g. the person is both a partner user and a member of a connected organization). Consolidate to a single eligible identity, then retry. |
| Deactivated users | Deactivated users are ignored — only active users are considered. |
Using the same admins in a second tenant on a private cloud
A common case: a customer already has a sandbox tenant and now needs a production tenant, run by the same admins.
On a private cloud, each email can belong to only one user across all of the private cloud's organizations. If you enter a sandbox admin's email as the Organization admin email when creating the production tenant, creation fails with "Email has already been taken", because the portal tries to create a second user with that email.
Instead, create the tenant first, then give the existing users access to it:
- In the partner portal, go to Home → Organizations and click Create Organization. Under Choose the Admin for the Organization, pick You. This needs a support seat. Without one, pick The customer and enter the email of someone who is not already a user in the sandbox. You won't get Visit portal for that organization, so that admin signs in from their invite email, goes to Settings → Users & Groups → Groups, and does step 3.
- If you picked You, click Visit portal next to the new organization and go to Settings → Users & Groups → Groups.
- Open the Administrators group, click Add External Member, and enter each sandbox admin's email.
The admins keep their existing login and switch between both tenants from the tenant switcher, with admin rights in each. In the new tenant they show with an External User tag.
Don't add the customer's users to your partner account to solve this. Partner users get partner-level access, which goes beyond this one customer.
Why don't all my accounts appear in the tenant switcher?
The account switcher (top-left) groups the accounts that belong to the same platform. All of your Connect+ accounts are grouped there, so you can switch between the ones you have access to.
An account that lives on its own — for example a standalone or brand-specific account that is not part of Connect+ — sits in a separate space. It will not appear alongside your Connect+ accounts in the switcher, even after access is granted to it — this is about the type of account, not your access rights. You can still open that account by logging into its own portal separately; it simply won't be grouped here with your Connect+ accounts.
| Account | Appears in the switcher with your Connect+ accounts? |
|---|---|
| A Connect+ account you have access to | ✅ Yes — grouped and switchable together |
| A standalone / non-Connect+ account | ❌ No — it lives in a separate space |
To have an account appear and switch alongside your Connect+ accounts, it needs to be a Connect+ account. If you need this, contact us and we'll help set it up.
How do I change a user's permissions?
A user's permissions come from the groups they belong to, plus any access granted to them directly on a space. They are not set on the user's profile, so to change them, move the user to a different group:
- Go to Settings → Users & Groups → Groups.
- On the user's current group (for example Viewers), click ⋯ → Manage Group, click × next to the user and confirm.
- On the group that has the access you want, click ⋯ → Manage Group → Add Members → Internal Users, select the user and click Add Member.
The user's Groups column on the Users tab shows the new group.
The change applies right away (the user may need to refresh) on every space that group has access to, and on everything below those spaces. If the user belongs to more than one group, they get the highest level among them — see A user is in a view-only group but can still edit.
To change what a group itself can access, open the space → Settings → Access. See Access levels.
Group permissions
| Topic | Details |
|---|---|
| Where space access is configured | When the group is added to the space's access settings — not on the group page |
| Available space access levels | View · Edit · Admin |
A user is in a view-only group but can still edit
A user's access is the highest level they hold from anywhere — not the lowest. Belonging to a view-only group does not cap access: if the same user also gets Edit or Admin from another group, from the administrators group, or from a direct grant on the space, the stronger level wins.
| The user belongs to | Effective access on the space |
|---|---|
| The view-only group only | View |
| The view-only group and a group with Edit on the space (or a space above it) | Edit |
The view-only group and the administrators group | Admin |
| Topic | Details |
|---|---|
| Organization administrators | Members of the tenant's administrators group have full access to every space and device in the tenant. This is resolved before any space-level setting, so setting a space or a group to View cannot reduce it. |
| Changing a space's Access tab | The Access tab controls that space's permissions only. It does not change administrators group membership — so removing and re-adding an administrator's access there will not make them view-only. |
The default Device support group | Every tenant is created with two default groups on the root space: Viewers (View) and Device support (Edit). Access on the root space is inherited by every space and device beneath it, so a user left in Device support has Edit everywhere. |
| Direct user grants | A user can also be granted access directly on a space, separately from any group. A direct Edit or Admin grant outranks a view-only group in the same way. |
To confirm a user is genuinely view-only on a space, check that they are in the view-only group and:
- not in the
administratorsgroup - not in the default
Device supportgroup - have no direct user grant of Edit or Admin on that space or any space above it
Test with the account itself. Testing with an administrator's own login will always show edit rights, whatever the space is set to.
Removing someone from a group did not remove their access
Group membership and Space access are two separate things. Removing a user from a group — including the administrators group — removes only the access they held through that group. Any access granted to them directly on a Space is untouched, and they keep it.
So a user who was given Admin on one Space and was also an administrator will, after you remove them from administrators, still hold Admin on that Space — they simply lose the tenant-wide access that came with being an administrator.
To remove it, open that Space → Settings → Access and remove the user there. The Users & Groups page cannot show you direct Space grants, so check the Space's own Access tab when you need someone fully removed.
Updated 6 days ago