Private projects & access

Keep a project, a folder or a file to the people who need it, and say what each role and person may do there.

In a new organization every member sees every project, because Everyone holds View project. A project can change that for itself. It can be private, so only the roles and people it names get in. And it can give a role or a person more, or less, than their roles give them everywhere else: Release managers can manage runs in one project and only watch in another.

The same goes for a folder or a file in the project's repository: assets/ can be closed to Everyone and open to Design, or one contract kept to Legal.

Where it is

Access, in the project's settings, on the web, the desktop app, the Mac, iPhone, iPad and Android. Only people with Manage access in the project see it, because what a project lets each role and person do is kept to the people who look after it.

For a folder or a file, Manage access… in its menu in Code, the wiki and Assets opens the same settings for just that folder or file. It is offered to whoever manages access there.

Make a project private

Turn on Private, and Everyone can no longer see the project. You stay in: when nothing else would let you in, turning it on gives you View project and Manage access there in your own name. Then choose who else gets in — roles and people, each with a preset, Can edit unless you pick another.

Turning Private off lets Everyone back in, and leaves what you gave roles and people as it was. The owner and people with Administrator see every project, private or not.

What each role and person gets

Access lists Everyone first, then roles, highest first, then people, then API keys and triggers (below). Each row says what it gives, as one of four presets:

A preset settles every permission a project can set, so it means the same whatever the role holds elsewhere: a role on Can view sees the project and reads its files, and starts no runs there even if it starts them everywhere else.

Add picks a role, a person, an API key or one of this project's triggers, then a preset. A row's menu has Change… and Remove, and removing a row gives them back what they had without it. A person's row goes when they leave the organization or are removed, a role's when the role is deleted, a key's when it is revoked, and a trigger's when it is removed.

Advanced

Under Advanced, each permission a project can set is listed on its shelf, as in the role editor, with Allow, Inherit and Deny. Allow and Deny decide it in this project; Inherit leaves it as it would be without this row. A row that matches no preset reads Custom.

A project can set Manage workflows, Manage automations and Manage mini apps; View project, Manage project, Manage board setup and Manage access; and everything under Work and Files. The rest — Administrator, the General and Integrations shelves, Manage store, Manage shared dashboards and Create projects — are the organization's alone.

When several rows apply

What somebody may do in a project starts from what their roles give them. Then the rows apply, level by level: the project's own, then those of each folder on the way down, then the file's. At each level the rows go in order — Everyone's, then those of every role they hold, then their own — each overruling what came before it. Between two roles they hold, Allow beats Deny. Without View project, nothing else in the project counts; without View files at a folder, nothing in it can be edited or shared.

Folders and files

