> ## 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.

# Using an app across multiple classes

> How to use a single Playlab app in several spaces without remixing, with activity segmented per class.

<div className="pl-badges">
  <span className="pl-badge pl-badge--new">New</span>
</div>

You can add the same app to as many spaces as you need. The app keeps a single owner and source of truth. Activity stays segmented by space, so each class sees only its own. When the owner publishes an update, every class using the app sees the new version.

The app exists once. You add it to a space as a reference, and the space gets a tile for it. Members of the space can use the app, and their activity is recorded against that space. The app's source stays under the original owner.

## How to add an app to a space

<Steps>
  <Step title="Go to the space">
    Open the space where you want the app available.
  </Step>

  <Step title="Open the Apps tab">
    The tab lists apps already in the space and a button to add more.
  </Step>

  <Step title="Click Add Apps">
    The Add Apps modal opens with a search field and a list of apps you have access to.
  </Step>

  <Step title="Select an existing app">
    Pick the app from the list or search by name. Apps from your org, apps shared with you, and apps in Collections you have access to all appear here.
  </Step>

  <Step title="Confirm">
    The app shows up in the space's Apps tab. Members can use it from their dashboard.
  </Step>
</Steps>

To add the same app to another space, go to that space and repeat the steps.

## Activity is segmented per class

Each space where the app is added keeps its own activity log. A teacher running three sections of the same class sees three separate activity views, one per space. Org admins can see across spaces, but teachers stay scoped to their classes.

```mermaid theme={null}
graph TD
 App["✏️ One app<br/>(owned by you)"]
 WS1["📁 Class A"]
 WS2["📁 Class B"]
 WS3["📁 Class C"]
 Act1["📊 Activity A"]
 Act2["📊 Activity B"]
 Act3["📊 Activity C"]

 App -.added to.-> WS1
 App -.added to.-> WS2
 App -.added to.-> WS3
 WS1 --> Act1
 WS2 --> Act2
 WS3 --> Act3

 classDef app fill:#a4beeb,stroke:#0c0f14,stroke-width:2px,color:#0c0f14
 classDef ws fill:#fbf9f6,stroke:#0c0f14,stroke-width:1px,color:#0c0f14
 classDef act fill:#feffa0,stroke:#0c0f14,stroke-width:1px,color:#0c0f14
 class App app
 class WS1,WS2,WS3 ws
 class Act1,Act2,Act3 act
```

*One app, three classes, three separate activity views. Each teacher sees only their class.*

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

## Updates propagate automatically

When the app's owner publishes a new version, every space using the app sees the update on the next load. Conversations from prior versions are preserved. New conversations use the latest version.

This is the biggest reason cross-space use replaced remixing for most teachers. A small fix or a curriculum update no longer needs to be copied into ten places.

## When to remix anyway

Cross-space use covers most cases. Remixing still makes sense in a few:

**Heavy customization.** If you want to substantially change the prompt, references, or starter inputs for one class, remix. The original app stays clean.

**Frozen-in-time pedagogy.** If you want a class to use the app exactly as it was at a point in time, even if the owner ships updates, remix. Your copy is independent.

**Learning the prompt.** Students learning to build apps often remix as a way of seeing how an app is built. The remix is for teaching, more than for production deployment.

For most other cases, adding the app to the space is the simpler path.

## Key points

<Info>
  * Add the same app to as many spaces as you need; no remixing
  * Activity is tracked separately in each space
  * Updates from the owner reach every space automatically
</Info>

## FAQ

<AccordionGroup>
  <Accordion title="Can students see each other across classes?">
    No. Each space's activity is visible only to its own members and managers, plus org admins. A student in section A does not see what a student in section B is doing with the same app.
  </Accordion>

  <Accordion title="Does this replace remixing entirely?">
    For deployment, mostly. For pedagogy and customization, no. Remixing is still useful for the cases above.
  </Accordion>

  <Accordion title="Who sees the activity?">
    Space members can see their own activity. Space owners and facilitators see all activity inside the space. Org admins see activity across all spaces in the org. Cross-space patterns require admin access.
  </Accordion>

  <Accordion title="What if the original app is unpublished or deleted?">
    Spaces using the app see a "no longer available" state. Activity history is preserved. The space owner can remove the tile or wait for the original app to come back online.
  </Accordion>

  <Accordion title="Can I remove the app from a space later?">
    Yes. From the Apps tab, click the app and choose **Remove from Space**. The app is no longer available in that space. Activity stays in the space's history. The original app is unaffected.
  </Accordion>

  <Accordion title="If I update the app, do all classes get the update at the same time?">
    Yes. The next time anyone opens the app in any space, they see the latest version.
  </Accordion>

  <Accordion title="Does cross-space use count against any quota?">
    No. Adding an existing app to a space doesn't count toward your space's app limit. Only apps you create count.
  </Accordion>
</AccordionGroup>

***

Last updated: 06-01-2026

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