Skip to main content

Who decides what

Assume "an administrator can do anything" or "an owner decides everything" and you will lay the work out wrong. Authority is not a single flight of stairs. The roles are independent layer by layer, and the power to decide a review is settled on an axis of its own. Some things only a higher role can do — and some things a higher role cannot do.

This page explains how far each party can decide. Who to make a member and who to make a reviewer are in the Review Guide.

The roles fall into two layers​

The roles fall into two layers. On the admin side there is the system administrator and the organization admin; on the project side, the owner and the member.

The two layers are different things. Holding a role in one does not automatically grant you a role in the other. Holding an admin role alone does not change a project's settings, and a project owner cannot change what the tenant has settled.

A project has owners and members​

There are two roles inside a project.

An owner changes the project's settings and can start a run by hand. They also manage members. Changing a project's settings is for owners only.

A member can see the overview, the run history and the run records. They cannot change settings or start runs by hand (where starting by email is in use, they can start runs by email). They can, however, decide a review on any step where they are named as a reviewer.

A change that would leave no owner at all is refused. Before changing or removing a role, someone else has to be made an owner first.

Review is not settled by role​

This is where it is most often misread.

Whether you can decide a review is not settled by being an owner or a member. Only the reviewers named on that review step can decide it.

Even an owner cannot decide a review unless they are named as a reviewer on that step. Do not lay the work out thinking "put the owner in and approvals will flow".

The exception is a review request raised from the result of a “Run by Agent” step. If a step's result handling is set to “Ask for review”, the agent's result raises a review request. Such a step has no field for naming reviewers, so as a rule, every owner at that moment becomes a reviewer, and the owners decide (Design Guide). On a review step too, if every named reviewer has been removed from the members by the time the review request is raised, every owner at that moment becomes a reviewer in the same way.

The other way round, only participants in that project — owners included — can be named. Someone who is not taking part cannot be made a reviewer.

The tenant-wide execution rules are settled by the system administrator​

The tenant-wide rules for which operations an agent may perform are settled by the system administrator. A project owner can move the execution rules only in the stricter direction from them. An organization admin can see what the execution rules say, but cannot change them.

How the tenant-wide rules apply is covered in How much to delegate.

What you can connect to is chosen from what is provided​

Connectors work the same way. A project owner can choose from the candidates provided and authenticate them, but cannot add to the candidates.

When what you want to connect to is not among them, the system administrator has to provide it.

An organization admin can see their organization's records​

An organization admin can see the records of runs made in the name of someone who belongs to one of the organizations they are responsible for (a project's runs go out in the name of the person who created the project). Opening the body of a record takes a stated reason, and who opened it and why are recorded.

The body can be opened by the person themselves, by participants in the project, and by an organization admin for that organization. From the admin side, a system administrator cannot open the body on that credential alone. They can survey the records across the whole tenant, but the body takes an organization admin's credential. This is not a matter of rank.

The organization admin role can only be given to someone who belongs to that organization. An organization admin can add people from their organization to a project tied to that organization, as a member or an owner. They cannot, however, remove a member, or turn an owner into a member.

A project is tied to an organization when its “Organization” is set. Only an organization the person setting it currently belongs to can be chosen, either when the project is created or, for a project with no organization, once by an owner. Once set, it cannot be changed. A project with no organization is still shared with its participants, but it is not listed or managed by organization admins.

Runs go out in the creator's name​

A project's runs go out in the name of the person who created the project (for a project made by copying, the person who copied it). An owner's authority is for managing the project, and is separate from the name runs go out in. Changing the owner, or removing the creator from the members, does not change that name. Nor can the name be moved to someone else.

What the runs produce goes to the creator too. A run's conversation is listed, read-only, in the “Chat” of the person who created the project (it cannot be posted to, shared or deleted), and files the agent creates go into that person's “Library”. They do not appear in the “Chat” or “Library” of the other owners or members (owners and members alike can open the input files and artifacts listed in a run record). The project's time triggers and sweeps do not appear in the creator's “Schedule” either. You follow the runs on the project's screens.

How many conversations there are depends on how it runs. A workflow step makes a new conversation each time an agent runs. A cycle's sweep keeps using one conversation per placement, so the exchanges pile up with each sweep (a run started by a webhook or by email makes a new conversation each time).

So while management can be handed over, the name runs go out in, the conversations and the files the agents created all stay with the creator. There is nothing that keeps the runs going once the creator can no longer be used. For work whose people in charge change, decide who creates the project with this in mind.

A connector's authentication belongs to the project. When the owner changes, the authentication stays in use, and it does not switch to the new owner's personal authentication. When it expires, a current owner authenticates it again (Connection Guide).

An agent's owner is also separate from the project's owner. Only an agent's owner can edit it, and changing the project's owner does not change who owns its agents. For a new owner to change an agent the creator owns, they prepare an agent they own and put it in its place (Design Guide).

The "Who" in the records is not always a person​

The Who column in the record of operations inside a project lists agents and the system as well as people.

So do not read that column as always meaning a person did it. When you trace who did what, look at the kind of actor along with it.