Qlik Cloud verstehen: Begriffe, Bereiche und Namenskonventionen

Versions- und Quellenstand: Qlik Cloud (SaaS), 23.10.2026. Kein festes Qlik-Sense-Client-Managed-Release. Cloudoberfläche und Funktionsumfang können sich auch bei kleineren Updates ändern; regionale Rollouts, Subscription und Tenantkonfiguration vor Umsetzung prüfen. Installierte Gateway-/Connectorversionen separat protokollieren. Redaktionell gegen Herstellerhilfe geprüft, nicht im Kundentenant ausgeführt.

Namensbeispiel lesen: VERTRIEB-ENTWICKLUNG-APPS bedeutet Fachbereich Vertrieb → Entwicklungsumgebung → Analyse-Apps. Entsprechend steht VERTRIEB-PRODUKTION-APPS für freigegebene produktive Apps. Die Namen sind frei gewählte Beispiele; sie erzeugen keine Berechtigungen. Verwende in Skripten und im Register exakt den Namen eures tatsächlich angelegten Bereichs.

Was wir in dieser Serie tatsächlich aufbauen

Du betreust die Qlik Cloud eines mittelständischen Unternehmens. Der Vertrieb möchte Monatsumsatz und Wachstum je Region verlässlich vergleichen. Bei Abweichungen braucht eine kleine Analysegruppe einen passenden Detailzugriff auf die zugrunde liegenden Beträge. Heute heißen Apps „Sales final“, „Sales final neu“ und „Kundenliste“. Niemand weiß sicher, welche Fassung freigegeben ist. Diese Serie baut daraus eine nachvollziehbare Struktur. Du brauchst dafür weder Snowflake noch einen externen Katalog. Beides kann später hinzukommen.

Am Ende existieren ein Entwicklungsbereich, ein Testbereich, ein kontrolliertes Veröffentlichungsziel, getrennte Ablagen für eingeschränkte und aufbereitete Daten sowie eine Sammlung als verständlicher Einstieg. Die Serie erklärt erst die Gegenstände, dann die Entscheidungen und schließlich deren Einrichtung. Die Namen und das Betriebsmodell sind unser Referenzvorschlag, keine von Qlik vorgeschriebene Norm.

Erst die Begriffe: Was gehört wohin?

Stell dir einen Bereich als Teamraum mit Zugangsregeln vor und eine Sammlung als kuratierte Leseliste. Die Analogie hilft beim Einstieg, ersetzt aber keine Rechteprüfung. Eine App in einer Sammlung erhält dadurch keine neue Datenberechtigung. Ein Bereich ist auch kein normales Dateisystemverzeichnis, in dem Unterordner automatisch eine eigene Sicherheitsgrenze bilden.

Eine Datenverbindung enthält nicht einfach eine zweite Kopie aller Quelldaten. Erst ein Ladeprozess holt die ausgewählten Daten in die App beziehungsweise schreibt eine QVD. Deshalb prüfen wir Verbindung, gespeicherte Dateien und App getrennt. Wer eine fertige App sehen soll, benötigt dafür nicht automatisch die Möglichkeit, ihre Quelldaten in eigenen Apps wiederzuverwenden.

Herstellerhilfe zu Bereichen · Sammlungen und deren Sichtbarkeit

Welche Art Bereich verwende ich wann?

Ein persönlicher Bereich eignet sich im Referenzmodell für eigene Lernversuche mit synthetischen Daten. Produktive Lieferketten legen wir dort nicht an: Betrieb und Zusammenarbeit sollen einen geregelten Übergang zwischen Personen erlauben. Das ist eine Organisationsentscheidung; „persönlich“ allein ist kein vollständiges Datenschutzkonzept.

