Skip to main content

Documentation Index

Fetch the complete documentation index at: https://altostrat.io/docs/llms.txt

Use this file to discover all available pages before exploring further.

Workspaces and organizations define the operating boundary for your SDX environment. They help you separate customers, business units, teams, subscriptions, and managed resources.

​
Prerequisites

  • You know whether your structure should follow customers, regions, departments, brands, or operating teams.
  • You know who should administer each area.
  • You understand which sites and policies belong together.

​
Core Concepts

ConceptPurpose
WorkspaceThe main portal context where teams, users, resources, subscriptions, billing, and audit logs are managed.
OrganizationA business or customer structure used to organize ownership and account hierarchy.
TeamAn access and ownership boundary for users and resources.
RoleA permission set assigned to users so they can perform the right actions.

​
Design a Structure

  1. Start from the way your operations team works today.
  2. Identify boundaries that require separate access, reporting, or billing visibility.
  3. Create teams for those boundaries.
  4. Keep resource ownership consistent: sites, policies, workflows, reports, and notification groups should live where the responsible team can manage them.
  5. Review the model after your first few sites are onboarded.

​
Common Patterns

Use a customer-based structure when you are an MSP or operator managing separate customer environments. Use a region-based structure when operational responsibility follows geography. Use a department-based structure when internal IT, guest networks, security, and operations need different access boundaries. Use a service-tier structure when policies, reporting, and response expectations differ by contract or support level.

​
Good Practices

Avoid creating a new workspace or team for every small exception. Too much fragmentation makes reporting, access review, and policy rollout harder. Use tags for flexible grouping inside a team. Tags are often better than extra teams when you only need filtering, reporting, or policy targeting.
See Metadata and Tags for resource grouping that does not require changing ownership boundaries.