Cloud Cost Management Team Roles

import { Steps } from ‘@astrojs/starlight/components’;

Cloud Cost Management Team Roles

Xplorr supports multi-user organizations with role-based access control. You can control who sees which accounts, who can make changes, and who just needs a read-only view.

Roles

Your organization has three roles:

Role	What they can do
Admin	Everything: manage users, connect and disconnect cloud accounts, replace credentials, create budgets and alert rules, manage org settings and billing, close the org.
Member	View the data they have access to, connect and own their own cloud accounts and clusters, create and manage budgets and alerts, acknowledge anomalies, manage their own notifications. Cannot manage users or remove someone else’s cloud account.
Viewer	Read-only access to dashboards, reports, and recommendations for the accounts they can see. Cannot create or modify anything.

An organization with only one admin cannot demote or deactivate that admin; there is always at least one person who can undo a mistake.

These roles, and what each one can do, are now defined in a single permission table read by every Xplorr service and the console, so a button the console offers and an action the API accepts can no longer disagree. Newer permissions in that table, such as a member creating an org-wide alert, roll out gradually: today’s actual behavior is unchanged until Xplorr switches enforcement on, which is announced on the changelog.

Xplorr staff are not one of your roles

Xplorr employees who provide support or operate the platform are a separate concept, entirely outside your organization: a platform_staff record bound to one specific account, not a role any of your users can hold. Staff always use a second factor and cannot sign in through your organization’s SSO. See Security for what staff access looks like and how it is logged.

Per-account access control

By default, all users can see all connected cloud accounts. For organizations that need account-level isolation (e.g., separate teams managing separate AWS accounts), admins can restrict access:

1. Go to Settings → Team in the console.

2. Click on a user to open their profile.

3. Under Account Access, toggle from All Accounts to Specific Accounts.

4. Select which cloud accounts this user can see. They’ll only see cost data, recommendations, and anomalies for those accounts.

5. Click Save.

Users with restricted access will see “No data” for accounts they don’t have access to. They won’t know the other accounts exist — the accounts simply don’t appear in their dropdown or reports.

Inviting users

1. Go to Settings → Team and click Invite User.

2. Enter their email address.

3. Choose their role: Admin, Member, or Viewer.

4. Optionally restrict their account access (defaults to all accounts).

5. Click Send Invite.

The invitee receives an email with a link to create their Xplorr account and join your organization. The invite link expires after 7 days. You can resend it from the Team page if it expires.

Bulk invites

If you’re onboarding a large team, you can invite multiple users at once by entering comma-separated email addresses. All users in a bulk invite get the same role and access settings — adjust individual permissions after they accept.

Two-factor authentication is required

Every password sign-in requires a second factor, an authenticator app code or a passkey. This isn’t a setting an admin turns on: it applies to every organization, including choosing which organization to sign in to, accepting an invitation, and verifying an email address.

Anyone without a factor set up is walked through enrolling one the moment they need it, rather than locked out with no path forward.

Setting up your own factor

1. Open Settings. The Two-Factor Authentication and Security keys cards are personal, so everyone sees them.
2. For an authenticator app, click Enable 2FA, scan the QR code with Google Authenticator, Authy, 1Password or similar, and enter the 6-digit code to confirm. Save your backup codes somewhere safe.
3. For a security key or passkey, use Add a security key on the Security keys card. See Security keys and passkeys below.

If you have no second factor yet, the sign-in screen walks you through the same choices before you reach the console.

Signing in through SSO

If your organization uses SAML SSO, signing in through it is exempt: your identity provider is trusted to handle multi-factor authentication on its side, so Xplorr doesn’t ask again. This exemption follows the sign-in method, not the account: if a SAML account tries to sign in with a password instead of through SSO, and has no factor of its own enrolled, it’s sent to SSO sign-in rather than left at a dead end. See Security for how SSO domain verification works.

Security keys and passkeys

