> ## Documentation Index
> Fetch the complete documentation index at: https://learn.playlab.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# What's changed
> For people coming from the previous version of Playlab: what stayed, what changed, and what you can do now that you couldn't before.
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](/getstarted/Overview) or [Feature Documentation](/features/Overview).
If you used Playlab before this update, this page is your first stop. It answers two questions side by side: what changed in your existing workflows, and what you can do now that wasn't possible before.
For the workflow-by-workflow side-by-side, see the [workflow cheat sheet](/whatsnew/Workflow%20Cheat%20Sheet). For the rationale, see [What's new](/whatsnew/What's%20New).
## What stays the same
Migration preserves what was already working.
* Your apps move with the same prompts, references, model selection, and starter inputs
* App owners are preserved
* Workspaces keep their names, members, and apps
* Voice and dictation carry over
* Conversation history is retained and queryable
* References at the org, workspace, and app level all carry over
* Integrations (SSO, rostering) keep working
* Activity history stays in place
* Old URLs continue to redirect to the current paths, so bookmarks, LMS embeds, and class materials keep resolving
## What changed
The structure of how content lives changed. The content itself did not.
| Previously | Now |
| -------------------------------- | ------------------------------------------------------------------------------ |
| Workspace > Members > Add Member | Workspace > Members > **Add Members** or **Create Invite Link** |
| Workspace > Apps > New App | Org or Workspace > **New App** |
| App > Publish > Pick visibility | App > **Share** > Publish toggle and visibility selector |
| Workspace > Activity | Workspace > Activity (segmented per class) or Org > Activity (cross-workspace) |
| Remix to deploy | App > **Share** > target org or **Add to Workspace** in another workspace |
| Curated bundles by remixing | Org > **Collections** > New Collection |
| Workspace creator collaboration | App > **Share** > add as Editor |
For the full mapping, see the [workflow cheat sheet](/whatsnew/Workflow%20Cheat%20Sheet).
## What you can do now (couldn't before)
Six capabilities are new. Each one solves a problem partners ran into often. Here's the shape of the change at a glance:
| Capability | In V1 | In V2 |
| ----------------------------- | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| Keep an app private | Every new app was visible to the whole workspace from day one | New apps start private to you and your org's admins until you share or publish |
| Share edit access on one app | Only by adding the peer to your workspace, which gave them edit on every app in it | Add a peer as Editor (or Viewer) on a single app — nothing else |
| Use one app in many classes | Remix the app into each class; copies drifted | Add the same app to as many workspaces as needed — single owner, activity per class, one update reaches all |
| Share an app with another org | Only by remixing it into the recipient org | Type the destination org in the Share modal, set permissions, send; updates flow automatically |
| Share a curated set of apps | Remix each app into each district's workspace | Build a Collection once and share the bundle; updates propagate to every recipient |
| Monitor across the whole org | Walk each workspace one at a time | Org-level dashboard of flags and activity, filterable by workspace, app, member, and date |
| Control what members can do | One shared workspace mode (everyone builds or no one does) | Three per-workspace toggles: build apps, see each other, share beyond the workspace |
**Editor sharing on a single app.** Add a peer as Editor on one app and they can edit that app only. They don't get access to your other apps or your workspace. Previously, the only way to grant edit access was through workspace membership, which over-shared. See [Collaborating on an app](/getstarted/Collaborating%20on%20an%20App).
**One app in many classes (no remixing).** Add the same app to as many workspaces as you need. The app keeps a single owner. Activity stays segmented per class. When the owner publishes a new version, every class using the app sees the update. Previously, this required remixing the app per class and copies drifted. See [Using an app across multiple classes](/features/Cross-Workspace%20App%20Use).
**Direct sharing with another organization.** From the Share modal, type the destination organization, set permissions, send. Cross-org sharing is a first-class flow. Previously, the only path was remixing into the recipient org. See [Sharing with groups and orgs](/features/Sharing%20with%20Groups%20and%20Orgs).
**Collections for curated bundles.** Build a Collection of apps once, share it with a partner organization, and that organization gets the whole bundle. Updates propagate. Previously, this required remixing each app into each district's workspace. See [Share with Collections](/features/collections/What%20are%20Collections).
**Centralized flag review.** All flagged messages from across an organization surface in one dashboard. Filter by workspace, severity, member, or date. Previously, finding flags meant walking every workspace. See [Centralized org monitoring](/features/Reviewing%20App%20Activity).
**Workspace building permissions.** Three toggles per workspace: members can build apps, members can see each other, members can share beyond the workspace. Set them to match the class. Previously, workspaces had one shared mode (everyone builds or no one does). See [Workspace building permissions](/getstarted/Workspace%20Building%20Permissions).
## Privacy as a default change
Now, every new app starts private. You and your org's admins can see it. Nobody else, until you share or publish. Previously, an app you created was visible to everyone in the workspace from day one. The default flipped.
Org admins keep visibility for trust and safety reasons. The default is private from peers and members of your workspaces unless you share. See [App privacy and visibility](/features/App%20Privacy%20and%20Visibility).
## Where to next
What to do before, during, and after the migration window.
Every common workflow with before-and-after columns.
For role-specific overviews, see [What's new for Builders](/whatsnew/What's%20New%20for%20Builders), [What's new for Educators](/whatsnew/What's%20New%20for%20Educators), [What's new for Admins](/whatsnew/What's%20New%20for%20Admins), and [What's new for Networks or Districts](/whatsnew/What's%20New%20for%20Networks%20or%20Districts).
## FAQ
Yes. Old URLs redirect to the current paths. Bookmarks, LMS embeds, and class materials should keep resolving.
No. The basics work the same. The new capabilities (Collections, cross-workspace, centralized monitoring) become available after migration. Read at your own pace.
The Playlab team is the first stop. Email [support@playlab.ai](mailto:support@playlab.ai), or drop into Office Hours for real-time questions.
***
Last updated: 06-17-2026
Contact us at [support@playlab.ai](mailto:support@playlab.ai)