Ein freigegebener Bereich / Shared space ist unser Arbeitsbereich für Entwicklung und Zusammenarbeit. Dort können berechtigte Mitglieder gemeinsam Inhalte bearbeiten. Ein verwalteter Bereich / Managed space ist das Veröffentlichungsziel für freigegebene Apps. Wir entwickeln die Source-App außerhalb dieses Ziels und veröffentlichen anschließend eine geprüfte Fassung dorthin. Managed Spaces sind nicht in jeder Subscription enthalten, insbesondere nicht in Analytics Starter und Qlik Sense Business. Prüfe das vor dem Aufbau.

Ein Datenbereich / Data space gehört zu Qlik Talend Data Integration. Wir wählen ihn nicht bloß deshalb, weil eine QVD „Daten“ enthält. In unserem reinen Analytics-Beispiel sind auch die beiden QVD-Ablagen Shared Spaces. Ihre Rolle ergibt sich aus den zugewiesenen Rechten und der Betriebsorganisation, nicht aus dem Wort DATA im Namen.

Unser Zielbild: fünf Bereiche statt beliebiger Projektordner

Das sind fünf geplante Bereiche, nicht fünf zusätzliche Qlik-Bereichstypen. AUFBEREITET bedeutet fachlich und technisch für einen bestimmten Zweck vorbereitet, nicht automatisch anonym oder unternehmensweit freigegeben. Ein einfacher Pilot kann mit Entwicklung und Produktion beginnen. Die zusätzlichen Bereiche rechtfertigen sich erst durch unterschiedliche Mitglieder, Schutzanforderungen oder Betriebsabläufe. Wenn dieselben Personen alles bearbeiten und keine unabhängige Abnahme vorgesehen ist, erzeugt ein Testbereich allein noch keine Funktionstrennung.

Die KPI-App und eine bei Bedarf eingerichtete Detailanalyse erhalten im späteren KPI-/PII-Kapitel einen klaren Datenumfang. Für dieselbe Periode, Region und Definition müssen die Werte zusammenpassen; ein Detailzugriff wird nach tatsächlichem Analysebedarf vergeben. Zwei Bereiche innerhalb eines Tenants sind außerdem kein Ersatz für eine geforderte Trennung ganzer Umgebungen.

Namensgebung: ein lesbares Schema mit stabilen Kennungen

Referenzkonvention: <FACHBEREICH>-<UMGEBUNG>-<INHALT>[-<SCHUTZSEGMENT>]. Wir schreiben die Bedeutung aus: VERTRIEB ist der Fachbereich, ENTWICKLUNG, TEST und PRODUKTION sind die Umgebungen, APPS oder DATEN beschreiben den Inhalt. Bei Daten kann EINGESCHRAENKT beziehungsweise AUFBEREITET den vorgesehenen Umgang kennzeichnen. Verwende für technische Namen einfache ASCII-Zeichen und Bindestriche, damit Skripte, Tickets und Suchvorgänge konsistent bleiben. Das ist unsere Empfehlung, keine von Qlik vorgeschriebene Namensregel.

Ein Anzeigename darf sich ändern. APIs, Katalogzuordnungen und Release-Register beziehen sich zusätzlich auf die tatsächlichen Objekt-IDs. Schreibe keine Passwörter, Kundennamen oder einzelnen Personennamen in technische Ressourcennamen. Hänge nicht bei jedem Release ein Datum an die produktive App an; dokumentiere Release-ID und Freigabe separat. Sonst vervielfachen sich Apps und Lesezeichen zeigen auf veraltete Fassungen.

Als Kundenprojekt mit Formularen durchführen

Für ein Kundenprojekt reicht die technische Einrichtung nicht aus. Kläre zuerst, welche Entscheidung der Kunde treffen möchte, welche Daten dafür nötig sind und woran er die Lieferung abnimmt. Die Projektwerkstatt: Anforderungen bietet dafür ausfüllbare Register mit eindeutigen REQ-IDs. Unter Workshop werden Entscheidungen und Umsetzungspakete auf diese IDs bezogen; unter Abnahme werden erwartetes und tatsächliches Ergebnis sowie Kundennachweis dokumentiert. Der Wechsel zwischen diesen drei Reitern erhält die gemeinsamen Eingaben.

