> 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/release-notes/release-notes-de/globale-einstellungen/monatliche-veroffentlichungen/globale-einstellungen-v1.6.27-monatliche-versionshinweise.md).
# Globale Einstellungen (v1.6.27) - Monatliche Versionshinweise
{% hint style="info" %}
#### **Versionsdetails - Globale Einstellungen - v1.6.27 - 29. Juli 2026**
Dieser Artikel richtet sich an Salesforce-Administratoren und IT-Teams, die für die Verwaltung der Mandantenkonfiguration, Organisationen, Benutzer und Rollen von Flosum Cloud Apps verantwortlich sind.
**Release-Typ**
* Monatlich
* Gilt für Flosum-gehostete und selbst gehostete
**Voraussetzungen**
* Ein registrierter und konfigurierter Flosum Cloud Apps-Mandant
* Entsprechende Flosum-Benutzerberechtigungen (Systemadministrator oder gleichwertig)
{% endhint %}
##  Zusammenfassung
Dieser Artikel dokumentiert das Patch-Release für **Globale Einstellungen (1.6.27)**. Dieses monatliche Release führt Topologien ein, eine neue Möglichkeit, Salesforce-Organisationen in Flosum Cloud Apps zu organisieren und zuzuordnen, zusammen mit einem neuen Organisationstyp Development.
###  Mehrere Topologien pro Mandant
Vor diesem Release arbeitete die DevOps-App mit einem einzelnen Satz verbundener Organisationen, wodurch der gesamte Mandant einen gemeinsamen Arbeitskontext hatte: eine Codebasis, einen Satz von Branches, einen Satz von Pull Requests. Topologien heben diese Einschränkung auf. Ein Mandant kann jetzt so viele Topologien enthalten, wie er benötigt, und jede ist ein in sich geschlossener Arbeitskontext mit eigenen Organisationen, Branches, Pull Requests und Pipelines.
#### Globale Einstellungen
Eine Topologie gruppiert eine einzelne Production-Organisation mit den zugehörigen Development- und Sandbox-Organisationen. Sie verwalten Topologien auf der neuen **Topologien** Seite in den globalen Einstellungen, auf der jede Topologie im Mandanten zusammen mit ihrer Production-Organisation und der Anzahl der Organisationen aufgeführt ist.
Die Zuordnung zu einer Topologie ist jetzt Teil des Verbindungsablaufs. Beim Verbinden einer neuen Organisation wählen Sie eine vorhandene Topologie aus oder erstellen spontan eine. Die Organisationstabelle enthält jetzt eine neue **Topologie** Spalte.
#### DevOps
In der DevOps-App ermöglicht Ihnen ein Topologie-Umschalter, zwischen Topologien zu wechseln. Die Auswahl einer anderen Topologie ändert Ihren gesamten Arbeitskontext, sodass Arbeit in einer Topologie nie in einer anderen angezeigt wird.
###  Production- und Development-Typen
Das Organisations **Typ** Feld bot bisher nur **Produktion** und **Sandbox**, entsprechend den beiden Salesforce-Organisationstypen. Dieses Release fügt einen dritten Typ hinzu, **Entwicklung**, sodass ein Mandant mehr als eine Salesforce-Produktions-Org verbinden kann, während innerhalb jeder Topologie weiterhin genau eine Production-Organisation identifiziert wird.
Aus Sicht von Salesforce gibt es keinen Unterschied zwischen den beiden Typen. Eine Production-Organisation und eine Development-Organisation sind beide Salesforce-Produktions-Organisationen und werden auf dieselbe Weise verbunden. Die Unterscheidung stammt von Flosum und beschreibt die Rolle, die die Org in Ihrer Topologie spielt:
* **Produktion**: Ihre Haupt-Produktions-Org, also die Live-Produktions-Org, auf der das Geschäft läuft.
* **Entwicklung**: jede andere Salesforce-Produktions-Org, die für Entwicklung oder Tests und nicht für den laufenden Geschäftsbetrieb verwendet wird. Eine Topologie kann mehrere enthalten.
* **Sandbox**: eine Salesforce-Sandbox. Sandbox-Organisationen bleiben von diesem Release unverändert. Eine Topologie kann mehrere enthalten.
###  Topologie-Migration
Alle Mandanten beginnen mit einer **Standard** Topologie, und alle vorhandenen Organisationen werden dorthin migriert. Zuvor als Production markierte Organisationen wurden zu Development, da eine Topologie nicht mehr als eine Production-Organisation enthalten kann.
{% hint style="info" %}
#### Nach diesem Release sind keine Maßnahmen erforderlich
* Backup & Archive und Data Migrator sind nicht betroffen.
* DevOps funktioniert weiterhin wie bisher, mit jeder Organisation in der Standard-Topologie.
* Sie müssen keine Organisation als Production markieren.
Handeln Sie nur, wenn Sie mehrere Topologien nutzen möchten, was das Erstellen zusätzlicher Topologien und das Zuweisen von Organisationen dazu bedeutet. **Als Production markieren** ist in der Organisationsliste verfügbar, wenn Sie eine Live-Produktions-Org festlegen möchten, bleibt jedoch optional.
{% endhint %}
###  Topologie-Berechtigungen
Die **Berechtigungen für die Organisationsverwaltung** Abschnitt in den Formularen Rolle erstellen und Rolle bearbeiten ist jetzt **Topologie-Berechtigungen**, und sie gilt für Backup & Archive, DevOps und Data Migrator. Wenn einer Rolle eine Topologie hinzugefügt wird, werden alle darin enthaltenen Organisationen aufgelistet. Die einzelnen Berechtigungen werden jedoch weiterhin pro Organisation zugewiesen, und Ihre bestehenden Berechtigungen bleiben unverändert.
{% hint style="info" %}
In DevOps sind alle Topologien für alle Benutzer sichtbar; der Zugriff auf einzelne Organisationen wird jedoch weiterhin durch die DevOps-Berechtigungen gesteuert.
{% endhint %}
---
# 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/release-notes/release-notes-de/globale-einstellungen/monatliche-veroffentlichungen/globale-einstellungen-v1.6.27-monatliche-versionshinweise.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.
