Users, Groups and Permissions¶

Getting Started with Users¶

When you sign up for edgeContinuum, your account is automatically set up with a Personal Organization - a dedicated workspace just for you. This is your own isolated environment where you can experiment, create infrastructures, and manage services.

Your Personal Organization¶

Your personal organization:

Is created automatically when you register
Is entirely yours and isolated from other users
Can be used as a sandbox for testing and learning
Can hold projects, infrastructures, and managed services just like any other organization

Creating Additional Organizations¶

If you need more workspaces for different purposes (separate clients, departments, projects, etc.), you can create additional organizations. Each organization you create is completely independent with its own:

Resources and configurations
Users and groups
Infrastructures, service configs and service platforms
Projects and managed services

Users and Organizations¶

Inviting Users¶

You invite people to your organization by email address. Invitations have their own lifecycle:

You send an invitation to an email address.
The invitee accepts or declines it from their own My Invitations view. An invitation can be pending, accepted, declined, or expired, and you can cancel one that is still pending.
You grant access — an invitation by itself carries no permissions (see the warning below).

A new member starts with no access

Joining an organization does not grant any permissions. After someone accepts, you must explicitly assign them permissions — directly or through a group — before they can do anything. Inviting someone who is already a member (or already invited) is rejected.

The person who creates an organization is its Owner; owners cannot be removed from it. Registration and email verification for new accounts are covered in Account & Security.

Multi-Organization Access¶

A single user can belong to multiple organizations:

Users invited to an organization become members of that organization
Each organization membership is independent
Users can have different roles and permissions in each organization

Groups¶

Groups allow you to efficiently manage permissions for multiple users within an organization.

Understanding Groups¶

Organization-scoped: Groups are defined and managed at the organization level
Not shared across organizations: Groups created in one organization are not visible or accessible in other organizations
Simplified permission management: Instead of assigning permissions to individual users, you can assign them to groups
Flexible membership: Users can belong to multiple groups within the same organization

A group is defined once at the organization level, but you grant it permissions in two places: organization-level permissions that apply across the org, and project-specific permissions assigned to the group per project. To use a group in a project, it must already exist at the organization level.

Best Practices for Groups¶

Organize by function: Create groups for teams, departments, or functional roles (e.g., developers, devops, data-team)
Organize by project: Create groups for specific projects or clients
Use meaningful names: Choose clear group names that describe their purpose
Review regularly: Periodically audit group membership to ensure it remains current

Permissions¶

Permissions in edgeContinuum control what users and groups can do across the platform. Permissions are organized into sections and can be granted at two levels:

Organization-level permissions: Control access to organization-wide resources and settings
Project-level permissions: Control access to specific projects and their managed services

Assigning permissions¶

In the console you grant access by selecting one or more permissions for a user or a group, at the organization or project level. A grant must include at least one permission. To add a user or group to a project, they must already be a member of (or a group in) the organization.

Behind the scenes the platform manages the roles that carry these permissions for you — in the console you work directly with the permissions themselves. For the full catalog of permissions, see the Permissions Reference.

Permission Inheritance¶

Some organization-level permissions are automatically inherited to all projects within that organization. This means:

If a user/group has a permission at the organization level that is inheritable, they automatically have it in all projects
Project-level permissions still apply and can further restrict or grant access

Viewing Available Permissions¶

For a comprehensive list of all available permissions, including which ones are inheritable, see the Permissions Reference.

Best Practices¶

Principle of least privilege: Grant users and groups only the permissions they need to perform their work
Use groups for consistency: Assign permissions to groups rather than individual users when possible
Plan your permission structure: Design your organization and project hierarchy with permissions in mind
Review permissions regularly: Periodically audit who has what access to ensure it aligns with your team structure
Use multiple projects: Leverage project-level permissions to provide fine-grained access control