A security key (WebAuthn) is a second factor. You still sign in with your password first, then use any one of your registered keys. It does not replace the password.

Kinds of key

When you add a key you choose what kind it is before the browser prompt, so the browser asks for the right thing:

Choice	What it is
Security key	A YubiKey or other USB or NFC key. Insert or tap it when asked.
This device	Touch ID, Face ID or Windows Hello on the computer or phone you are using now.
Passkey from a password manager or phone	Saved in 1Password, iCloud Keychain, Google Password Manager or similar, or on a phone you scan a QR code with.

Each registered key is listed with its type as Xplorr sees it (Hardware security key, Synced passkey or Passkey on one device), its name, when it was added and when it was last used to sign in.

Rules

• Up to 10 keys per person. The eleventh is refused; remove one to add another.
• Any key works at sign in. Every registered key is offered, so whichever one you have with you finishes the sign in.
• One set of keys for every organization. Keys belong to you, not to one membership.
• Names. Up to 64 characters. Left empty, a key is named Security key 1, Security key 2 and so on. Rename changes it at any time (recorded in the audit log as user.webauthn_renamed).
• The only second factor cannot be removed. Two factor authentication is required, so removing your last security key when you have no authenticator app, or removing the authenticator app when you have no security key, is refused. Add another factor first.
• A backup is recommended. If you lose your only key, an admin has to reset your second factor. With a backup key you can still sign in.

Register two YubiKeys when you set up 2FA

If you have no second factor yet, the sign-in screen asks you to set one up.

1. Sign in with your email and password. The Set up two factor authentication screen opens.
2. Under What kind of key?, choose Security key.
3. Enter a Name, for example YubiKey 1, or leave it empty.
4. Click Register key, then insert or tap the first YubiKey when the browser asks.
5. The screen shows Security key added and offers Add a backup security key (recommended). Choose Security key again and name it, for example YubiKey 2.
6. Click Register backup key, then insert or tap the second YubiKey. A key that is already registered is refused, so use the other one.
7. Click Finish. You are signed in with both keys registered.

Store the second key somewhere apart from the first.

Register two YubiKeys from Settings

1. Open Settings and find the Security keys card.
2. Under Add a security key, choose Security key, enter a name such as YubiKey 1, and click Add security key.
3. Insert or tap the first YubiKey when the browser asks. It appears in the list as a Hardware security key.
4. Repeat steps 2 and 3 with the second YubiKey and a name such as YubiKey 2.
5. Sign out and sign in again with each key in turn to confirm both work.

Sharing a cloud account

A member who connected a cloud account owns it and can share it, read only, with the rest of the organization:

1. Go to Infrastructure → Cloud Accounts and open the account.
2. Click Share and confirm.
3. Everyone in the organization can now see cost data, recommendations and anomalies for that account. Only an admin, or the member who owns it, can change who has write access.

Resetting a member’s second factor

If a member loses their authenticator device or passkey, an admin can reset their second factor from Settings → Team without waiting on Xplorr support, as long as the person belongs to only this one organization:

1. Open the member’s profile from the Team page.
2. Click Reset 2FA and confirm.
3. Their authenticator, backup codes and security keys are cleared, their sessions are revoked, and they receive a notice email naming the admin who did it.

For someone who belongs to more than one organization, this is refused: a second factor now covers every organization a person is in, so resetting it here would also affect their other organizations. Contact Xplorr support instead.

Reassigning what someone owns

Deactivating a user, or demoting them to viewer, can leave budgets, alert rules, scheduled reports, saved views, unit metrics, allocation rules, tagging policies and clusters without an owner able to edit them. When that happens, the console shows what the person owns and lets you reassign each type to another admin or member, or leave it owned by admins only. Nothing is deleted either way, and the choice is recorded in the audit log.

Removing vs. deactivating

Two different actions on the Team page, and they’re not interchangeable:

	Deactivate	Remove
