Teams

Every brief has a scope: personal or team.

The two scopes

Personal is the default. Only you can see it. It does not appear for anybody else on your team, in any list, at any time.

Team shares the brief with everyone on the team you assign it to. They can open it, read every block, attach it to their own team projects, and take their own copy. Teammates with a full seat can also edit its content; only you can rename it, change its scope or delete it.

Your Briefs page shows the two separately, so you can always tell at a glance which of your briefs other people are looking at.

What a teammate can do

Read it. Every block, every reference picture, exactly as you see it.

Attach it to a project on that team. Their project then uses your brief (the same record, not a copy) and reads your edits as you make them.

Clone it: take a full copy into their own list, which they then own outright and can change however they like. See Reusing a brief.

Edit it, with a full seat. Every block, the Look, the reference pictures, a document upload and the Brief Agent. A viewer seat reads and attaches, and does not edit.

What a teammate cannot do

Rename it, or change its scope. The name, the scope and the team it is shared with are the owner’s.

Delete it. Same reason.

Why clone rather than edit

A shared brief is usually shared because it is settled: a house style, a client’s world, the thing everybody’s work is supposed to agree with. Now that a project uses a brief rather than copying it, the stakes of an edit are higher than they were: change a shared brief and every team project using it composes differently from that moment, and any full seat on the team can make that change.

So edit deliberately. The brief page tells you how many projects you are about to reach. Somebody who needs a variant clones the brief and changes the clone. If the variant turns out to be an improvement, make the change on the original, on purpose, for everyone.

Which brief a team project can use

This is the rule that makes shared briefs safe, and it is enforced rather than advised:

A project can only use a brief that everyone who can see the project can see. A team project can use a brief shared with that team. It cannot use a personal brief, yours or anyone’s, because the rest of the team could not see what their prompts were being composed against. Attach refuses, and says the brief has to be shared with the team first.

The same rule is checked from the other side. You cannot move a project onto a team while it uses a brief that team cannot see, and you cannot make a brief personal while a team project is using it. Both are refused with the reason; detaching first is always the way through.

What the rule protects is the brief record, not its influence. A project’s prompts are governed by the project’s own visibility. If a project is public, its prompts are public, and they still reflect the brief that wrote them: the brief’s descriptions are in those prompts. The gate keeps the brief itself (the blocks, the reference pictures, the Brief Agent’s view of it) within its scope; it does not, and cannot, unwrite the prompts.

A project’s brief may not be yours, and may change without you

On a team, a project you are working in can be using a brief a teammate owns. You will see it on the project’s Brief card and can open it, and everything you compose in that project reads it. But its owner and every full seat on the team can edit it, and may do so without telling you; the next prompt you compose reflects the change.

This is the sharpest consequence of live briefs plus team scope, and it is better known than discovered. Two ways to handle it:

• Accept it, because that is what a shared brief is for: one settled world the whole team stays in step with.
• Clone it and attach your clone to the project instead, when a project must not move under you. The clone is yours; it changes only when you change it. You will be out of step with the team’s brief from then on, on purpose.

Changing scope

You can share a personal brief with a team (Share… on the Briefs page), and make a team brief personal again (Make personal).

Sharing goes up as well as down because the rule above needs it: a brief you built for yourself has no way onto a team project until it is shared, and a clone would not do, because a clone is a copy, and the point of attaching is to stay in step. Sharing is a deliberate action, taken from the brief’s row, naming the team; it is refused unless you are on that team.

Two things are refused, both for the same reason (a live brief has projects depending on it):

• Making a brief personal while a team project uses it. The team would lose sight of a brief their project composes against. Detach it from those projects first.
• Moving a brief from one team to another. That is a re-file, not a change of mind: every project on the old team would lose the brief at once. Make it personal first (which the rule above only allows once no team project uses it), then share it with the other team.

Un-sharing a brief does not reach into clones your teammates have already taken. Those are theirs.