Outline

1. Overview
   1. Document Purpose
   2. Summary
   3. Naming Conventions (Public, Invite Only, Private)
2. Setting up an Instance Type
   1. Choosing Between Them (Decision Guidance)
   2.  Public vs. Private (Invite Only) at a Glance
   3. The Instance Type Selector (Create Instance, Step 1)
3. What Is Editable After Creation
4. Primary User Flows by Instance Type
   1. Joining a Public Instance (Learner Self-Signup)
   2. Joining a Private Instance (Invitation)
   3. Managing Seats (Invite Only Instances)
5. Access and Permissions
   1. Who Can Access
   2. Where to Find It
6. Glossary of Key Terms

1. Overview

1.1 Document Purpose

This document helps admins and client-facing teams choose the right Instance Type (Public or Invite Only) when creating a new Discover Instance, and to understand what that choice means for the life of the instance.

1.2 Summary

Every learning environment on the Noodle Learning Platform (NLP) serves one of two quite different audiences:

1. an open, consumer-facing population that finds the catalog on its own, or
2. a closed, sponsored population (a company, an alumni group, a cohort) that an organization curates and pays for.

The Instance Type setting is how NLP tells these apart. It is configured once when an instance is set up and it cannot be changed later because it has major effects on course discovery, new learner account sign-up, and the payment process. Committing once keeps every downstream behavior (invitations, seats, catalogs, requests) internally consistent for the life of the instance.

When a Parent Admin creates a new Discover Instance, Step 1 of the guided form presents Instance Type with two cards: Public (anyone can join and enroll) and Invite Only (admins invite members and pay for capacity). Exactly one card must be selected to save, and the choice is written once to the instance record (instance_type API field). Instance Type controls how people discover the environment, how accounts get created, and who pays. The decision cannot be reversed after creation; there is no toggle to convert a Public instance to Invite Only or vice versa.

1.3 Naming Conventions (Public, Invite Only, Private)

The Create Instance UI labels the second options as “Public” and “Invite Only.” In documentation and everyday conversation, “Invite Only” instances are also referred to as “Private.” This article treats “Invite Only” and “Private” as the same thing.

(Do not confuse this with “Private Label,” a separate infrastructure concept referring to NLP’s ability to be branded for a partner. See Section 5, Glossary of Key Terms.)

2. Setting up an Instance Type

2.1 Choosing Between Them (Decision Guidance)

• Choose “Public” when the goal is reach: open enrollment, consumer-facing catalogs, and audiences who should be able to find and join the environment on their own.
• Choose “Invite Only” when the goal is control: a sponsoring organization defines the roster, pays for capacity through seats, and expects the environment to be invisible to outsiders.

2.2 Public vs. Private (Invite Only) at a Glance

2.3 The Instance Type Selector (Create Instance, Step 1)

Purpose: Capture the access model that will govern the instance permanently.

When Invite Only is selected, the admin user must also determine the initial number of licensed seats and the per-seat price for the environment.

3. What Is Editable After Creation

Choosing an Instance Type commits the instance to a set of behaviors for its life. Several neighboring Step 1 settings share that permanence; others remain flexible.

4. Primary User Flows by Instance Type

4.1 Joining a Public Instance (Learner Self-Signup)

Purpose: Let anyone become a learner without admin involvement.

In plain terms: A prospective learner lands on the instance’s microsite or default NLP Home, browses the catalog, and creates an account on their own. No invitation is ever needed — the environment is openly accessible by design, and the catalog itself does the recruiting.

Details: Discovery runs through the public web presence configured in Step 1 (custom microsite or default NLP Home, plus the microsite landing and courses URLs). Once signed up, the learner uses the standard NLP experience: browse, purchase where courses are priced, and access enrolled courses from their homepage.

4.2 Joining a Private Instance (Invitation)

Purpose: Give admins full control over who enters a closed environment.

In plain terms: Adding users starts with the admin, not the learner. The admin adds a person, NLP emails them an invitation, and they set a password to get in. Visitors who find the URL on their own see the instance but have no way to create an account.

Details:

• Add individually: On /members, the Add Instance Members inline form captures First Name, Last Name, Email, and Permission (role); clicking Add creates the member and triggers the invitation.
• Add in bulk: Bulk Actions → Bulk Upload Members accepts a CSV (template provided) with email, first_name, last_name, role, and send_notification_email columns.
• The invitee’s side: The invited user receives a Set Password email, creates a password, logs in, and lands on the instance home page.
• Follow-up: Bulk Actions → Resend Invitations re-sends invites to members who have Never Logged In. The first user of a new instance is automatically made an admin.
• Seat consumption: Each activated member consumes a licensed seat; new activations may be blocked when Seats Available is 0 until seats are increased.

4.3 Managing Seats (Invite Only Instances)

Purpose: Keep capacity ahead of the roster — and route payment to the right party.

In plain terms: Seats are the currency of a private instance. Admins can buy more at any time, and child discover instances can ask their parent institution to buy more on their behalf.

Details:

• Increase Seats (self-serve): From /members, the Increase Seats flow accepts Paid seats (the instance-specific per-seat price displays inline) and Free seats (no charge). Pay triggers the payment/invoice, a Successful Purchase! confirmation appears, and Seats Available increases by the purchased amount.
• Seat Requests (child → parent): child discover instance admins can generate seat requests from the Members page. Parent Admins see these in the Requests column of the Instance Table, open the Review Request modal, and either Approve and Pay or Reject Request.

5. Access and Permissions

5.1 Who Can Access

• Parent Admins: Create new Discover Instances and are the only role that makes the Instance Type selection. They also review child discover instances’ seat requests.
• Instance Admins (parent or child): Manage members, invitations, and seat purchases within their instance. They cannot change the Instance Type.
• Learners / Members: Experience the instance differently depending on its type — self-service sign-up on Public instances, invitation-based access on Invite Only instances.

5.2 Where to Find It

• Entry point: Parent Admins log in via their institution-specific NLP Discover Partner Instance.
• Navigation path: /home → Instance Table → Create Instance → Step 1: Instance Details → Instance Type card selector.
• Ongoing monitoring: The Instance Table on /home shows each instance’s Seats count and a Requests link (blue when open requests exist). Member and seat management lives at /members.

6. Glossary of Key Terms