Sub-workspaces

A parent workspace can hold sub-workspaces: separate workspaces for a team, a site, a region or a client, each with its own simulations, people and settings. The parent stays a working workspace in its own right, and its owners and admins run the whole group from it: one plan, one set of seats, one credit pool, content sent or mirrored to every sub-workspace, and usage reported by workspace so each one can be recharged for its share.

Sub-workspaces are part of the Enterprise plan. If your organization is on Enterprise and has workspaces that should join the group, ask devlin.ai support to attach them (see Attaching an existing workspace, and detaching).

What a sub-workspace is

• A sub-workspace is an organization workspace that belongs to one parent workspace. It has its own simulations, coaches, Brain, results and people.
• There is one level only. A sub-workspace cannot hold sub-workspaces of its own, and a personal workspace can be neither a parent nor a sub-workspace.
• A sub-workspace has no owner of its own. The parent workspace is its owner.

How a sub-workspace is created

Owners and admins of the parent workspace create sub-workspaces themselves. In the parent workspace, open Settings, then Sub-workspaces, and select Create sub-workspace.

• The parent workspace must be an organization workspace that is not itself a sub-workspace, on a plan that includes sub-workspaces. devlin.ai can also turn sub-workspaces on for a workspace on another plan, for example for a pilot. On a plan without sub-workspaces, the Sub-workspaces section shows "Sub-workspaces are available on the Enterprise plan." and creating is off.
• A new sub-workspace starts with the parent workspace's plan. It is empty, apart from anything the parent workspace sends to sub-workspaces added later (see Sending content to sub-workspaces).
• The parent workspace's owners and admins see it in the workspace switcher straight away. Nobody else is added to it.
• The Sub-workspaces section lists every sub-workspace with how many people it has. Search by name. Long lists show 25 sub-workspaces a page.
• To rename a sub-workspace, select Rename next to it, change the name and select Save. Its people, content and results stay as they are. An archived sub-workspace cannot be renamed.
• A parent workspace cannot be deleted while it still has sub-workspaces. Ask devlin.ai support to remove them first.
• Deleting your account is refused while you own a parent workspace that still has sub-workspaces, or while a sub-workspace is still tied to your account (for example, one created while you owned its parent workspace). You see "Your account is still tied to sub-workspaces. Ask devlin.ai support to remove the sub-workspaces first." followed by the names of those workspaces, and nothing is deleted.
• When ownership of a parent workspace moves to someone else, its sub-workspaces move with it.

Attaching an existing workspace, and detaching

The devlin.ai team can also make a workspace you already have into a sub-workspace, or turn a sub-workspace back into a workspace of its own. Ask devlin.ai support, naming both workspaces.

An existing workspace can be attached only when:

• it is an organization workspace, not a personal one, and has no sub-workspaces of its own;
• it has no subscription or plan of its own still running (cancel or end it first);
• everyone in the group fits the parent workspace's seats once it joins. A person in both counts once;
• if it has its own single sign-on connection, that connection is not enforced and uses the same identity provider as a connection the parent workspace already has. Otherwise devlin.ai support asks you to turn off enforcement and move it to the parent workspace's identity provider, or to remove the connection, first. This keeps anyone from being locked out of the parent workspace or of the sub-workspace when it joins.

When it is attached, in one step:

• Its remaining credits move into the parent workspace's balance, keeping their expiry dates. Both workspaces' credit history shows the move.
• It spends credits the way the parent workspace's default says, and its plan follows the parent workspace.
• Its owner becomes an admin: the parent workspace's owners and admins are its owners from then on. Its other admins and members keep their roles.
• If it had its own single sign-on connection, the connection is removed and its email domains are added to the parent workspace's connection for the same identity provider.
• Its simulations, coaches, results and history stay where they are.

Detaching is also done by devlin.ai support; there is no setting for it in the app. Ask devlin.ai support, naming the sub-workspace and the member who should become its owner. When a sub-workspace is detached:

• Any credits allocated to it go back to the parent workspace first, so it leaves with no credits, on the Free plan.
• Its admins choose a new owner from its active members, and devlin.ai support makes that person its owner.
• The parent workspace's owners and admins no longer have access to it, unless they are its own members.
• Limits set by the parent workspace no longer apply to it.
• Its mirrors become ordinary copies it can edit. They are no longer updated from the parent workspace, and they no longer stop the parent workspace from deleting or archiving the originals.
• Email domains that were added to the parent workspace's single sign-on connection when it was attached stay there. devlin.ai support removes them if its people should no longer sign in through the parent workspace's identity provider.

Who can open a sub-workspace

