Team & user management

Managing your team on GLBNXT Platform means ensuring that every person who needs access to the environment has it, that their access is scoped appropriately to their role, and that accounts are kept current as your team changes over time. Well-managed team access reduces security risk, supports compliance obligations, and ensures that the right people can do their work without unnecessary friction.

This section covers how to add and manage users in your environment, how to assign and maintain roles, how to manage access for teams working across multiple environments, and the practices that keep your team access configuration healthy over time.

User Accounts

Every individual accessing GLBNXT Platform has a dedicated user account. User accounts are the identity anchor for all activity within the environment. Every action taken in the platform, from a model inference request to an administrative configuration change, is attributed to the authenticated user account that performed it. This attribution is captured in the audit trail and is the basis for access control enforcement across the environment.

User accounts are provisioned in one of two ways depending on your environment configuration.

SSO-provisioned accounts are created and managed through your organisation's identity provider. When SSO integration is configured, user accounts in the platform are linked to the corresponding identity provider identity. Provisioning and deprovisioning are managed through the identity provider, ensuring that platform access stays synchronised with your organisation's broader user lifecycle management. When an employee leaves and their identity provider account is deactivated, their platform access is revoked automatically.

Directly provisioned accounts are created by your platform administrator through the platform console. Direct provisioning is appropriate for environments where SSO has not been configured, for external collaborators who do not have an account in your identity provider, and for service accounts used by application workloads. Directly provisioned accounts require manual deprovisioning when no longer needed.

Adding Users

New users are added to your environment by your platform administrator through the user management area of the platform console. When adding a user, the administrator specifies the user's identity, either by linking to their identity provider account or by creating a direct login credential, and assigns the role or roles appropriate for their work in the environment.

For environments onboarding a large team at launch, user provisioning can be completed in bulk through the access list provided to your GLBNXT contact during onboarding. Individual users can be added at any time after initial provisioning by your platform administrator.

New users added to the environment with direct login credentials should be advised to update their password on first login and to enable multi-factor authentication immediately. For SSO-provisioned users, MFA is enforced by the identity provider according to your organisation's existing policies.

Roles and Role Assignment

Roles define what a user can see and do within the platform environment. Every user account is assigned one or more roles at the time of provisioning. The roles available in a GLBNXT Platform environment and how they are assigned are covered in detail in the Access Control and Identity section. The key principle to apply when assigning roles is least privilege: every user receives the minimum access needed to fulfil their responsibilities within the platform, and no more.

Role assignments should be reviewed whenever a team member changes role, moves to a different project, or takes on responsibilities that require different platform access. Accounts that retain roles from previous assignments accumulate permissions that are no longer appropriate, creating unnecessary security exposure.

Teams and Grouped Access

For organisations where multiple team members share the same access requirements, roles can be assigned at the group level rather than individually. Group-based access assignment links a set of roles to a defined group, and adds users to that group to grant them the appropriate access. When a new team member joins who requires the same access as an existing group, they are added to the group rather than having roles configured individually.

Group-based access management is particularly effective in SSO-configured environments where groups can be managed in the identity provider and synchronised automatically to the platform. Changes to group membership in the identity provider are reflected in platform access without requiring manual updates by the platform administrator.

External Collaborators and Partner Access

Engagements involving external collaborators, such as partner development teams, consultants, or contractors, require careful access configuration. External collaborators should be provisioned with the minimum access required for their specific contribution and should have access revoked promptly when their engagement ends.

For partner teams working within a client environment, access is typically configured during onboarding with the scope agreed between the client organisation and the partner. Partner access should be scoped to the specific components the partner team needs to build and maintain their solutions, without granting visibility of other parts of the environment that are not relevant to their work.

External collaborator accounts provisioned with direct login credentials require particular attention during offboarding. Because deprovisioning is manual for direct accounts, a clear process should be in place to ensure that contractor and partner accounts are revoked at the end of an engagement rather than left dormant.

Service Accounts

Application workloads running on GLBNXT Platform authenticate to platform services using service accounts rather than user credentials. Each application workload that needs to access platform resources, such as a model endpoint, a database, or a storage bucket, should have a dedicated service account scoped to exactly the resources it requires.

Service accounts are created by your platform administrator through the platform console. Credentials for service accounts are managed through the platform secrets vault and injected into application workloads at runtime. Developers building applications on the platform do not handle service account credentials directly.

Service accounts should be named descriptively to make their purpose clear in audit logs and access reviews. An account named after the specific application or workload it serves is significantly easier to manage and audit than a generic credential shared across multiple applications.

Offboarding Users

Prompt deprovisioning of user accounts when team members leave or change role is one of the most important hygiene practices for platform security. Dormant accounts with active credentials represent an unnecessary risk, particularly for accounts with elevated roles such as administrator or developer access.

For SSO-configured environments, offboarding a user from the identity provider automatically revokes their platform access. No additional action is required in the platform itself.

For directly provisioned accounts, offboarding requires the platform administrator to deactivate or delete the user account through the platform console. A process should be in place to ensure that account deprovisioning is initiated promptly when an employee leaves the organisation or when a contractor or partner engagement ends.

When a user with an administrator role leaves, confirm that at least one other active administrator account exists in the environment before the departing user's account is deprovisioned. An environment with no active administrator account cannot be managed through the console and requires GLBNXT intervention to restore administrative access.

Access Reviews

A periodic access review verifies that every active account in the environment has role assignments appropriate to the account holder's current responsibilities. Access reviews catch accumulated permissions from role changes that were not cleaned up, identify dormant accounts that should have been deprovisioned, and confirm that service account scoping remains appropriate as applications evolve.

The recommended cadence for access reviews depends on the pace of change in your team and the sensitivity of the data processed in your environment. Quarterly reviews are appropriate for most production environments. Environments handling highly sensitive data or subject to strict regulatory requirements may warrant more frequent reviews.

Access review outputs should be documented and any corrections made promptly. For regulated environments, access review records may form part of the evidence base for compliance assessments and should be retained accordingly.

User Management in Multi-Environment Deployments

Organisations operating multiple GLBNXT Platform environments, such as separate environments for development, staging, and production, or separate environments for different business units or client deployments, manage user access independently in each environment. A user's role in one environment does not automatically grant them any access in another.

For teams that work across multiple environments, role assignments in each environment should reflect the access appropriate for that specific context. A developer who requires broad access in a development environment to build and test solutions may need more restricted access in a production environment where they are monitoring and supporting deployed applications rather than actively building.

For guidance on the access control policies that govern what users can do within their assigned roles, see the Access Control and Identity section. For guidance on the audit logging that captures user activity across the environment, see the Audit Logs and Query History section.