Companies and teams

How the two boundaries work, what switching between them does, and why a team is a harder wall than it looks.

Available Updated 2026-09-24

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 scope depends on the surface. Spotlight uses the active team. The issue Search page defaults to online Company scope for authorized cross-team results and offers local Team scope.
  • 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. One is active, and it is what the interface shows. The switcher is at the top of the sidebar.

Switching is an in-place transition, not a page reload. The app quiets in-flight work, swaps the active team, and rehydrates from the local replica — using available local data. A team whose data has not loaded yet needs additional fetching.

Two details worth knowing:

Your choice is durable before anything else happens. The new active team is written to storage before any in-memory teardown, so refreshing mid-switch boots you into the team you chose, not the one you left.

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.

Unsent changes drain across teams

When connected, the worker attempts queued changes across teams, using each change’s owning team for server authorization. You do not need to visit every team to start its drain. Rejected or failed changes still require attention; check pending and failed states before clearing storage or signing out.

The company boundary

A company is a stronger boundary than a team, and crossing it destroys the previous company’s local replica. 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.

Unsent work does not survive sign-out

Signing out destroys queued changes that have not reached the server. This is the accepted contract, not a bug: sign-out has to destroy the data regardless of what is queued. If you have been working offline, reconnect and let the queue drain before signing out. Offline and reconnect explains how to tell.

A company switch is stricter and will refuse to proceed if it cannot prove the queue is empty and the storage wipe actually succeeded — it would rather fail loudly than serve you a replica it cannot vouch for.

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.

Something here wrong, missing or out of date? Tell us at support@orneos.com — corrections to these pages are welcome and we would rather hear it than have you work around it.