• The parent workspace's owners and admins are owners of every sub-workspace. They can open any sub-workspace from the workspace switcher without being invited to it.
• In the workspace switcher, sub-workspaces are listed under their parent workspace. The parent workspace's row shows its plan and "Parent workspace" instead of a credit balance, and each sub-workspace row shows only its name, because its plan and credits follow the parent workspace. Once you have more than 8 workspaces, a search box at the top of the switcher finds one by name.
• Members of the parent workspace do not get access to its sub-workspaces.
• A sub-workspace's own admins and members see only that sub-workspace, not the parent or the other sub-workspaces.
• A sub-workspace has no billing of its own. Its plan follows the parent workspace, and billing is managed in the parent workspace.

Inviting people and seats

• A sub-workspace's own admins can invite people to that sub-workspace. They cannot invite anyone to the parent workspace or to another sub-workspace.
• The parent workspace's owners and admins can invite people to the parent and to any sub-workspace.
• The parent workspace's seats are the total for the whole group: the parent and every sub-workspace. A sub-workspace has no seats of its own.
• A person counts once, however many workspaces of the group they belong to. Inviting someone who is already in the group, or already invited to it, takes no extra seat.
• A pending invitation holds a seat until it is accepted, cancelled or expires.
• When every seat is in use, a new invitation is refused. The message gives the parent workspace's seat count and asks you to remove a member or pending invitation, or contact us to add seats.

Single sign-on

• A single sign-on connection set up on the parent workspace covers every sub-workspace. When the parent requires single sign-on, so does every sub-workspace.
• People are invited to a specific workspace first. When they sign in with single sign-on, they join every workspace in the group they were invited to, and they start in the workspace they were invited to most recently.
• Signing in with single sign-on without an invitation adds nobody to the parent workspace or any sub-workspace, even when the email domain matches. The person sees "You have not been invited to a workspace yet. Ask your administrator for an invitation." and can still use their own workspace.
• Someone already in a workspace of the group signs in as usual.
• Single sign-on joins take seats from the parent workspace's seat count, the same as invitations.

Archiving a sub-workspace

Removing a sub-workspace archives it. Nothing in it is deleted. In the parent workspace, open Settings, then Sub-workspaces, and select Archive next to the sub-workspace. A dialog titled with the sub-workspace's name asks you to confirm. Select Archive sub-workspace to go ahead.

• The sub-workspace's own admins and members lose access to it straight away, and its pending invitations are cancelled.
• Its simulations, coaches, evaluators, journeys and hosted projects stop loading for learners, wherever they are embedded or linked.
• Nobody can open it or act in it any more, including the parent workspace's owners and admins, and MCP connections to it stop working.
• Its results and credit use stay, so reports for the period it was active still include it.
• Any credits it holds, such as credits allocated to it, go back to the parent workspace, keeping their expiry dates.
• An archived sub-workspace no longer appears in the workspace switcher. It stays in the Sub-workspaces section, listed after the active ones and marked Archived.

Usage and billing reports

The parent workspace's owners and admins see a Sub-workspaces tab in Results. It shows what each sub-workspace used, so you can recharge each one for its share.

• By workspace is the charge review: one row for the parent workspace and one for each sub-workspace, with credits used, share of total, sessions, unique learners, average credits per session, pass rate, and credits by type (learner practice, voice, video avatars, building with devlin, other). A totals row sums the rows shown. The parent workspace's row is always first, whatever the sort, and is shaded.
• The last two by-workspace columns show how each sub-workspace spends credits as it stands today, whatever dates you pick (see Credits). Spending now is Draw freely, Monthly cap or Allocated. Cap or allocation now shows, for a capped sub-workspace, the credits counted against its cap this month (UTC) out of the cap, or "No cap set"; for an allocated one, the credits it holds. Both are a dash for the parent workspace, an archived sub-workspace and the totals row.
• Sessions are simulation and coach sessions. Pass rate covers scored simulation evaluations and evaluator results. Both views count them the same way. The Video avatars column holds all the credits of a voice session that connected a video avatar, voice minutes included, and those credits are not in the Voice column.
• By content lists each original simulation, coach, evaluator and journey with its totals across the group. Open a row to see one line per workspace: the original, each mirror, and each edited copy.
• Credits come from what was actually spent, so the charge review always matches your usage. A sub-workspace that was removed still appears, marked archived, for any period in which it used credits, ran sessions or had evaluations.
• The report opens on the previous calendar month (UTC). Pick other dates with From and To (Last month returns to the default), search by workspace name or content title, and sort by any column except Link in the By content view.
• Select a sub-workspace's name to switch to it and open its own Results. Selecting the parent workspace's name opens its Results.
• Export CSV downloads the report with the same view, dates, search and sort as the screen. The by-workspace file adds a Status column (Parent workspace or Archived) in place of the badges, and the by-content file lists every workspace line under each original, expanded on screen or not.
• Ask devlin, or an AI agent connected over MCP, can read both reports for you while you are in the parent workspace.
• Members of the parent workspace, and people in a sub-workspace, do not see these reports.

