Teams and approvals

Teams control who can create, deploy and run nodes. Projects group nodes inside a team.

Find your team

atfg team ls
atfg team show sandbox

Join an existing team, or request a new one:

atfg team join sandbox
atfg team create my-team --reason "Team development"

These are alternatives. A pending request returns exit code 3; this means waiting, not a failed submission.

Approve a request

The request names who must act. A team owner approves membership; a platform administrator approves a new team. In the approver's own signed-in terminal:

atfg approvals
atfg approve <approval-id> --note "Approved for development"

To reject:

atfg reject <approval-id> --reason "Please use the existing team"

The requester can use atfg approvals --all and atfg team show <team> to check the result. Do not assume email, Slack or pull-request notifications: check the CLI approval queue.

Self-approval is normally blocked. A one-time bootstrap exception lets the configured initial platform administrator approve creation of the first team. Once a team exists, that exception is closed; later requests need another eligible approver.

Set your working context

After approval:

atfg config set team sandbox
atfg config set env dev
atfg project ls

If the project does not exist:

atfg project create pilot --title "First node"

Use --team <name> or --env dev to choose context for an individual command.

Roles

New outbound destinations and other controlled changes can require approval even in dev. Follow the specific request returned by the service.