A row can sit on a folder or a file. It names a place in the tree, never a pattern: assets/public/ starts from whatever assets/ settled and adds its own rows, and there are no rules like **/*.env to decide between.

A folder's or a file's row carries only four permissions: View files, Edit files, Share files publicly and Manage access. Its presets range over the files:

Manage access on a folder is set under Advanced only. The people who close a folder usually manage it through their roles, and a preset that also decided Manage access would take that away from them the moment they closed it to Everyone. So the presets leave it alone, and who may manage a folder is its own decision. Managing a folder doesn't need its files: it can be closed to the very people who decide who opens it.

The Access page lists every folder and file you manage that has rows, under Folders and files. A folder or file that has gone from the repository keeps its rows and is marked Missing, so a folder that comes back comes back closed; Remove takes the rows away. A folder or file with rows of its own shows a lock in Code, the wiki and Assets to the people who manage access there.

The rules are each project's own. When another project uses the same repository and leaves open what this one closes, Access says so: "This repository is also used by B, where assets/ is open."

Who may change it

• Manage access where the row sits — in the project for the Access page, at a folder or file for its own rows.
• Only what you hold there. A row can allow only permissions you hold there yourself; denying takes nothing more. Anything else is refused: "You can only give permissions you hold here." The owner and people with Administrator hold them all.
• Nobody shuts themselves out. A change after which you would no longer have Manage access there is refused: "You'd lose access to this project's settings. Give yourself or one of your roles Manage access here first." The owner and people with Administrator are never shut out, so it never stops them.

Every change is recorded on the Access shelf of the audit log, where the folder or file a change names is shown only to the people who manage access there.

See as… and Why?

See as… on the Access page, and from Manage access… on a folder or file, shows what Everyone, a role, a person, an API key or one of the project's triggers gets there, on the role editor's shelves. In Settings → Roles it shows what they get at the organization — an API key only for people who also hold Manage API keys, and a trigger never, since a trigger acts only in its own project. Every permission offers Why?: the chain that decided it — the roles that give it, or a key's or a trigger's own list, then each row that applied, where and for whom, allowing or denying — or the owner, Administrator, a View permission it waited on, with that one's own chain, or a project that's gone.

It is shown to the same people as the rules themselves: Manage roles for the organization, Manage access in the project or at the folder or file. And it says only what they may see. In a project it lists what a project can set, and at a folder or file the four a folder or file can. Which roles give a permission is named only to people with Manage roles. Rules above the folders you manage, which you can't see, come as one line: what they gave by the time they reached you.

What you can't see

It isn't there, and nothing hints that it exists. A project you can't see:

• is left out of the project switcher, every project list, search and the timeline;
• is left out of dashboards, which drop the widgets pinned to it, and of the audit log;
• reaches nobody's notifications or Inbox, and no approver rule reaches you there, since approving a gate takes View project in the run's project;
• is beyond the reach of the assistant.

A folder or file you can't see is left out of Code's tree, search and history, the wiki, Assets, memory, a commit's and a run's changed files, and everything the assistant reads. A commit whose files are all hidden from you keeps its message and reads "Changes to files you can't open". A closed folder with something inside opened to you shows only as the way down to it. A run that worked with it shows you only its row (below).

The public API answers 404 for either, and chat apps are told it isn't found, as for something that was never made. A private project you can see wears a lock beside its name in the switcher and in project lists.

Runs

A folder or file with a row here that takes View files away from anybody — Everyone, a role, a person, a key or a trigger — is restricted: every run leaves it out unless it includes it, even for people who can open it. A folder opened to Everyone again inside a closed one, like assets/public/ inside assets/, isn't restricted. What a run includes:

• A person's run — what they tick under Include restricted folders when they start it, and what its workflow's phases ask for with include:, as far as they can open it.
• An API key's run, or a trigger's with a list — whatever that list opens, without asking.
• Any other run — nothing.

A run that worked with a restricted folder or file is whole only for people who can open everything it worked with; the owner and people with Administrator always can. Everybody else who sees the project gets its row — the title, the status, who started it and when — and "This run worked with files you can't open." in place of its transcript, changes and files. Its gates and questions don't reach them, and approving it or sending it back is refused: "Approving needs access to the files this run worked with."

A run that leaves files out works on a copy without them, and Peractor pushes its changes only to files whoever it acts for can edit — see Git & credentials. A mini app built from this project's repository can't be built from a restricted folder, and its builds leave restricted files out.

"You don't have access to this"

A link to something you can't open — sent to you, opened from a notification, or a place the app remembered — shows You don't have access to this: no name, nothing past the last thing you can see, and Request access. A link to something that isn't there shows the same page, so the page tells nobody what exists.

• What you ask for. Can view, unless you choose Can edit. If you can already open it, the page simply opens instead.
• Who is told. The people with Manage access there who could give you what you asked for — the owner and people with Administrator among them. Nobody else hears of it, so a request is only ever seen by people who can already open what it points at. It names the link you opened and nothing behind it.
• Grant. Their Inbox opens the project's Access page at your request. Grant gives you a row of your own there, with the preset you asked for or another they choose, and the same rules as any row. You are told — "Kim let you in" — and the notification opens the link.
• Decline. You aren't told, but you can't ask about the same thing again for a day: "You asked for this less than a day ago and weren't let in. You can ask again tomorrow."

Public links to assets

A public link to an asset carries the person who made it. Making one takes View files and Share files publicly where the file is, and every open checks both again: once its maker can't open the file or share it, or has left the organization, the link stops working.

API keys and triggers

An API key may do only what it was given, and a trigger can be given a list of its own too (Roles & permissions). A key, or a trigger with a list, holds no roles, so rows for Everyone and for roles never give it anything — but what Everyone is denied, it is denied too. A private project, or a folder or file closed to Everyone, opens to it only through a row in its own name: Add offers the organization's API keys and this project's triggers after Roles and People, with the same presets. A row whose key or trigger has since gone reads A revoked key or A removed trigger, and Remove takes it away.

A trigger without a list of its own acts with no identity: it sees only what Everyone can, and a row naming it counts only once it has a list.

Next: Roles & permissions · Projects & repositories