User and access management

Access modes: evaluation and governed

Ringinx supports two operating modes. The difference matters for both security and compliance, and security is a shared responsibility: Ringinx operates the platform's controls, while your organization operates the complementary controls that a governed deployment requires.

• Evaluation mode. Before the organization is claimed, approved-domain users self-register individual accounts. This keeps evaluation simple. Baseline controls still apply (domain allowlist, email verification, a one-time passcode at login, encryption, and audit logging), but membership is not yet centrally governed and no administrator is designated. We recommend not placing sensitive or regulated corporate data in Ringinx while in this mode.
• Governed (enterprise) mode. After an administrator claims the organization and enforces single sign-on, membership follows the corporate identity provider, password login is disabled, and access is centrally managed. This is the intended mode for production use.

The steps below describe how an organization moves from evaluation to governed mode. See also the shared responsibility model on the trust center.

1. Domain approval

Ringinx access is granted at the organization level, not to individuals. Before anyone from an email domain can create an account, the domain itself must be approved by Ringinx.

Approval starts with a request submitted through the request access form, ideally by an authorized representative of the organization. Each request is reviewed manually. Once approved, Ringinx adds the domain to the platform and emails the requester (from info@ringinx.com) with next steps.

At this stage no administrator is designated for the domain. Claiming the domain administrator role is a separate step (see step 3).

2. Individual accounts

Once a domain is approved, users with an email address on that domain create their own individual accounts directly on the platform:

• Each user self-registers and authenticates with their work email and a password at the Ringinx sign-in page. No per-user invitation is issued.
• At sign-up the platform verifies the email's domain against the approved list; addresses on unapproved domains cannot create accounts.
• Each user verifies ownership of their email address before first use. At every login, after the password, a single-use one-time passcode sent to the account's email address is required to complete sign-in.
• Individual accounts have feature scope appropriate for evaluation, personal use, and early team experimentation.
• Each individual account's data is isolated from other individual accounts on the same domain until the organization is claimed (next step).

3. Claiming the organization

When the organization is ready to operate Ringinx centrally rather than as a collection of individual accounts, the first administrator from the domain claims the organization:

• Verifies administrative authority over the domain (for example, by publishing a DNS TXT record or equivalent proof of control).
• Consolidates existing individual accounts from the same domain under the corporate tenant. Users keep their existing data and work; no migration is required from end users.
• Becomes the organization administrator and is responsible for ongoing user management, roles, and configuration.

After the claim, all current and future users from the same domain are members of the corporate organization rather than standalone individual accounts.

4. Enterprise tier and single sign-on

After claiming the organization, the administrator may move the organization to the enterprise tier and configure single sign-on. Supported identity providers:

• Microsoft Entra ID (Azure AD)
• Google Workspace

Once SSO is enabled and enforced:

• All users from the domain authenticate through the corporate identity provider. Password-based login is disabled for the organization.
• Joiners, movers, and leavers are reflected in Ringinx based on the directory state in the identity provider.
• The organization administrator controls who has access and at what privilege level, in line with corporate security policy.

Roles

• Organization administrator. Manages users, roles, SSO configuration, designated support contacts, and (if applicable) the connected Google Cloud and billing accounts.
• Member. Uses agents, MCP servers, apps, and other platform features within the scope assigned to them.

Additional roles and permissions are documented inside the platform itself.

Designated support contacts

Tickets to Ringinx are submitted only by users designated as support contacts. By default this is the organization administrator, who may delegate to other members of the IT or platform team. See Support for the full model and ticket workflow.

Administrator hardening checklist

To move from evaluation to a governed, audit-ready deployment, we recommend administrators complete the following as early as possible:

• Submit the access request from an authorized representative of your organization.
• Claim the organization by proving domain ownership (DNS TXT).
• Move to the enterprise tier and enforce single sign-on (Microsoft Entra ID or Google Workspace).
• Confirm password-based login is disabled once SSO is enforced.
• Assign administrator and member roles on a least-privilege basis, and grant the administrator role to more than one person.
• Designate the support contacts authorized to file tickets with Ringinx.
• Establish a joiner, mover, and leaver process through your identity provider, and review access periodically.
• Only after these controls are enforced, migrate sensitive or regulated data into the platform.

Common questions

What happens if my organization's domain isn't approved yet?

Accounts cannot be created on an unapproved domain — the platform rejects sign-up attempts from domains that are not on the approved list. To get started, an authorized representative should submit the request access form so the domain can be reviewed and approved.

Do individual users receive an invitation email?

No. Once a domain is approved, users self-register at the Ringinx sign-in page. Ringinx emails the original requester (from info@ringinx.com) when the domain is approved, not each individual user.

Can multiple people share the administrator role?

Yes. The organization administrator role can be granted to additional users.

What happens to individual accounts after the organization is claimed?

They are migrated into the corporate organization. No data is lost; existing work is preserved.

Can SSO be disabled later?

Yes, by the organization administrator. Doing so reverts the organization to password-based login and is not recommended for production use.

Which identity providers are supported?

Microsoft Entra ID (Azure AD) and Google Workspace today. Other SAML 2.0 or OIDC providers will be considered on request.