Der sechsphasige Projektplan führt durch Auftrag, Kundenworkshop, Tenant-/IAM-Zielbild, Pilot, Abnahme und Betriebsübergabe. Die sechs Wochen sind eine anpassbare Startannahme, keine Lieferzusage. Fachliche Entscheidungsrechte, Aufwand und Voraussetzungen werden mit dem Kunden konkretisiert.

Gesamtprojektdoku: Den Tenant-Steckbrief als JSON-Arbeitsdatei herunterladen und in der Projektwerkstatt als technische Anlage einbinden. Anschließend enthält der gemeinsame Markdown-/HTML-Export Anforderungen, Entscheidungen, Risiken, Umsetzungspakete, Tests, Freigabeverweise und Tenant-Inventar. Projekt-ID, Version und Kapitelreferenz verbinden ihn mit eurer Governance-Gesamtdokumentation. Nachweise und signierte Entscheidungen bleiben an der vereinbarten, passend berechtigten Projektablage. Arbeitsdateien und Planner-Status werden nicht automatisch synchronisiert.

Was ist der Tenant-Steckbrief?

Der Tenant ist eure konkrete Qlik-Cloud-Umgebung, identifizierbar über ihre Tenant-ID und Adresse. Der Tenant-Steckbrief ist das Deckblatt ihrer Betriebsdokumentation: Er erklärt einer neuen Administratorin oder Vertretung, um welche Umgebung es geht, was dort eingerichtet ist, wer verantwortlich ist und welche Angaben noch ungeklärt sind. Er ist unser Dokumentationsmuster, kein besonderer Qlik-Dialog und keine Datei, die Qlik automatisch für euch erstellt.

Du erstellst ihn zu Beginn des Pilots und aktualisierst ihn nach Tarifwechsel, IdP-/Gateway-Änderung, Verantwortungswechsel und produktiven Releases. Technische IDs und tatsächliche Prüfstände stammen aus eurer Umgebung. Fehlende Informationen bleiben OFFEN, statt mit Beispielwerten als vorhanden zu erscheinen. Fachliche Verantwortung und technische Eigentümerschaft werden getrennt erfasst.

Tenant-Steckbrief ausfüllen und Dokumentation erzeugen

Das Tool bietet neben dem Steckbrief wiederholbare Tabellen für Bereiche, Gruppenrechte, Verbindungen und Apps. Es erzeugt Markdown für Wiki/Git und eine eigenständige HTML-Dokumentation, die du öffnen und über den Druckdialog als PDF speichern kannst. Mit der heruntergeladenen JSON-Arbeitsdatei lässt sich die Erfassung später fortsetzen. Es fragt keinen Tenant automatisch ab und bestätigt keine Einrichtung. Passwörter, Tokens und Recovery-Codes gehören in ihre geschützte Ablage; hier stehen nur Verweise darauf.

Kopierbare Vorlage: Deckblatt der Tenant-Dokumentation

Kopiere den folgenden Markdown-Block in euer Wiki oder nutze ihn als leere Vorlage im Tool. Die rechte Spalte erklärt, woher die Angabe kommt. OFFEN wird erst durch einen tatsächlich ermittelten Wert ersetzt. Der vollständige Bereichs- und Rechtebestand kommt in die nachfolgenden Inventartabellen; im Steckbrief genügt der Verweis auf dieses Register.

# Qlik Cloud – Tenant-Steckbrief

Status: Arbeitsstand, keine technische oder fachliche Freigabe

