> ## Documentation Index
> Fetch the complete documentation index at: https://docs.praxis-ai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Enrollment & Joining Policies

> Control who can join your Digital Twin, how they sign up, and whether they can switch between instances.

Every Digital Twin in Pria sits behind an **enrollment policy** that decides who can sign up, how they get in, and whether they stay locked to that single instance. This page covers the available joining modes, the Admin-approval gate, guest access, and the self-service signup flow.

## Joining policy modes

The primary control is the **Allow Joining** mode on the Digital Twin. It has three values, each tuned for a different kind of audience.

<CardGroup cols={3}>
  <Card title="Disabled" icon="lock">
    No self-service joining at all. Users only get in if an Admin explicitly adds them. Use this for private, invite-only Digital Twins.
  </Card>

  <Card title="Account-Only" icon="building">
    Anyone whose email matches the Account's authorized domains can join. Ideal for a school, company, or organization with a known email domain.
  </Card>

  <Card title="Public" icon="globe">
    Anyone with the public link can join. Use this for community Digital Twins, public-facing assistants, and open courses.
  </Card>
</CardGroup>

Pick the mode in **Admin → Configuration** under **Joining**.

<Note>
  Account-Only matches the new user's email domain against the list configured on the parent Account. If the Account has no domain list, "Account-Only" effectively behaves like Disabled — only Admin-added users get in.
</Note>

## Admin-only joining toggle

Independent of the joining mode above, you can flip on **Joining Admin Only** to require Admin approval on every signup — even on a Public link.

<Steps>
  <Step title="User clicks Join">
    The candidate completes the standard signup form. Their record is created with status `pending`.
  </Step>

  <Step title="Admin gets an email">
    The instance contact email receives a "Membership Request" notice with a one-click approval link.
  </Step>

  <Step title="Admin approves">
    The user's status flips to `active`. They receive a "Joining Approved" email with a link to start using the Digital Twin.
  </Step>
</Steps>

<Tip>
  Combine **Allow Joining: Public** with **Joining Admin Only: ON** to publish a join URL anywhere (newsletter, website, syllabus) while keeping a human in the loop before anyone gets in.
</Tip>

## Guest mode

For public-facing demos and marketing pages, you can enable **Guest UI** so visitors can interact with the Digital Twin without signing up at all.

<CardGroup cols={2}>
  <Card title="No account required" icon="user-secret">
    Visitors land on a simplified UI and can converse immediately. Their session is not tied to a persistent user record.
  </Card>

  <Card title="Capped session" icon="hourglass">
    Guest sessions are intentionally limited so that anonymous traffic cannot drain the instance's credit pool. Encourage visitors to sign up for a full experience.
  </Card>
</CardGroup>

Guest mode is enabled in **Admin → Configuration** under **Guest UI**. Leave it off unless your Digital Twin is intended for unauthenticated visitors.

## Preventing instance switching

By default, a user who belongs to multiple Digital Twins can switch between them from a menu in the UI. For some deployments — branded apps, focused classroom experiences, embedded assistants — you want the user pinned to a single Digital Twin.

<Card title="Lock users to one instance" icon="lock">
  Enable **Prevent Switching Instance** in **Admin → Configuration**. The instance switcher disappears from the UI for users of this Digital Twin. They will only see this one Digital Twin no matter how many memberships they have.
</Card>

<Warning>
  This is a per-instance setting. If a user belongs to two Digital Twins and only one has the lock enabled, the lock applies only when they are inside that Digital Twin.
</Warning>

## Self-service signup flow

When a user joins via a public or account-domain link, Pria runs them through a short flow before dropping them into the Digital Twin.

<Steps>
  <Step title="Email verification">
    A one-time activation link is emailed. The user must click it to confirm the address. The account is not active until they do.
  </Step>

  <Step title="Onboarding Questions">
    If the Digital Twin has [Onboarding Questions](/mdx/admin-guide/onboarding-questions) configured, the user answers them here. Their responses are stored and available to assistants for personalization.
  </Step>

  <Step title="Personalization gate">
    The first time a user enters the Digital Twin, they are asked the [Personalization](/mdx/admin-guide/personalization) prompts that build their initial user profile.
  </Step>

  <Step title="In the Digital Twin">
    The user lands in the main UI with their profile, preferences, and any awarded credits already in place.
  </Step>
</Steps>

## Email verification and activation

All self-service signups require a verified email. The activation email is sent immediately on signup and contains a single-use link.

<Info>
  If the activation email is missing, check the user's spam folder, then verify in **Admin → Users** that the email address on file is correct. Admins can re-send the activation link from the user's record.
</Info>

A user whose email is never activated remains in the `pending` state. They cannot sign in until the link is clicked or until an Admin manually activates them.

## Contact email auto-promotes to Admin

The Digital Twin record carries a **Contact Email**. When the user whose email matches that contact email signs in for the first time, Pria automatically promotes them to the **Admin** role on the Digital Twin.

<CardGroup cols={2}>
  <Card title="Why this exists" icon="key">
    It lets the platform bootstrap a brand-new Digital Twin: set the contact email to whoever should own it, hand them the link, and the first time they sign in they get the Admin permissions they need.
  </Card>

  <Card title="What it means in practice" icon="circle-info">
    Treat the **Contact Email** as the keys to the Digital Twin. Anyone who can sign in with that address becomes an Admin on first sign-in.
  </Card>
</CardGroup>

<Warning>
  Update the **Contact Email** carefully. Setting it to an unverified or shared address effectively grants Admin to whoever controls that mailbox.
</Warning>

## LMS launches bypass joining policy

Users who arrive via an LMS launch — Canvas, D2L Brightspace, or any other [LMS-supported](/mdx/user-guide/lms/user-auth) tool — **bypass the joining policy entirely**.

<CardGroup cols={2}>
  <Card title="Why" icon="graduation-cap">
    The LMS has already authenticated the user and asserted their identity. Re-asking them to sign up would break the launch flow and confuse students.
  </Card>

  <Card title="Implication" icon="triangle-exclamation">
    Even with **Allow Joining: Disabled**, an LMS launch from a configured course will still create a membership and grant access. Restrict the LMS configuration if you need to limit which courses can launch.
  </Card>
</CardGroup>

<Note>
  LMS-launched users land directly in the Digital Twin with the role configured on the LMS integration. They can still go through Onboarding Questions and the Personalization gate, but they skip the email-verification step.
</Note>

## Related

* [Users](/mdx/admin-guide/users) — managing memberships and roles
* [Entitlements](/mdx/admin-guide/entitlements) — granular Admin permissions
* [Onboarding Questions](/mdx/admin-guide/onboarding-questions) — what new joiners are asked
* [Configuration](/mdx/admin-guide/configuration) — Digital Twin settings reference
* [Personalization](/mdx/admin-guide/personalization) — first-run personalization prompts