# Working across a group


> Moving between workspaces, moving a screen, and getting the same content onto screens in several of them.
Linking changes billing. Day to day, the workspaces behave exactly as they did before, which is what most of this page is about.

## Moving between them

The workspace switcher, and the [lobby](/docs/account/signing-in/the-lobby/) when you sign in. You only see the workspaces you are a member of, so being an Owner of the parent does not put the children in your list.

If you administer the whole group, you have to be a member of each one. That is deliberate, and it means adding somebody to the group is still a per-workspace invitation.

## Moving a screen between them

Supported, with the usual caveats: you need Owner or Admin in both, settings come across, **playlist assignments do not**, and the screen arrives disabled.

Linking does not change any of that. See [Move a screen to another workspace](/docs/screens/managing/transfer-a-screen/).

The license side is simpler in a group, though. Both workspaces draw on the same pool, so moving a screen does not free a license in one place and consume one somewhere it might not be available.

## Getting the same content into several workspaces

This is the thing people expect linking to solve, and it does not.

Use a [shared playlist](/docs/workspaces/reference/sharing-between-workspaces/). One workspace owns the content, shares the playlist, and each other workspace decides which of its own screens play it. Update it once and every workspace showing it follows.

That works between any two workspaces on Enterprise, linked or not. It is the right tool for brand-controlled content across regions.

## What still has to be done per workspace

Members and roles. Branding. Integrations. Notification destinations. Labels.

None of these inherit from the parent. A new child is a blank workspace with a funded license pool, so budget setup time per workspace rather than assuming the group carries its configuration.