Companies and teams

Orneos has two levels: a company, and the teams inside it. Almost everything you interact with belongs to a team.

Teams own the work

Issues, projects, labels, board columns, saved views and Vault spaces all belong to exactly one team. There is no cross-team pool they are filtered out of.

This matters more than the equivalent concept in most trackers, because team is also the boundary the sync engine routes on. Real-time events are published per team, rows in your local database are tagged with a team, and your replay position is tracked per team. An issue in a team you do not belong to is not hidden from a list you received — it was never sent to you.

The practical consequences:

• Search has an explicit scope. Spotlight and the Search page offer Team (the active team, on your device) and Organization (issues from every team you currently belong to, online). Spotlight starts in Team; the Search page starts in Organization. Results always carry their own team’s prefix.
• An issue reference like ENG-42 is team-scoped. Two teams can each have their own ENG-42. This is why programmatic access refuses an ambiguous reference instead of guessing.
• Labels are per team. Creating bug in one team does not create it in another. See Labels.
• Losing access to a team stops future authorized delivery, but does not reach into your browser to erase what you already had. See Security and isolation for the exact contract.

The active team

You can belong to several teams. Each browser tab shows one of them, and the team is part of the address:

/o/your-company/eng/issue/ENG-42

The first part is your company’s workspace URL, the second is the team’s key in lowercase. Links you copy carry the team with them, so a colleague who opens one lands in the right team.

Tabs are independent. Open a second tab on another team and work in both side by side — switching team in one tab does not move the other. To open a team in a new tab, Cmd-click (Ctrl-click on Windows and Linux) or middle-click it in the switcher at the top of the sidebar.

Switching is an in-place transition, not a page reload. The app quiets in-flight work in that tab, swaps the team, and rehydrates from the local replica — using available local data. A team whose data has not loaded yet needs additional fetching. Browser Back and Forward move between teams the same way.

Details worth knowing:

The address is the choice. Refreshing a tab reopens the team in its address, including mid-switch. Your organization’s bare address (/o/your-company/) opens your personal Home, which spans your teams, where Home is enabled for your workspace; otherwise it opens a team’s board, with the team chosen as for the older team-less links described next. An older link to a page without a team (for example /o/your-company/issue/ENG-12) opens that page in the team the tab was last on — or, in a new tab, the team you used most recently — and adds it to the address.

A team you cannot open is not guessed. If an address names a team you are not a member of, the tab stays on its current team and tells you. If the app has not been able to confirm your teams with the server yet (for example, you are offline) and this device does not know the team, the tab says so instead of showing another team’s work under that address.

Issue links follow their team. Opening ENG-42 while looking at another of your teams switches the tab to Engineering rather than reporting the issue as missing.

Changing a team key changes its addresses. Old links that use the previous key stop resolving, just as old issue IDs do. Keys that collide with app pages (ISSUE, SEARCH, VAULT) are not accepted.

The other teams are kept converging in the background. After the team you are looking at is ready, Orneos fills in your other teams’ data and subscribes to their live updates too. Their changes are written to the local database but do not touch the interface — that is what makes the next switch fast instead of a fresh download. A team that another tab is showing is never refreshed underneath that tab; that tab keeps its own team current.

Workspace URL

Company administrators can change the company part of the address in Settings → Company → Workspace URL — for example from an automatically generated name to your-company. Use 3–48 lowercase letters, numbers and single hyphens. Links that use the previous URL stop working, so change it before you share many links. Other tabs that are already open move to the new address after a reload, or shortly after you return to them.

The company boundary

A company is a stronger boundary than a team, and crossing it destroys the previous company’s local replica. Unlike teams, companies are not independent per tab: one browser profile holds one company at a time. Sign-out and explicit storage resets are also destructive boundaries.

Signing out or switching companies resets the previous local database and storage. When company revocation is detected, the runtime halts and attempts the same cleanup; a cleanup failure leaves the app halted. A subsequent authorized workspace needs its own replica. These paths cannot remotely erase an offline device or guarantee every cleanup succeeds.

That is not caution, it is a requirement. The local replica holds exactly one company’s data. Preserving anything across the boundary — including your queue of unsent changes — would mean the previous company’s operations getting pushed under the next session’s credentials, or the next session adopting the previous company’s scope.

Creating and configuring teams

Company administrators create teams under Settings → Teams. Each team has a name and a key — the prefix in issue references like ENG-42.

Board columns are configured per team, so one team can run Todo / In Progress / Done and another something longer. See Board, Backlog, Timeline.

Related

• Members and roles — who can do what, and how invitations work.
• Settings — where all of this lives in the app.
• Local data and storage — what is on your machine and how to clear it.