> 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/global-settings/environment/topologies/overview-of-topologies.md). # Overview of Topologies ## ![](https://579543750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FsEk2hU5IMh3HEY5dJZjR%2Fuploads%2FSxcnKlaJKPzDqONWoDNv%2FSummary2-Small-Icon.svg?alt=media\&token=5e3253d0-a069-4ba5-9c06-83c70bd0b21d) Overview This article explains what a Topology is, how Topologies group your organizations, how they are managed, and how they affect DevOps. For step-by-step instructions on working with Topologies, see the following articles. * \[Coming Soon] Creating a Topology * \[Coming Soon] Editing a Topology * \[Coming Soon] Deleting a Topology {% hint style="info" %} Only users with the **SystemAdministrator** role can create and edit Topologies. All other users can work inside a Topology in the DevOps app based on their organization permissions. {% endhint %} ## How Topologies Work DevOps previously worked from a single set of connected organizations. This gave the entire tenant one shared working context: one codebase, one set of branches, one set of pull requests, and one set of pipelines. If you used more than one Salesforce production environment, they all shared the same working context. A **Topology** groups a Production organization together with the Development and Sandbox organizations related to it. Each Topology acts as a self-contained working context with its own organizations, branches, pull requests, and pipelines. A tenant can have as many Topologies as it needs, allowing you to keep separate production environments fully isolated from one another. ### Organization Types Every organization has a **Type** that describes its role. **Production** and **Sandbox** were previously the only types, mirroring the two Salesforce org types. Topologies add a third type: **Development**. A Topology can contain any number of Development and Sandbox organizations, but never more than one Production organization. Each type is described below:
TypeDescription
ProductionYour main live production org, the one the business runs on. A Topology can hold only one.
DevelopmentAny other Salesforce production org used for development or testing rather than live business operations.
SandboxA Salesforce sandbox.
{% hint style="info" %} #### Production and Development Are Both Salesforce Production Orgs From Salesforce's perspective, there is no difference between the Production and Development types. Both are Salesforce production orgs, and both are connected the same way. The distinction exists in Flosum, and it identifies which org is your live production environment. A **Development** type organization is not a Salesforce Developer Edition org. The type describes how you use the org, not the Salesforce edition it is connected to. {% endhint %} {% hint style="warning" %} #### Type vs Environment Do not confuse an organization's **Type** with its **Environment** label. The **Environment** label is a filtering aid that does not limit what an organization can do. The **Type** determines whether an organization can be the Production organization in a Topology. To learn more about the Environment label, see the following article. * [Update an Organization Environment](/global-settings/environment/organizations/update-an-organization-environment.md) {% endhint %} ### Topologies in the DevOps App In the DevOps app, a Topology switcher lets you move between Topologies. Selecting a different Topology changes your entire working context, so the organizations, branches, commits, pull requests, and pipelines you see all belong to the selected Topology. To learn more about using Topologies with DevOps, see the following article. * [What are Topologies](/devops/general-information/what-are-topologies.md) {% hint style="info" %} In DevOps, all Topologies are visible to all users; however, access to individual organizations is still controlled by the DevOps permissions. {% endhint %} ## Migration to Topologies All tenants start with a **Default** Topology, and all existing organizations were migrated into it. Organizations previously marked as Production became Development, because a Topology holds no more than one Production organization. {% hint style="info" %} #### No Action Is Required * Backup & Archive and Data Migrator are unaffected. * DevOps continues to work as before, with every organization in the **Default** Topology. * You are not required to mark any organization as Production. Act only when you want to take advantage of multiple Topologies, which means creating additional Topologies and assigning organizations to them. {% endhint %} ## Creating and Managing Topologies Topologies are managed from the **Topologies** page in Global Settings. The page lists every Topology in the tenant, along with its Production organization and the number of Sandbox and Development organizations assigned to it. You can create a Topology from this page or while connecting an organization. Each Topology has a detail page that shows its name, description, Production organization, organization counts, creation and update dates, and the full list of assigned organizations. You can rename a Topology at any time, and renaming does not affect the organizations inside it or any work in progress. You can delete a Topology only after all of its organizations have been removed.
## Creating and Managing Organizations Organizations are assigned to a Topology when you create them. During the creation process, you select an existing Topology or create a new one without leaving the process. To learn how to create an organization, see the following article. * [Creating an Organization](/global-settings/environment/organizations/creating-an-organization.md) {% hint style="warning" %} #### Changing Topologies After an organization is assigned to a Topology, it cannot be moved to another Topology. This restriction protects your DevOps working context and prevents the unintended effects of moving an organization between contexts. If you need to move an organization to a different Topology, delete the organization and create it again with the Topology you want. When you delete an organization, you will lose any information specific to that organization, especially backups from the Backup & Archive app. {% endhint %} Because a Topology holds no more than one Production organization, Global Settings validates this when you connect a Production organization. If the Topology you selected already has one, Global Settings blocks the action and displays a warning. The **Organizations** list includes a **Topology** column, so you can see which Topology each organization belongs to without opening its detail page. Each organization also has a **Mark as Production** option, which changes the organization type from Development to Production. If the Topology already has a Production organization, an error message is displayed.
## How Topologies Affect Roles The **Manage organization permissions** section in the Create Role and Edit Role forms is now **Topology permissions**, and it applies across Backup & Archive, DevOps, and Data Migrator. When a Topology is added to a role, all organizations in the Topology are listed. However, the individual permissions are still assigned per organization, and your existing permissions remain unchanged. To learn how roles, groups, and users work together, see the following articles. * [Overview of Roles, Groups, and Users](/global-settings/user-management/overview-of-roles-groups-and-users.md) * [Creating a Role](/global-settings/user-management/roles/creating-a-role.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/global-settings/environment/topologies/overview-of-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.