Credits

A sub-workspace has no credits to buy. It spends the parent workspace's credits in one of three ways, chosen by the parent workspace's owners and admins:

• The parent workspace sets a default for every sub-workspace, and can give any sub-workspace its own setting. New sub-workspaces use Draw freely until the default is changed.
• A capped sub-workspace needs a monthly cap greater than zero, its own or the default one. A cap counts credits held by sessions still running as well as credits already spent, so two sessions at once cannot go over it. The count starts again on the first day of each month (UTC).
• Allocating moves credits from the parent workspace into an allocated sub-workspace. Returning moves them back. The credits keep their expiry dates both ways, and neither balance can go below zero. A sub-workspace must hold no allocated credits before it stops being allocated: return them first.
• Changes apply from the next session. A session already running keeps the credits it held when it started; what it does not use is returned to the workspace that pays under the setting in force when it ends.
• The parent workspace's own sessions always spend its own balance.

Where to manage sub-workspace credits

Owners and admins of the parent workspace open Settings, then Sub-workspaces, in the parent workspace. Settings next to a sub-workspace opens its page, where you change how it spends, see what it has used this month or can spend now, allocate or return credits, and set its limits. Credit and limit defaults for every sub-workspace opens the group's page, which sets the defaults and lists every sub-workspace with Manage for each. The same group page is also reached from Settings → Credits & Billing with Manage sub-workspace credits. All sub-workspaces at the top of either page goes back to the list. A sub-workspace's own admins cannot change any of this.

In a sub-workspace, Settings → Credits & Billing shows how it spends, what it can spend now, and for a capped one how much of the month's cap it has used. It has no purchase, plan or receipt actions.

Credit alerts in a group

• When the parent workspace's balance drops below one of its alert thresholds, its owners and admins are alerted, whichever workspace spent the credits. A sub-workspace that spends the parent's credits has no low-credit alerts of its own.
• When a capped sub-workspace has spent 80% of its monthly cap, and again when it reaches the cap, its admins and the parent workspace's owners and admins are alerted, once each per month.
• When an allocated sub-workspace's balance drops below one of its own alert thresholds, or a session is declined because it ran out, its admins and the parent workspace's owners and admins are alerted.
• When a session in a sub-workspace is declined, the alert goes to whoever can fix it: the parent workspace when its balance ran out, the sub-workspace and the parent when the cap was reached.
• Each workspace's "Email workspace owners and admins for these alerts" setting applies to its own people: the parent's setting to the parent's owners and admins, the sub-workspace's to its admins.

Limits set by the parent workspace

The parent workspace's owners and admins can put limits on what a sub-workspace's own admins may set. A limit is a ceiling: the sub-workspace's admins can choose something stricter, never something looser, and cannot turn on what the parent workspace turned off.

• Limits are set on the same pages as credits. Limits for sub-workspaces on the group's page applies to every sub-workspace without limits of its own. Limits for this sub-workspace on one sub-workspace's page replaces the default for that sub-workspace only. Leave a field empty, or choose Follow the default, to have no limit of its own.
• Where the parent workspace set nothing, the sub-workspace's admins control the setting exactly as before.
• A limit applies from the next session. When the parent workspace lowers a limit below a value the sub-workspace already saved, the lower one applies from the next session, and the saved value is kept: it applies again if the limit is raised or removed.
• In the sub-workspace, each limited setting shows "Set by your parent workspace" with the value, and cannot be raised past it. A save that tries is refused with "Your parent workspace limits this setting to" and the value, or "Your parent workspace has turned this off." for a switch. devlin and AI tools connected over MCP get the same refusal.
• The parent workspace's owners and admins are owners in every sub-workspace, and can still save a sub-workspace's own setting above a limit. The limit still applies.

Sending content to sub-workspaces

The parent workspace's owners and admins can send a copy of a simulation, coach, evaluator or journey to some or all of its sub-workspaces.