What happens	Access is revoked immediately; the account, its role and everything it owns stay in place	The membership is deleted from your organization
Reversible?	Yes: inviting the same address again restores the account	No
What they owned	Stays exactly where it is, editable by admins, unless you reassign it	Must go to a named successor first if they own anything; the removal can’t complete otherwise
Pending invitation to the same address	Unaffected	Revoked, so they can’t be re-added by accident
Their second factor	Unaffected	Cleared, but only if this was their last organization; it stays intact if they belong to others

Use Deactivate for someone leaving temporarily, or when you’re not certain removal is final. Use Remove when you’re certain: offboarding, a contractor’s engagement ending, or cleaning up an account that’s been inactive for a long time.

Choosing a successor

If the person you’re removing owns anything, budgets, alert rules, scheduled reports, saved views, unit metrics, allocation rules, tagging policies, cloud accounts or clusters, the removal dialog shows what they own and asks for a successor before it will proceed. Pick another admin or member; everything they owned moves to that person in one step. You also type the person’s email address to confirm before the removal runs, since it can’t be undone.

Deactivating doesn’t require this: it leaves ownership as is (reachable by any admin) unless you separately choose to reassign it.

Step-by-step: setting up your team

1. Start as Admin. The person who created the Xplorr org is its first Admin. Enable 2FA on your own account first.

2. Invite your co-admin. Send an Admin invite to one other person so you’re not a single point of failure for org management.

3. Invite team leads as Members. They can view data, manage budgets, and handle anomalies for their areas.

4. Invite executives as Viewers. They get dashboards and reports without the ability to change configurations.

5. Restrict account access if needed. If team A shouldn’t see team B’s AWS account costs, set up per-account restrictions.

6. Know the removal path before you need it. Deactivate someone leaving temporarily; remove someone permanently, choosing a successor for anything they own.

Common mistakes

• Making everyone an Admin. Admins can connect and disconnect cloud accounts, which affects data for the entire org. Keep Admin count to 2–3 people.
• Having only one Admin. An org can’t demote or deactivate its last Admin, but if that person leaves the company without handing off access first, you’ll need Xplorr support to transfer ownership. Invite a second Admin early.
• Removing someone instead of deactivating them. Removal is permanent and can’t be undone. If there’s any chance the person is coming back, or you’re not sure yet, deactivate instead.
• Over-restricting account access. If team leads can’t see the full picture, they’ll miss cross-team optimization opportunities. Restrict access only when there’s a genuine need (e.g., separate business units with confidentiality requirements).

FAQ

Can I change a user’s role after they’ve joined? Yes. Go to Settings → Team, click the user, and change their role from the dropdown. The change takes effect on their next page load.

What happens when I remove a user? Their membership is deleted. If they owned anything, you chose a successor before the removal completed, and everything moved to that person as part of the same action. Their pending invitation to the same address, if any, is revoked. If this was their only organization, their second factor is cleared too; if they belong to others, it’s untouched.

What happens when I deactivate a user instead? Their access is revoked immediately, but the account, its role and anything it owns stay exactly as they were. Inviting the same address again restores it. Anything they owned stays reachable by admins unless you use the reassignment dialog to move it to someone else.

Can a user belong to multiple organizations? Yes. Users can switch between orgs from the org selector in the top-left corner of the console. Each org has its own role and access settings, but one second factor covers all of them.

What authenticator apps work with Xplorr 2FA? Any TOTP-compatible app: Google Authenticator, Authy, 1Password, Bitwarden, Microsoft Authenticator, etc. The standard is RFC 6238. A security key or passkey works too, as a second factor after the password.

Key takeaways

• Use the principle of least privilege — Viewer for read-only users, Member for active users, Admin for team leads.
• 2FA is required for every account; SSO sign-in is the only exemption.
• Deactivate when you’re not sure; remove only when you are, and pick a successor if they own anything.
• Set up per-account access control only when you have a clear isolation requirement.
• Always have at least two people with Admin access.