| Angabe | Unser Stand | Woher / worauf achten? |
|---|---|---|
| Organisation / Projekt | OFFEN | eigene Zuordnung |
| Tenant-ID | OFFEN | tatsächliche Tenant-Kennung |
| Originalhostname / URL | OFFEN | eigene Cloudadresse, keine Screenshot-Adresse |
| Region / Datenresidenz | OFFEN | Deployment-/Vertragsunterlagen abgleichen |
| Subscription / Tarif | OFFEN | aktuell gebuchter Stand |
| Verfügbare Funktionen | OFFEN | im Tenant und Tarif prüfen |
| Erfasst am | OFFEN | Datum dieser Bestandsaufnahme |
| Fachliche Verantwortung | OFFEN | mandatierte Rolle und Zuständigkeit |
| Technischer Betrieb | OFFEN | Betriebsrolle und Supportweg |
| Vertretung | OFFEN | benannte Rolle / Eskalationsweg |
| IdP / SSO / SCIM | OFFEN | Verfahren und IAM-Verantwortung |
| Gateway-/Connectorversionen | OFFEN | tatsächlich installierte Versionen |
| Erlaubte Zwecke / Datenumfang | OFFEN | fachliche Freigabe referenzieren |
| Namenskonvention | OFFEN | vereinbarte Regel, z. B. VERTRIEB-ENTWICKLUNG-APPS |
| Bereichs-/Rechte-/App-Register | OFFEN | Dokument oder Tool-Ausgabe referenzieren |
| Recovery-Verfahren | OFFEN | nur geschützter Verweis, keine Codes |
| Veröffentlichung / Rückweg | OFFEN | Verfahren und Release-Register |
| Prüfende Rolle / letzte Prüfung | OFFEN | tatsächliche Prüfung mit Datum |
| Nächste Prüfung | OFFEN | vereinbarter Termin |
| Offene Punkte | OFFEN | Maßnahme, Verantwortung und Termin |

So wird aus der Vorlage eine nutzbare Doku

1. Fülle zuerst Tenant-ID, Adresse, Tarif und Verantwortlichkeiten aus. Beschaffe fehlende Angaben beim zuständigen Betrieb; kopiere keine Werte aus unserem synthetischen Beispiel.
2. Ergänze pro Bereich, Verbindung und App deren tatsächliche ID im Inventar. Gruppen werden mit Ziel und Rolle dokumentiert. Anzeigenamen allein reichen für die Wiedererkennung nach einer Umbenennung nicht.
3. Halte pro Prüfung Status und Nachweis fest. „Geplant“ bedeutet noch nicht eingerichtet. Ein Eintrag „geprüft“ ohne Datum/Beleg bleibt im Tool als fehlender Nachweis sichtbar.
4. Exportiere das Dokument und die JSON-Arbeitsdatei. Lege sie an der für eure Betriebsdokumentation vorgesehenen, passend berechtigten Stelle ab und verweise vom Release-Ticket darauf.
5. Lass die zuständige Rolle den Stand prüfen und halte deren Freigabe im vereinbarten Verfahren fest. Das Erzeugen einer Datei ist keine Freigabe.

Tenant-Steckbrief und sicherer Rückweg

Erfasse vor Änderungen Tenant-ID, Originalhostname, Region, Subscription und tatsächlich verfügbare Funktionen. Halte auch die Version installierter Gateways und Connectoren separat fest. Qlik Cloud ist SaaS; erfinde dafür keine feste Qlik-Sense-Windows-Releasekennung. Plane vor jedem Veröffentlichungswechsel eine gesicherte, zuletzt akzeptierte Fassung und die verantwortliche Person für die Rücknahme. Teste die Wiederherstellung zuerst im Labor. Ein App-Backup allein sichert nicht automatisch jede externe Verbindung oder deren Credentials.

Schritt für Schritt: die Planung vor dem ersten Klick

