Skip to main content

​
Root vs. SA2

Every Shanone account has exactly one Root user and, optionally, any number of SA2 users — Shanone’s term for a delegated, scoped-access teammate. If you know AWS IAM, the shape is the same: one root account, many IAM users underneath it.
There’s exactly one Root user per organization. To hand off ownership, transfer the organization rather than trying to create a second Root.

​
Creating an SA2 user

1

Open SA2 Users

In the Shanone dashboard, go to Settings → SA2 Users (Root-only) and click Create user.
2

Set a username

Pick a username that’s unique within your organization — an SA2 user types this in alongside your Organization ID/alias to sign in.
3

Set up permissions

Attach one or more Managed or Customer Managed policies, add the user to an existing group, or copy another user’s permission set as a starting point.
4

Review and create

Confirm the settings. Shanone generates a password and a direct sign-in link — share both with the new user through a secure channel.
The generated password is shown once, at creation time. Share it securely — if it’s lost, the user can recover it themselves (see below) as long as an email address was set on their account, otherwise Root has to set a new one.

​
Signing in as an SA2 user

1

Go to the sign-in page

Open the Shanone sign-in page and choose the email/password option instead of Google, Microsoft, or GitHub.
2

Enter your Organization ID or alias

Type your organization’s ID (org_...) or its short alias instead of an email address. Shanone recognizes there’s no @ in the field and reveals a Username field for you to fill in.
3

Enter your username and password

Fill in both and sign in.
If your organization has multi-factor authentication turned on, you’ll be prompted for a TOTP code (or a recovery code) after your password, with an option to trust the device for 7 days. Forgot your password? Use the “forgot password” link with your Organization ID and username — if your account has an email on file, a reset link is sent there.

​
Policies

SA2 access is governed by policies — AWS IAM-style JSON documents made of Allow/Deny statements over service:Action strings (e.g. sa2:CreateUser, analytics:Overview, organization:*). Evaluation always follows the same order:
  1. Explicit Deny wins, no matter what else is attached.
  2. Explicit Allow grants access if nothing denies it.
  3. Everything else is implicitly denied — an SA2 user starts with zero access until something explicitly allows it.

​
Managed policies

Shanone ships a set of ready-made policies so you don’t have to hand-write JSON for common roles: You can also write Customer Managed policies for anything more specific, combining Allow and Deny statements the same way the managed policies do.

​
Groups and audit logs

Attach the same set of policies to several SA2 users at once by creating a group, instead of repeating the attachment on every user individually. Every SA2-related action — user creation, policy changes, sign-ins — is written to the audit log, filterable by user, event type, and date, and exportable as CSV/JSON.

​
SA2 users and tool permissions

Policies control access to Shanone’s management surface — users, policies, analytics, organization settings. Access to the tools themselves — which of the 269+ integrations an SA2 user can actually call through their agent — is a separate layer, covered in Permissions & Access Control. An SA2 user needs the tool-permissions:ManageOthers policy action (granted via ToolPermissionAdministrator, or a custom policy) before they can change another user’s tool access — and even then, never a Root user’s.

​
Next steps

Permissions & Access Control

Control exactly which integrations and tools an SA2 user (or any teammate) can call

Troubleshooting

Fix “Permission Denied” and sign-in related errors