Skip to main content
This guide is for people coming from the previous version of Playlab. It will be retired in August 2026 once everyone has migrated. For current Playlab guidance, see Learn on Your Own or Feature Documentation.
If you read another doc and hit a term you do not recognize, look it up here. Each entry links to the page where the term is used in depth.
Some role names may shift between this draft and launch. Confirm with your org admin if a name does not match what you see in the product.

Containers

The four places content lives in Playlab. Organization (Org) The top-level container. Usually a school, district, university, or partner. Holds workspaces, members, collections, and policies. Most people belong to a single organization. See Navigating Playlab. Workspace A class, team, project, or group inside an organization. A workspace has its own members, apps, activity, and building permissions. Workspaces are created by educators and admins. App A Playlab app. Lives in a single workspace as its home, but can be added to other workspaces and to collections without being remixed. Each app has one owner and any number of editors and viewers. Collection A curated set of apps you can share like a single resource. Useful when you want to bundle several apps for a partner, a curriculum unit, or a starter pack. Updates propagate to everyone with access. See Share with Collections.

Roles

Who can do what. Org Owner Manages the entire organization. Sees all workspaces, all member activity, and all flagged messages. Can change member roles and configure org-level settings. This is the all-access org role. (Distinct from a Workspace Owner, which governs a single workspace.) Workspace Owner The workspace creator by default. Can do everything a Facilitator can — add and remove members, change permissions, add apps, review activity — plus delete the workspace. See Workspace roles and permissions. Workspace Facilitator Manages a single workspace without the ability to delete it. Can add and remove members, change permissions, add apps, and review activity for everyone in the workspace. Workspace Participant A person who uses a workspace. Can use the apps shared in the workspace and, depending on building permissions, may also create or share their own apps. App Owner The person who created an app. Owns the app, controls who can edit, and decides what to publish. Editor A person you have shared an app with at the editor level. Can edit the app’s instructions, references, and settings. Cannot reassign ownership. See Collaborating on an app. Viewer A person you have shared an app with at the viewer level. Can use the app but not change it.

Capabilities

Things you do in Playlab. Sharing Granting access to an app or collection. Done through the Share modal. You can share with individuals, groups, or organizations and pick a permission level for each. See Sharing with individuals and Sharing with groups and orgs. Publishing Making an app available beyond direct sharing. Publishing happens from the app builder or the Share modal and lets you set a visibility level. See Publishing your app. Privacy by default Now, every new app is private to the owner and the org’s admins until the owner shares or publishes it. This replaces the old default of “visible to the workspace.” See App privacy and visibility. Building permissions Workspace-level toggles that control whether students can build apps, see each other’s work, or share apps beyond the workspace. Set on workspace creation and editable later. See Workspace building permissions. Activity The record of who used an app, when, and what conversations took place. Available at the workspace level, the member level, and the org level. See Reviewing student activity per class. Flags A flagged message is a conversation that triggered a safety or moderation rule. All flags from across the org are surfaced in a centralized dashboard for org admins. See Centralized org monitoring. Cross-workspace use Adding the same app to multiple workspaces without remixing. Activity stays segmented per workspace, and updates flow from the original app. Replaces the old “remix per class” pattern. See Using an app across multiple classes.

Old terms that changed

Quick translation table for familiar older vocabulary.

Want a term added?

If you see a term in another doc that should be defined here, email [email protected] and we will add it.
Last updated: 06-26-2026 Contact us at [email protected]