Portal Access: Features, Roles, and Scope
Overview
Portal access in Spotto controls which companies, features, pages, and actions a user or API key can use. It combines company feature availability, assigned roles, role scope, and backend checks into one effective access result.
This page explains how those pieces fit together so administrators can understand why something is visible, locked, hidden, or unavailable. It covers Spotto Portal authorization only; cloud-provider permissions such as Azure RBAC are separate and still matter when Spotto connects to cloud accounts.
The API is the source of truth for access decisions. The Portal uses the evaluated access state to show or disable controls, but hiding a button is not the security boundary. Server-side authorization still decides whether an action is allowed.
SSO and external identity
Spotto supports Azure SSO for Portal sign-in. Authentication is handled through Spotto's identity layer, backed by AWS Cognito, and can federate with Azure so your existing Microsoft Entra ID controls such as MFA, Conditional Access, and user offboarding remain part of the login path.
SSO and Portal roles do different jobs:
| Control | What it decides |
|---|---|
| Azure SSO / Microsoft Entra ID | Who can sign in, whether MFA or Conditional Access applies, and whether an offboarded user can still authenticate. |
| Spotto roles and scopes | Which Spotto companies, pages, features, and actions the signed-in user can access. |
Spotto does not currently map Microsoft Entra group membership or group claims directly into Portal roles. A successful SSO login proves who the user is; Spotto then uses its own company membership, role assignments, and delegation scopes to decide what that user can access inside the Spotto Portal.
In practice:
- Use Azure SSO for authentication and identity lifecycle controls.
- Assign Spotto roles inside the Portal for authorization.
- Use role scope to limit whether access applies only to one company, child companies, or all companies.
- Use feature availability when a whole capability, such as Ask Spotto AI, should be enabled or disabled for a company.
This keeps cloud identity policy and Spotto application authorization separate. That separation is useful when an organization wants SSO and Conditional Access without allowing every Entra group change to alter application permissions automatically.
How Portal access works
Spotto evaluates access in this order:
- Company feature availability decides whether the selected company can receive a feature.
- Roles and permissions decide what the signed-in user or API key can do inside that company context.
- Delegation scope decides where the role applies, such as this company only or child companies.
- Presentation state decides whether the Portal should hide the feature, show it normally, show it as locked, or show teaser/promo information.
Company feature availability is checked before user permissions. A user cannot access a feature just because their role includes a matching permission if the selected company is not entitled to that feature.
Key concepts
| Term | Meaning |
|---|---|
| Feature | A Spotto Portal capability, page, workflow, or action area. |
| Feature set | A bundle of features that can be made available to a company. |
| Role | A system-defined set of permissions. Roles are assigned to users or API keys. |
| Permission | A specific action capability, such as viewing, using, managing, or assigning access. |
| Scope | Where an assigned role applies in the company hierarchy. |
| Principal | The identity receiving access. This can be a user or an API key. |
| Effective access | The final evaluated result after feature availability, role permissions, scope, and presentation rules are applied. |
Company feature availability
Feature sets control which features are available to a company. A feature set can be available by default, unavailable by default, or changed through a company-specific decision.
Administrators and support users may see these decision types when reviewing feature access:
| Decision | Meaning |
|---|---|
| Default (inherit) | No local decision exists. Spotto uses the nearest parent decision or the catalog default. |
| Allow | The company receives the feature set. |
| Deny | The company does not receive the feature set unless a later allowed decision applies. |
| Restrict | A parent company blocks descendant companies from receiving the feature set. |
Parent restrictions take precedence over child allow decisions. This prevents a child company from enabling a feature that a parent company has explicitly restricted.
Roles and scope
Roles control what a user or API key can do after the company is entitled to a feature. Each role assignment includes a role and a scope.
| Scope | Meaning |
|---|---|
| This company | Applies only to the selected company. |
| Direct child companies | Applies to the selected company and its immediate child companies. |
| All child companies | Applies to the selected company and every descendant company. |
| All companies | Applies across all company contexts available to the administrator. |
Use the narrowest scope that fits the job. Broad scopes are useful for central operations and support teams, but they also increase the blast radius of mistakes. The computer will do exactly what you permitted it to do, which is rarely a comforting thought after the fact.
Role quick reference
Spotto roles are system-defined permission bundles. Customers normally assign roles from the Users screen or, for automation, from the API Keys screen.
Start with the role that matches the person's job, then keep the scope as narrow as practical.
| Role | Choose this for | Assignable to |
|---|---|---|
| Company Viewer | Read-only company visibility for people who need a basic view of selected portal pages. Investigate pages are not included. | Users and API keys |
| Company Administrator | Day-to-day company administration, including users, settings, integrations, billing, cloud accounts, tags, and access. | Users and API keys |
| Company Hierarchy Administrator | Delegated administration across this company and child companies. Useful for parent-company or MSP operating models. | Users and API keys |
| Accounts Administrator | Cloud account onboarding, subscriptions, API keys, connector setup, Spotto MCP access, and sync diagnostics. | Users and API keys |
| FinOps Analyst | Cost analysis, Cost Tree, recommendations, commitments, trend tracking, storage cost analysis, and tracked savings work. | Users and API keys |
| Operations Analyst | Alerts, schedules, resources, tickets, notes, relationship graphs, service retirement, backups, and operational diagnostics. | Users and API keys |
| Security Analyst | Security posture, governance, perimeter insights, relationship graphs, review checklists, and recommendation review. | Users and API keys |
| Service Delivery Manager | Customer reporting, SDM reports, review checklists, statements of work, tracked work, tickets, notes, and service reviews. | Users and API keys |
Some roles are used only for specific Portal setups:
| Role | Choose this for | Assignable to |
|---|---|---|
| Customer Portal Viewer | Limited customer-facing portal access where the customer portal experience is enabled. | Users only |
| Portal Administrator | Spotto administration across global portal configuration, customers, users, features, and operational controls. This role is only assignable at the root company. | Users only |
The exact pages available to a role can still depend on feature availability for the selected company. For example, a user may have a role that includes Ask Spotto AI access, but the chat feature can still be disabled for the company.
Role assignment
Each role assignment combines a system-defined role with a scope. Use role assignment when inviting users, editing users, or configuring API-key authorization.
For most users, choose This company first. Use child-company scopes only when the person needs delegated access across a hierarchy. Use All companies only for portal-wide administration.
For invite and edit workflows, see Users: Invite and Manage Access.
Users and API keys
Spotto treats users and API keys as portal principals for access evaluation.
| Principal type | How it is used |
|---|---|
| User | An interactive person signing in to the Portal. Users can see pages, controls, locked states, teaser states, and promo states where their access allows it. |
| API key | A non-interactive principal used for protected API calls. API keys can receive roles and scopes, but they do not use UI-only teaser or promo actionability. |
API-key access documentation here is about role assignment and authorization. API-key creation, one-time secret display, rotation, and network restrictions are covered in API Authentication.
For the customer-manageable workflow, see Feature Sets: Control Company Availability.
Access review pages
Where enabled, the Portal provides administration pages for reviewing access:
- Feature Sets shows effective availability, source, local overrides, audience, and inherited parent restrictions for customer-manageable feature sets.
- Users shows Classic and Advanced user roles and delegation scope.
- API Keys shows authorization assigned to non-interactive API principals where that workflow is enabled.
Use these pages to inspect access before changing assignments. They are especially useful in parent-child company setups because the selected company, principal company, and role scope can all affect the final result.
Presentation states
Effective access can produce different Portal states:
| State | What it means |
|---|---|
| Hidden | The feature should not appear for the principal in this context. |
| Visible | The feature appears and the principal can use allowed actions. |
| Locked | The feature appears, but the requested action is not allowed. |
| Teaser | The feature may be shown as available to learn about, but it is not actionable. |
| Promo | The feature may be shown for upgrade or rollout awareness, but it is not actionable. |
Teaser and promo states never grant data access or write access. They are presentation states, not permissions.
Reason codes
When Spotto explains an access result, it may include a reason code. Reason codes are intended to make troubleshooting possible without reading backend logs.
| Reason code | Meaning | First check |
|---|---|---|
not_entitled | The company does not receive the feature. | Check the selected company's feature availability. |
blocked_by_parent | A parent restriction blocks the company. | Check parent-company feature decisions. |
missing_view_permission | The principal cannot view the feature or object. | Check assigned roles for view access. |
missing_use_permission | The principal can view but cannot use the action. | Check assigned roles for use access. |
missing_manage_permission | The principal can view but cannot manage settings or assignments. | Check admin or manager roles. |
missing_delegation_scope | The role exists but does not apply to this company context. | Check whether the role scope includes this company. |
preview_only | The feature is visible for preview but not actionable. | Check rollout status and enabled actions. |
coming_soon | The feature is visible ahead of availability. | Check rollout notes or contact support. |
teaser_visible | The feature is shown as teaser content only. | Check whether the company is entitled to the feature. |
promo_visible | The feature is shown as promotional content only. | Check plan or rollout eligibility. |
Boundary with cloud permissions
Portal access decides whether a Spotto user or API key can open a Spotto page or call a Spotto API action. It does not replace cloud-provider permissions.
For example:
- A user may have Portal access to view a cloud-account setup screen, but the Azure operator still needs the right Azure permissions to assign roles or grant consent.
- A company may be entitled to a Spotto feature, but the feature can still show missing-data warnings if the cloud account is missing provider-side read permissions.
- An API key may have a Spotto role for an API action, but it still cannot recover a plaintext API-key secret after creation.
For Azure cloud-account permission requirements, see Azure Cloud Account Permissions.
Troubleshooting
A feature is missing from the navigation
What you're seeing: The page or feature does not appear in the Portal.
Likely causes:
- The selected company is not entitled to the feature.
- A parent company has restricted the feature.
- Your role does not include view permission.
How to fix:
- Confirm you are using the intended selected company.
- Review the feature state in Feature Sets if it is available in your environment.
- Ask an administrator to check your assigned roles and scope.
A feature appears but actions are disabled
What you're seeing: The page is visible, but buttons or controls are locked or disabled.
Likely causes:
- Your role allows view access but not use or manage access.
- Your role applies to another company context.
- The feature is in preview, teaser, or promo state.
How to fix:
- Check the disabled control's reason message, if shown.
- Review your role assignment in Users.
- Ask an administrator to grant the required role with the right scope.
Access works in one child company but not another
What you're seeing: The same user can access a feature in one child company but not a sibling or deeper descendant.
Likely causes:
- The role scope only covers direct child companies.
- The second company has a different feature-set decision.
- A parent restriction applies to one branch of the hierarchy.
How to fix:
- Confirm the selected company's position in the hierarchy.
- Check whether the role uses Direct child companies or All child companies scope.
- Compare feature availability between the two company branches.
An API key receives a forbidden response
What you're seeing: An API request fails with an authorization error even though the key is valid.
Likely causes:
- The API key's role does not include the requested action.
- The key's scope does not include the target company.
- The company is not entitled to the feature behind the API action.
How to fix:
- Confirm the API key has not been revoked or rotated.
- Review the key's non-secret identifier, role, and scope in the admin UI.
- Check the target company's feature availability and the API action being called.