> ## 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 new for networks or districts

> What changes for partners deploying apps across networks of organizations in the latest Playlab update.

<Note>
  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).
</Note>

If you are a network operator, a foundation, or a curriculum org running Playlab in many classrooms across many districts, this update was built with your workflow in mind. Multi-org deployment, segmented activity, and Collections replace the old remix-per-deployment pattern.

## At a glance

1. Apps deploy across organizations from a single source. Update once, propagate everywhere.
2. Activity stays segmented by org and workspace, so partners see network-wide data without crossing privacy lines.
3. Collections let you bundle a curated set of apps and share them as a single resource.

## Deploy apps at scale

Previously, deploying a curated app to a network of partner schools meant remixing the app into each district's workspace. A 30-school network meant 30 remixes. Every update meant doing it again.

Playlab now introduces direct sharing across organizations. From the Share modal on any app, you type the destination organization, set permissions, and send. The recipient adds the app to their workspaces and uses it. When you publish a new version, everyone with access gets the update.

For the full sharing workflow, see [Sharing with groups and orgs](/features/Sharing%20with%20Groups%20and%20Orgs).

## Activity is segmented

A common concern before: if students from many districts are using the same app, can a partner see usage data without seeing private student information from other partners' districts?

Playlab segments activity by organization and workspace. As the partner who shared the app, you see aggregate usage across all the districts you shared with. Each district sees only its own activity. Privacy lines stay where they should be.

For more, see [Reviewing student activity per class](/getstarted/Reviewing%20Activity).

## Collections

A Collection is a curated set of apps that you share like a single resource. Build a Collection once, add the apps you want included, share it with a partner organization, and that organization gets the whole bundle.

Collections solve a problem that came up again and again: "I want to give this district a starter pack of seven apps for their teachers, but I do not want to remix seven apps into seven workspaces."

For the deeper guide, see [Share with Collections](/features/collections/What%20are%20Collections) and [Creating and sharing a Collection](/features/collections/Creating%20and%20Sharing%20a%20Collection).

## Updates propagate

A point worth highlighting on its own.

Previously, an app update lived in the app's source workspace. To propagate the update to remixed copies, the partner had to re-remix or push changes manually. In practice, most copies drifted.

Now, the canonical app has one source of truth. When the owner publishes a new version, every workspace and Collection using the app sees the update on the next load. There is no separate update step.

## What stays the same

The app builder, references, prompts, model selection, and conversation flow all carry over. The change is in how content travels across the network.

## FAQ

<AccordionGroup>
  <Accordion title="Can a partner add their own apps to a Collection I shared with them?">
    The recipient sees the apps in the Collection but cannot modify the Collection itself. They can use the apps in their workspaces and combine them with their own apps and Collections.
  </Accordion>

  <Accordion title="Do permissions cascade from the Collection to the apps inside?">
    Yes. Permissions you grant on a Collection apply to the apps in that Collection. If you remove access to the Collection, access to the contained apps is removed too.
  </Accordion>

  <Accordion title="How does activity work for cross-org sharing?">
    You see aggregate stats across the orgs you shared with. Each org sees only its own activity. Personally identifiable student information stays inside each org.
  </Accordion>

  <Accordion title="Where is migration support for partners?">
    Coordinated with the Playlab team. The migration meeting walks you through what changes for your specific deployment. See [Migrating to the new Playlab](/whatsnew/Migration%20Guide) for the self-serve overview.
  </Accordion>

  <Accordion title="Can I see usage data without logging into each partner org?">
    Yes for the apps and Collections you've shared. Each recipient org's activity rolls up to your view as the source. You see aggregate, not personally identifiable, data.
  </Accordion>

  <Accordion title="How do I onboard new partners to my network?">
    Share your starter Collection with the new org and walk them through the [Migrating to the new Playlab](/whatsnew/Migration%20Guide) guide if they're coming from the previous version, or [Getting started](/getstarted/Getting%20Started) if they're brand-new.
  </Accordion>

  <Accordion title="Can I template an org structure for new partners?">
    Org templates are on the roadmap. Today, the closest path is to share a Collection of starter apps so new partners have a known starting point.
  </Accordion>
</AccordionGroup>

***

Last updated: 06-01-2026

Contact us at [support@playlab.ai](mailto:support@playlab.ai)