> For the complete documentation index, see [llms.txt](https://docs.flosum.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flosum.com/devops/general-information/what-are-topologies.md).
# What are Topologies
##  Overview
**Topologies** are a new feature in DevOps. A **Topology** is a self-contained working context: each one has its own organizations, branches, commits, pull requests, and pipelines, and work in one Topology never surfaces in another.
When the Topologies feature is released, your tenant will contain a **Default** Topology that holds all of your existing organizations, branches, commits, pull requests, and pipelines. Topologies are created and managed in Global Settings. To learn how, see the following article.
* [Overview of Topologies](/global-settings/environment/topologies/overview-of-topologies.md)
{% hint style="info" %}
#### No Action Is Required
DevOps works the same way it did before Topologies were introduced. All of your organizations are already in the **Default** Topology, so if your team works from a single codebase, you can continue working without making any changes.
{% endhint %}
## Why Use Multiple Topologies
A Topology holds one codebase. Every organization inside it shares the same branches, pull requests, and pipelines, which is what you want when those organizations belong to a single delivery process: a Production organization, the sandboxes used to develop against it, and any Development organizations used for testing.
Use a second Topology when you have a second codebase to manage. If your business runs two Salesforce production environments that are developed and released independently, they should not share branches or pull requests. Giving each one its own Topology keeps their work completely separate.
## Switching Topologies
The **Topology Switcher** is the first item in the breadcrumb navigation at the top of the page, shown with the Topologies icon and the name of the Topology you are working in. Because the Topology sits at the root of the breadcrumb, everything further along the path belongs to the Topology you selected.
Click the switcher to open the list of Topologies. A checkmark identifies the Topology you are currently working in. Select a different Topology to change your working context, and the organizations, branches, commits, pull requests, and pipelines all change too.
{% hint style="info" %}
In DevOps, all Topologies are visible to all users; however, access to individual organizations is still controlled by the DevOps permissions. To learn more about these permissions, see the following article.
* [DevOps Permissions](/global-settings/user-management/flosum-cloud-app-permissions/devops-permissions.md)
{% endhint %}
## Managing Topologies
Topologies are created, renamed, and deleted in Global Settings, and only users with the **SystemAdministrator** role can manage them. You assign organizations to a Topology when you create them, and an organization cannot be moved to a different Topology afterward.
To learn how Topologies are managed and how organizations are assigned to them, see the following article.
* [Overview of Topologies](/global-settings/environment/topologies/overview-of-topologies.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.flosum.com/devops/general-information/what-are-topologies.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