• Open the item's menu in the parent workspace (for an evaluator, the Send button beside it) and choose Send to sub-workspaces. Search for and tick the sub-workspaces, or tick All sub-workspaces.
• With All sub-workspaces, you can also tick Also send to sub-workspaces added later. Every sub-workspace created or attached afterwards then receives its own copy too. Ask devlin can stop that later; copies already sent stay. Sending the same item to all sub-workspaces again with this ticked replaces the earlier send for sub-workspaces added later, and it stops by itself if the original is deleted or moved out of the parent workspace.
• Archived sub-workspaces are not sent anything.
• Each sub-workspace gets its own copy to edit. A copy arrives unpublished, with a new embed link, so publish it in the sub-workspace when it is ready. Editing a copy never changes the original, and editing the original never changes the copies.
• What the item uses comes with it: its knowledge sources, its custom character, a coach's simulations and evaluators, an evaluator's simulation, and a journey's simulations, coaches, characters and scenes, with the evaluators linked to its simulations. A journey's copy plays, branches on and scores the sub-workspace's own copies of its simulations. Only knowledge that has finished processing and custom characters that are ready come along; a copy goes without anything that is not ready yet.
• Skill tags, the audience profile and folders belong to the parent workspace and stay behind.
• Sending spends no credits.
• The dialog shows each sub-workspace as Waiting, Sending, Sent or Not sent. Copies are made in the background, so you can close it; sending to many sub-workspaces can take a few minutes. If one shows Not sent, nothing was left half made there: send again to that sub-workspace.

Mirrors

Instead of a copy, the parent workspace's owners and admins can send a mirror: a read-only version that the parent workspace keeps in sync. In the Send to sub-workspaces dialog, choose Mirror (read-only, stays in sync) under Send as.

• Each sub-workspace gets its own mirror, with its own embed link and its own results, together with what the item uses (as for a copy). A mirror is published as soon as it arrives if the original is published.
• Nobody can edit a mirror in the sub-workspace, including its owners and admins. Its editor shows "This is kept in sync by your parent workspace and can't be edited here." and saving, publishing or deleting it is refused with the same message, in the app, through devlin and through AI tools connected over MCP. A mirror cannot be moved either. It can still be filed in one of the sub-workspace's folders.
• When you publish the original again, every mirror is updated to match in the background, usually within a minute or two. If a mirror cannot be updated, for example because the original has changes that have not passed review, the list of mirrors in the Send to sub-workspaces dialog says so, and the mirror stays at its last version. For a simulation, coach or evaluator that is already published, saving it in the parent workspace also updates its mirrors, because the change is live for its own learners. A journey's mirrors follow its published version, never its draft.
• Changes to the knowledge a published original uses also reach its mirrors: a document added to or removed from a knowledge base it uses, a document that finishes processing, or a change to the documents and knowledge bases linked to it. These updates are made in the background, usually within a minute or two.
• Mirrors keep the original's review: a mirror only goes live with content that passed the same review as the original. A live mirror whose original is unpublished, or whose original has unreviewed changes, keeps its last version.
• A sub-workspace that already has a mirror of the item gets that mirror updated rather than a second one.
• Unpublishing the original leaves every mirror live at its last version, so courses that embed the mirrors keep working.
• The original cannot be deleted or archived while sub-workspaces have mirrors of it, and a mirrored simulation cannot be transferred to a workspace outside the group. The refusal names those sub-workspaces: stop or unlink their mirrors first. Moving the original between the parent workspace and one of its sub-workspaces is still allowed.
• The Send to sub-workspaces dialog lists where the item is mirrored, with two choices for each sub-workspace:
  • Unlink turns the mirror into an ordinary copy that the sub-workspace can edit. It is no longer updated from the original.
  • Stop archives the mirror in that sub-workspace. Its learners can no longer open it, and its past results stay.
  • While a mirror's sub-workspace is being updated, Unlink and Stop are refused with "This mirror is being updated right now. Try again in a minute." and nothing changes.
• Only the parent workspace's owners and admins can send, unlink or stop mirrors. Mirroring spends no credits.

Moving content between the parent workspace and a sub-workspace

The parent workspace's owners and admins can move a simulation, coach, evaluator or journey from the parent workspace to a sub-workspace, or from a sub-workspace to the parent workspace. Ask devlin to move it. A simulation can also be moved with Transfer on its menu, which the workspace's owners see.

• It keeps its embed link, so courses that embed it keep working. Its past results stay with the workspace where learners made them.
• Its knowledge sources and custom character are copied for it into the workspace it moves to. A journey brings its simulations and coaches with it, and the evaluators linked to its simulations, keeping the links between them. If moving a simulation, coach or evaluator cannot finish, nothing moves and you can try again. If a journey's move stops partway, some of its simulations or coaches may already be in the destination; try the move again.
• A journey is not moved while another journey in the same workspace uses one of its simulations or coaches. Send a copy instead.
• Content moves only between a parent workspace and its own sub-workspaces, not between two sub-workspaces. Content can be moved out of an archived sub-workspace, not into one.
• A mirror is not moved: unlink or stop it first.

Asking devlin or an AI tool

• Asking devlin to send or mirror content, move it, unlink or stop a mirror, or stop sending it to sub-workspaces added later always becomes a proposal you apply. devlin can also tell you how a send is going and where an item is mirrored.
• An AI tool connected through the MCP server can do the same. It must confirm each change, and in a workspace that requires approval for live changes, the request waits for an owner or admin to approve it.