Remove status: from Org ADRs

: System-wide admin tasks will use explicit context exemption blocks

Scheduled Tasks

: Cron jobs will likely initalize the job without a Current Organization and then define Current Organization per Organization batch.

: Cron jobs will likely initialize the job without a Current Organization and then define Current Organization per Organization batch.

An example exception may look like:

---

owning-stage: "~devops::tenant scale"

title: 'Organizations ADR 001: Organization context resolution'

toc_hide: true

---

## Context

The GitLab data paradigm will shift from a global pool of instance wide data, to a multi-tenant pattern of isolated organizations within multiple instances.

To accomodate this change Organization access will have to occur in an isolated environment through the full data stack. The solution ideally needs to have minimal impact on the engineering team.

To accommodate this change Organization access will have to occur in an isolated environment through the full data stack. The solution ideally needs to have minimal impact on the engineering team.

We have been through a number of Organization/Cell roadmaps over the last couple of years which have informed this decision.

- We need to ensure all entry points define a Current Organization.

- The database will filter view of the data according to the Organization context.

- All other direct/indirect services will need to accomodate similar contextual data access.

- All other direct/indirect services will need to accommodate similar contextual data access.

- We allow global access for exceptional cases.

## Alternatives

---

owning-stage: "~devops::tenant scale"

title: 'Organizations ADR 004: Organization path scope'

toc_hide: true

---

## Context

---

owning-stage: "~devops::tenant scale"

title: 'Organizations ADR 005: Multi-Step Authentication Flow'

status: accepted

creation-date: "2025-08-06"

authors: [ "@ayufan" ]

toc_hide: true

---

## Context

### Step 1: User Identification

Users will go through the sign in flow on the global sign in page (`/users/sign_in`) and be routed to the correct cell by the Typology service using the `login` query param. In the future when organizations support [verified domains](https://docs.gitlab.com/user/project/pages/custom_domains_ssl_tls_certification), users with a verified domain will be redirected to branded organization sign in pages (e.g. `/o/<org-path>/users/sign_in`).

Users will go through the sign in flow on the global sign in page (`/users/sign_in`) and be routed to the correct cell by the Topology Service using the `login` query param. In the future when organizations support [verified domains](https://docs.gitlab.com/user/project/pages/custom_domains_ssl_tls_certification), users with a verified domain will be redirected to branded organization sign in pages (e.g. `/o/<org-path>/users/sign_in`).

#### Without verified domains

---

owning-stage: "~devops::tenant scale"

title: 'Organizations ADR 006: Administration and Settings'

status: accepted

creation-date: "2025-08-26"

authors: [ "@alexpooley" ]

toc_hide: true

---

## Context