1. Öffne den Unternehmens-Use-Case und formuliere einen einzigen Satz zum Zweck: „Monatsumsätze nach Region zur Vertriebssteuerung“. Definiere Zeitraum, Regionsumfang und Vergleichsmonat. Kläre anschließend, ob für eine Abweichungsanalyse Belegdetails benötigt werden. Kundenkontakt ist keine Voraussetzung für diese KPIs.
2. Lege eine Tabelle mit den fünf Zielbereichen an. Für jeden Eintrag erfasse Name, Qlik-Typ, fachlichen Owner, technischen Betreiber, Stellvertretung und vorgesehene Mitgliedergruppen. Noch keine pauschale Tenant-Mitgliedschaft vergeben.
3. Prüfe die Subscription und Erstellerrollen. Fehlt Managed Space, halte die Abweichung fest: kontrollierte Veröffentlichung ist in dieser Ausprägung nicht umsetzbar. Eine andere Bezeichnung für einen Shared Space behebt die Funktionslücke nicht.
4. Erstelle das Objektregister. Nutze zunächst Platzhalter für IDs; fülle sie nach dem Anlegen aus. Registriere Entwicklungs-App und veröffentlichte Produktions-App als unterschiedliche Objekte.
5. Vereinbare die Namenskonvention mit dem Team. Eine zweite Person muss aus VERTRIEB-TEST-APPS Umgebung und Zweck erkennen können, ohne den Ersteller zu kennen. Kann sie es nicht, ist die Konvention noch nicht erklärt.
6. Plane drei Testkonten: Entwicklung, Consumer und ausgeschlossen. Ergänze später einen gesonderten Reload-Account und klartextberechtigte Testidentitäten. Keine echten Kundeninformationen für die Grundübung verwenden.
7. Gehe zu Identitäten und Gruppen, danach zu Bereiche und Sammlungen konkret einrichten. Dort wird aus dieser Tabelle eine überprüfbare Einrichtung.

Beschreibung und Objektregister am Beispiel

Zweck: Freigegebene monatliche Vertriebsanalyse
Umgebung: Produktion
Fachliche Verantwortung: Rolle Sales Owner
Technischer Betrieb: Rolle Analytics Operations, Vertretung benannt
Erlaubte Daten: Monatsumsatz je Region; keine Kontaktfelder
Zugang: QLIK-VERTRIEB-PRODUKTION-APPS-LESEN nach Freigabe
Änderungsweg: Entwicklung -> Test -> Veröffentlichung nach Produktion
Support: internes Team-Postfach oder Serviceportal
Prüfung: Datum, Verantwortliche und nächste Prüfung im Register

Diese Informationen pflegst du in den dafür verfügbaren Beschreibungsfeldern und im Betriebsregister. Qlik bietet nicht für jede fachliche Verantwortlichkeit ein eigenes Pflichtfeld. Die technische Eigentümerrolle ist deshalb nicht automatisch der fachliche Owner.

Übung: eine fremde Struktur beurteilen

Du findest die Sammlung „Produktion“, die App „Umsatz final“ und eine Verbindung im persönlichen Bereich des ehemaligen Entwicklers. Schreibe drei getrennte Befunde: Die Sammlung erklärt nicht den tatsächlichen Veröffentlichungsbereich; der App-Name liefert keinen Freigabebeleg; die Verbindung hat eine ungeklärte Betriebsabhängigkeit. Die Lösung ist nicht bloß Umbenennen. Ordne Verantwortlichkeit und IDs zu, prüfe Datenpfad und Rechte und migriere anschließend kontrolliert. Nach dem Wechsel muss die gleiche Consumer-Testperson die freigegebene App nutzen können, während das ausgeschlossene Konto weiter scheitert.

Quellen, Hilfe und Lernmaterial

• Qlik: Space-Typen / Space types
• Qlik: Managed-space permissions
• Qlik: Microsoft Entra ID / SAML
• Qlik: Data connections in spaces
• EDPB: Controller and processor
• Qlik: What is new / staged rollouts

Bei Videos hat die aktuelle schriftliche Hilfe Vorrang. Externe Medien werden vom jeweiligen Anbieter bereitgestellt.