Members & Invitations

Anyone who can sign in to your workspace is a member of your organization. This page explains how people become members, what they must do before they can use the workspace, and how to suspend or revoke access.

Settings live under Settings > Users.

Inviting Someone

Inviting is the only way to add a member. Invitations start from a Party record, so workspace access is tied back to an approved person or external contact in your organization records. There is no direct create-account-for-someone-else flow inside the product.

To invite:

1. Open Settings > Users.
2. Select the Party to invite.
3. Pick the primary role they should have. See Roles & Permissions for what each role can do.
4. Enter the reason for the invitation and click Issue invitation.

The invite email is sent to the selected Party’s primary email address. If mail is not configured, the invitation will appear in the users list but no email will be delivered, so the invited person will have nothing to act on.

Eligibility Checks

Invitations can be checked against governed eligibility policies before the member, membership, token, or Party link is created. Activation and role changes can also be checked before access becomes active or a different primary role is applied.

Some workspaces use an advisory launch posture so administrators can start inviting members before every eligibility policy is configured. When that happens, Novantra records and displays the risk as Allowed without applicable eligibility policy.

Stricter workspaces can require an applicable eligibility policy and fail closed unless an approved waiver allows the invite, activation, or role change.

What The Invitee Does

When the invited person clicks the link, they:

1. Choose a password.
2. Enroll in multi-factor authentication. This is required; they cannot skip it. They scan a TOTP QR code with an authenticator app and confirm a one-time code.
3. Accept the invitation and land in your workspace as an active member.

If activation eligibility is configured as fail-closed and the person is no longer eligible, acceptance is blocked until an administrator fixes the policy posture or records an approved waiver.

Email-Domain Restrictions

If your organization has set the allowed email domains setting, invitations to any other domain are rejected before the email is sent. This is useful for organizations that want to prevent admins from accidentally inviting personal email addresses. Configure it in the organization settings.

The Invitation Lifecycle

Every membership row goes through these states:

Revoked membership is terminal for that membership record. If the same Party needs access again, issue a new invitation so the previous revocation remains clear for audit.

Invitation Expiry

Invitations do not sit open forever. If a pending invitation is not accepted within the configured window, it expires and the invitee’s link stops working. You can issue a fresh invitation to the same Party if access is still needed.

Revoking A Pending Invitation

If you invited someone in error, revoke the invitation immediately. From the users list, find the pending entry and click Revoke. The link in the email stops working at that moment.

Suspending Or Revoking An Existing Member

When access should stop temporarily, suspend the membership:

1. Open Settings > Users and find the member.
2. Click Suspend.
3. Provide a reason. The reason is audited.

What happens immediately:

• They can no longer sign in to this organization.
• Their active sessions are terminated.
• Their member account and evidence history are preserved.

When the temporary issue is resolved, click Reactivate and provide a reason. Reactivation restores workspace access for the existing membership. If activation eligibility is configured, Novantra checks the membership again before restoring access.

When access should end, revoke the membership:

1. Open Settings > Users and find the member.
2. Click Revoke.
3. Provide a reason. The reason is audited.

Revocation also terminates active sessions and preserves the audit trail. It is the clean path for leavers, expired third-party access, and access granted in error.

What always stays:

• Every audit-log entry they ever generated. You can still see what they did before access was suspended or revoked.
• Any artifacts they created, such as uploaded files and form responses. Those belong to the organization, not the user.

MFA Enforcement

MFA is always required. There is no per-org switch to disable it, and there is no per-user opt-out.

• New members must enroll MFA during signup before they can reach the workspace.
• Existing members cannot turn it off.
• If a member loses their MFA device, an admin must reset their MFA from the users list. The next sign-in puts them back through enrollment.

This is intentional. The product never allows a member to bypass MFA because doing so would undermine the access evidence underneath.

Members Vs Install Admins (Sovereign)

In Sovereign there are two distinct admin populations:

• Organization admins are members of an organization with the admin role. They manage that organization, including users, roles, audit, and settings.
• Install admins are not members of any organization. They manage the install itself, including organizations, licensing, mail, and infrastructure. They cannot sign in to a workspace as a member without being explicitly invited as one.

The separation is deliberate: the people who run the infrastructure are not automatically the people who can read the data inside it.

Related

• Roles & Permissions - pick the right role when inviting.
• Mail Configuration - invitations and password resets depend on this.
• Audit Log - every invitation, acceptance, suspension, reactivation, revocation, and MFA reset is recorded.