Skip to main content
A team gives its members Iris Code Pro and one shared standard for their repositories. Team owners manage seats and billing, while developers use the same tools they would use individually. Shared configuration and recorded scan results help everyone understand what the team expects.

​
What a team is

A team is the unit that owns everything: members and their seats, connected repositories, the published standard, the audit trail, and the billing relationship. You can own up to three teams. Most people need one.

​
Members and roles

The owner cannot be demoted or removed, because a team whose only owner had been demoted could not be administered by anyone.

​
Inviting people

Invite by email address and choose a role. The invitation is created whether or not the email is delivered, and the screen tells you which happened rather than reporting “invitations sent” for both. An invitation holds a seat while it is pending, so five invitations on a three-seat team will not all succeed. Invitations expire after 7 days, and you can revoke one at any time to release its seat immediately.
Iris Code reports each invitation’s outcome separately. A batch of five on two free seats succeeds twice and fails three times, and you are told which three, because “invitations sent” hides exactly the information you need.

​
What every member gets

A seat grants Pro in that member’s editor, whatever their own subscription says. See Team entitlement for how that interacts with a personal subscription, and what happens when a seat ends.

​
The shared standard

A team publishes one .irisconfig.json standard, built and previewed in Config Studio. It is committed beside your code like any other config, so a new machine enforces it on its first push. Publishing does not change any repository. It sets what the team expects; the config in each repository is what actually runs, and every report names which policy version it used, so drift is visible rather than silently corrected.

​
The audit trail

Every completed audit records what ran, on which commit and branch, what it scored, how many findings were open and how many were high severity, and which policy version applied. Audits arrive from three places, and all three land in the same trail:
  • The editor, on every completed team scan
  • CI, from iris gate, when the repository sets a teamProjectId
  • Cloud scans, from connected GitHub repositories
This team evidence contains counts and revisions, without source code, file names or finding text. Connected cloud repositories also have separate, detailed scan reports containing file paths and finding locations. See cloud reports and retention.

​
Cloud scans for a team

A team has its own connected repositories and its own scan allowance of 100 per seat per month, entirely separate from any member’s personal repositories. See Scan allowances.

​
Trials

A team can start a 14-day trial with 3 seats, no card required.
The trial is one per person, not one per team. If you have already trialled Teams, a second team you create starts with no trial and no plan: it exists and accepts invitations, but no member gets Pro from it and it cannot run cloud scans until a subscription starts. The billing screen says so rather than leaving you to guess.

​
Deleting a team

Only the owner can, and only once the subscription has been cancelled, because deleting a team tells the billing provider nothing and a team removed mid-subscription would keep being charged for something that no longer exists. Deleting removes members, invitations, connected repositories, cloud reports and the audit trail. A record of the deletion is kept. Deleting your last team returns you to your personal account. Read Team governance for agent handoff controls, offline behaviour and pre-push hook records.