Odoo Studio: Eigene Modelle, Views und Automatisierungen ohne Programmieraufwand

Einleitung

Odoo Studio entfaltet seinen Wert erst, wenn die Basissysteme stimmen: Dashboards, Dokumente, Studio‑Erweiterungen und IoT‑Funktionen schaffen erst dann nachhaltigen Nutzen, wenn Vertriebs-, Lager‑ und Finanzdaten verlässlich sind.

Teams steigen meist mit der reinen Transaktionsnutzung in Odoo ein. Erst danach wächst der Wunsch nach besseren Auswertungen und individuell zugeschnittenen Oberflächen — an dieser Stelle kommen Plattform‑Apps und durchdachte Anpassungen ins Spiel.

Mit Studio können Entscheider und Power‑User steuern, wie Informationen dargestellt und erreicht werden, ohne dabei die zugrundeliegende Datenstruktur zu zerstören.

COOs, Product Owner und interne Odoo‑Champions erkennen beim nächsten Reifegrad, wann Standardapps erweitert werden können und wann es besser ist, externe Expertise hinzuzuziehen.

Studio ist ein Modul des Odoo‑ERP. Teams greifen zu, wenn sie klare Verantwortlichkeiten, reproduzierbare Abläufe und durchsuchbare Historien statt verstreuter Chats und Offline‑Tabellen wollen. Kurz gesagt: Odoo Studio steht für eigene Modelle, Ansichten und Automatisierungen ganz ohne Code — ein klares Argument für Entscheider.

Dieser Beitrag ist ein geranktes Top‑10‑Verzeichnis von Level 1 (einsteigerfreundlich) bis Level 10 (Experten). Zu jedem Level gibt es nummerierte Schritte: die konkreten Klicks in Odoo Studio.

Fang dort an, wo dein Team sich wohlfühlt — nicht bei Level 10 nur weil es imponiert.

Lies zuerst die Herausforderung durch und öffne dann das Level, das dem Zustand deines Teams heute entspricht.

In diesem Leitfaden findest du:

• Welche Rolle Odoo Studio typischerweise in der Systemlandschaft übernimmt
• Wo Anwender heute am meisten Reibung spüren (und weshalb)
• Zehn priorisierte Use‑Cases vom einfachen Praxisgewinn bis zur strategischen Architektur
• Wann Automatisierung oder Integrationen das Hinzuziehen eines Odoo‑Partners rechtfertigen

Die Herausforderung

Führungskräfte öffnen ein hübsches Dashboard — und fragen dann, warum der Kassenstand nicht mit der Buchhaltung übereinstimmt. Hinterher stellt sich heraus: Ein View basiert auf unvollständigen Transaktionsdaten, und aus Vertrauen wird erstmal Misstrauen statt Entscheidungsgrundlage.

Erwartungen: Individuelle Einblicke und maßgeschneiderte Prozesse. Realität: Daten‑ und Anpassungswildwuchs ohne Governance. Dashboards und Studio‑Änderungen helfen nur, wenn sie auf sauberen, transaktionalen Daten aufbauen.

Klingt vertraut? Typische Stolpersteine sind:

• KPIs, die nicht der operativen Realität entsprechen
• Anpassungen ohne Sandbox‑Disziplin und Versionskontrolle
• Integrationen, die nach Updates lautlos ausfallen

Die gute Nachricht: Es braucht keinen Big‑Bang‑Umbau. Wähle einen Use‑Case aus, teste ihn 30 Tage in Odoo Studio und messe die Wirkung.

Top‑10 Studio‑Use‑Cases

Zehn praktische Studio‑Use‑Cases, gerankt von Level 1 (sofort umsetzbar) bis Level 10 (architektonisch anspruchsvoll). Zu jedem Fall: Was bauen wir und welche Schritte klickst du in Studio?

Level 1 bringt schnelle Alltagsgewinne. Das letzte Level ist bewusst ambitioniert, damit du siehst, wie groß die gleiche App werden kann, wenn Architektur und Daten sauber bleiben.

Wähle dein Level, probiere die nummerierten Schritte in einer Testdatenbank aus und steigere dich erst, wenn das Vorherige zur Routine geworden ist.

1. In zwei Minuten ein benutzerdefiniertes Feld in der Kundenmaske hinzufügen Level 1 — Einfach

Level 1 ist die kleinste Studio‑Aktion: ein Administrator ergänzt ein fehlendes Feld, kein Code, keine Migration. Feld ziehen, ablegen — beim nächsten Laden sehen alle Nutzer das neue Feld.

So würdest du vorgehen:

1. Öffne einen Kontakt, klicke oben rechts auf das Studio‑Icon.
2. Ziehe ein Char‑Feld aus der Toolbox unter den Firmennamen und platziere es.
3. Gib dem Label den Namen "Account Manager Notes" und ergänze einen Tooltip, der erklärt, was eingetragen werden soll.
4. Speichere — das Feld steht jetzt allen Nutzern in jedem Sichtmodus zur Verfügung.
5. Öffne einen anderen Kunden, trage etwas ein und prüfe das Chatter‑Log auf die Änderung.

Nutzen: Fehlende Informationen werden noch am selben Tag strukturiert erfasst — ohne IT‑Ticket oder Entwicklerlaufzeit.

2. Compliance‑Tab mit gruppierten Feldern und bedingter Sichtbarkeit anlegen Level 2 — Einfach

Level 2 erweitert die Benutzeroberfläche: Zusammengehörige Angaben kommen in einen eigenen Reiter, damit Nutzer nicht die ganze Maske durchsuchen müssen.

So würdest du vorgehen:

1. Im Studio einen neuen Tab neben den bestehenden hinzufügen und "Compliance" nennen.
2. In den Tab eine Section ziehen und drei Felder anlegen: VAT Verified (Boolean), NDA Signed (Boolean), Last Audit Date (Date).
3. Stelle die Sichtbarkeit des Tabs so ein, dass er nur bei Firmenkontakten erscheint, nicht bei Privatpersonen.
4. Aktiviere für die drei Felder das Änderungsprotokoll, sodass das Chatter festhält, wer wann was geändert hat.
5. Speichere, lade die Seite neu und prüfe, dass der Compliance‑Tab nun zwischen Sales und Internal Notes bei Firmen erscheint.

Nutzen: Compliance‑Infos liegen direkt auf der Kundenkarte statt in einer separaten, schnell veraltenden Tabelle.

3. Eigene Kanban‑Ansicht für das morgendliche Sales‑Standup bauen Level 3 — Einfach

Level 3 führt alternative Views ein. Sales‑Daten werden zu einem Board nach Team gruppiert, farblich nach Deadlines markiert — ideal für ein zehnminütiges Standup.

So würdest du vorgehen:

1. Im Sales‑Modul Orders öffnen, Studio starten, Views auswählen und eine neue Kanban‑Ansicht hinzufügen.
2. Karten so gestalten, dass Kundenname, erwarteter Umsatz und Verkäufer angezeigt werden; eine Farbregel nach Deadline einrichten.
3. Records nach Sales Team gruppieren und einen Schnellfilter Active = True setzen, damit abgeschlossene Deals ausgeblendet bleiben.
4. Die Ansicht als Standard für die Sales‑Manager‑Gruppe per View‑Zugriffsoptionen pinnen.
5. Das nächste Morning Standup vom Board abhalten: Karten verschieben — Änderungen sind sofort für alle sichtbar.

Nutzen: Manager führen ein kurzes, visuelles Meeting von einer Oberfläche statt mit mehreren Reports und wiederholten Erläuterungen.

4. Angebots‑PDF mit Branding und bedingten Blöcken anpassen Level 4 — Mittel

Level 4 betrifft Ausdrucke: Im Report‑Editor von Studio gestaltest du Angebots‑PDFs mit Firmenbranding, dynamischen Summen und Bedingungslogik.

So würdest du vorgehen:

1. Einstellungen → Studio → Reports, den Quotation/Order‑Report zum Sales Order‑Modell öffnen.
2. Im Layout‑Editor Logo in die Kopfzeile einfügen und Spaltenreihenfolge anpassen: Beschreibung, Einzelpreis, Menge, Steuern, Zwischensumme.
3. Einen bedingten Block einfügen, der nur im Zustand draft erscheint und ein "Valid 30 days"‑Banner in Markenfarbe zeigt.
4. Footer mit Zahlungsbedingungen dynamisch aus dem Kundenstamm ziehen, damit jedes PDF dem Vertragsstatus entspricht.
5. Speichern, Studio verlassen und ein Testangebot per Mail verschicken, um das Ergebnis zu prüfen.

Nutzen: Vertrieb versendet rechtssichere, markenkonforme Angebote ohne jedes Mal Grafik oder Finance um Anpassung bitten zu müssen.

5. Neue No‑Code‑App für internen Workflow aufsetzen Level 5 — Mittel

Level 5 geht vom Anpassen zum Erschaffen: Du legst eine komplett neue App für einen internen Prozess an — ganz ohne eine einzige Zeile Code.

So würdest du vorgehen:

1. Studio öffnen, New App klicken, "Equipment Loan" als Namen vergeben, Icon und Farbe wählen und Menü sowie Datenbanktabelle erstellen lassen.
2. Im neuen Modell Felder anlegen: Asset Name (Char), Borrower (Many2one → res.users), Loan Date (Date), Due Date (Date), Status (Selection).
3. Standard‑Kanban, List‑ und Form‑Views erzeugen und das Formular so anpassen, dass Status als Statusbar oben angezeigt wird.
4. Menü unter Inventory platzieren und Lese/Schreibrechte für die Employee‑Gruppe vergeben, damit Mitarbeiter Leihanfragen stellen können.
5. Test: Zwei Leihaufträge anlegen und einen durch alle Status bewegen, um den End‑to‑End‑Ablauf zu prüfen.

Nutzen: Ein bisher ungetrackter Prozess erhält eine digitale Spur mit Besitzern, Fristen und Manager‑Übersicht.

6. Überfällige Erinnerungen mit einer No‑Code‑Serveraktion automatisieren Level 6 — Mittel

Level 6 fügt Logik hinzu. Studio‑Automationen lösen Aktionen bei Feldänderungen, Zeitintervallen oder beim Anlegen von Datensätzen aus — ganz ohne Python.

So würdest du vorgehen:

1. Im Equipment Loan‑App Studio → Automations öffnen und eine neue Regel anlegen.
2. Trigger: On Update of Status, neuer Wert = Overdue, Modell = Equipment Loan.
3. Füge zwei Aktionen hinzu: E‑Mail‑Template an den Borrower mit Asset‑Name und Due Date senden und eine rote Notiz im Chatter posten.
4. Zweite Regel: täglicher Zeit‑Trigger um 9:00 Uhr, der Loans mit Due Date < Heute findet und Status auf Overdue setzt.
5. Test: Leihdatensatz mit vergangenem Fälligkeitsdatum anlegen und prüfen, dass die nächtliche Ausführung Status ändert und die E‑Mail versendet wird.

Nutzen: Erinnerungen laufen automatisiert, niemand jagt manuell überfällige Assets hinterher — Manager müssen nicht mehr fragen, ob etwas zurückkam.

7. Mehrstufigen Freigabeprozess mit bedingten Buttons bauen Level 7 — Schwer

Level 7 macht Studio zum Workflow‑Motor. Beschaffungsanträge bekommen Statusbar, rollenbasierte Buttons und Logik, die vorschreibt, wer was verschieben darf.

So würdest du vorgehen:

1. Purchase Request‑Modell anlegen mit Feldern Requester, Amount, Justification, Approver und Status‑Statusbar (Draft, To Approve, Approved, Refused).
2. Formular‑Buttons hinzufügen: Submit (nur im Draft sichtbar), Approve und Refuse (nur im To Approve sichtbar und nur für Manager‑Gruppe).
3. Buttons so konfigurieren, dass sie den Record in die nächste Phase schieben und beim Submit automatisch einen Approver zuweisen.
4. Studio‑Automation: Wird ein Record Approved und Amount > 5000, dann E‑Mail an CFO für zweite Freigabe senden.
5. Filter "My Pending Approvals" speichern und im Dashboard der Manager anpinnen, damit sie nur wartende Anfragen sehen.

Nutzen: Ausgabensteuerung läuft innerhalb von Odoo mit lückenlosem Audit‑Trail statt über zerstreute E‑Mails, die schnell verloren gehen.

8. Ein Custom‑Modell per Record Rules und Gruppenrechte absichern Level 8 — Schwer

Level 8 betrifft Sicherheit: Dieselbe Equipment‑App benötigt unterschiedliche Rechte je Rolle; Studios Sicherheitslayer regelt, wer welche Datensätze lesen oder ändern darf.

So würdest du vorgehen:

1. Einstellungen → Benutzer & Firmen → Gruppen: Equipment Manager und Equipment Employee mit klaren Beschreibungen anlegen.
2. Im Studio für das Equipment Loan‑Modell Lese‑, Schreib‑, Erstell‑ und Löschrechte pro Gruppe setzen: Employee darf eigene Loans anlegen/lesen, Manager darf alles bearbeiten.
3. Record Rule hinzufügen: Equipment Employee sieht nur Loans, bei denen Borrower = aktueller Nutzer; Manager sieht alle Einträge der Firma.
4. Sensitive Felder (z. B. Approval Notes, Acquisition Cost) für die Employee‑Gruppe via Feldsichtbarkeit ausblenden.
5. Als Testnutzer einloggen, bestätigen, dass andere Leihdatensätze nicht sichtbar sind, dann als Manager prüfen, dass Vollzugriff besteht.

Nutzen: Eine App dient allen Rollen, aber jede Rolle sieht wirklich nur, was sie sehen darf — keine separaten Datenbanken und geringeres Leckage‑Risiko.

9. Custom‑Modell mit CRM, Inventory und Projekt per Smart Buttons verbinden Level 9 — Schwer

Level 9 ist Integration: Das Equipment Loan‑Modell wird kein Insel‑Datenbestand mehr, sondern liefert Signale an Kundenstamm, Projekte, Lager und CRM.

So würdest du vorgehen:

1. Many2one‑Feld von Equipment Loan zu res.partner ergänzen, damit jeder Loan mit einem Kunden/Partner verknüpft werden kann.
2. Auf der Kundenkarte per Studio einen Smart Button "Open Loans" hinzufügen, der Equipment Loan nach Partner filtert und die Anzahl live anzeigt.
3. Auf dem Loan ein related‑Feld ergänzen, das das offene Forderungsvolumen des Kunden zeigt, damit Finance vor einer Genehmigung Risiken sieht.
4. Studio‑Automation: Wird ein Loan auf Returned gesetzt, erstelle automatisch eine Inventory‑Aufgabe für das Lager zur Asset‑Prüfung.
5. Loan‑Smart‑Button auch auf der Projekt‑Maske anzeigen, wenn Kunde und Projekt übereinstimmen, sodass beide Timelines verknüpft werden.

Nutzen: Equipment, Kunden, Lager und Projekte teilen eine Timeline; niemand tippt Daten doppelt ein und Teams arbeiten auf derselben Datengrundlage.

Das Vernetzen von Related‑Feldern, Smart Buttons, Automationen und Sicherheitsregeln über mehrere Standard‑Apps und ein Custom‑Modell ist genau das, worin Dasolo als Partner‑geführtes Studio‑Engagement spezialisiert ist.

10. No‑Code Customer‑Health‑Mini‑App mit AI, Dashboards und BI‑Sync betreiben Level 10 — Experte

Level 10 ist die Königsklasse. Studio orchestriert eine Customer‑Health‑Mini‑App, die Signale aus allen Modulen zusammenführt, Risiko‑Scores berechnet, Odoo‑AI für Zusammenfassungen nutzt und Leadership‑Dashboards in Echtzeit beliefert.

So würdest du vorgehen:

1. Customer Health‑Modell bauen mit Feldern Score, Last NPS, Open Tickets, Overdue Invoices, Last Order Date und AI Summary, gefüllt durch Studio‑related Fields aus CRM, Helpdesk, Sales und Accounting.
2. Nacht‑Automation einrichten, die den Score per gewichteter Formel neu berechnet und Status zwischen Healthy, Watch, At Risk und Churn Imminent umschaltet.
3. Odoo‑AI‑Action einbauen: Montags die letzten 30 Tage Chatter analysieren und eine ein‑absätzige Risiko‑Zusammenfassung in AI Summary schreiben lassen.
4. Record Rules konfigurieren, sodass Account Manager nur ihre Kunden sehen, Führungskräfte das Gesamtportfolio mit geschwärzten Notizen einsehen können.
5. Customer Health als Smart Button in jede CRM‑Opportunity einbetten, damit Score und AI‑Summary direkt im Deal‑Review sichtbar sind.
6. Spreadsheet‑Dashboard "Customer Risk Live" bauen, das Kunden nach Score rankt, in Echtzeit refreshed und per Webhook die Top‑10‑Risiken in einen Discuss‑Kanal postet.
7. Dataset per Studio‑Webhook an ein externes BI‑Tool (Looker, Power BI) synchronisieren, damit Führung und CRM dieselben Kennzahlen sehen.

Nutzen: Eine zentrale Mini‑App, ohne Code, liefert für alle dieselbe Sicht auf Kundenrisiko — die AI liest, Studio vernetzt, Menschen handeln, um Accounts zu retten.

Die Modell‑Architektur, AI‑Prompts, Sicherheitsregeln, Echtzeit‑Dashboards und externe Syncs zu designen, ist die Art von Architekturarbeit, die Dasolo in partnergeführten Studio‑Programmen liefert. Die meisten Teams brauchen externe Hilfe, um die Cross‑App‑Verklebung beim ersten Mal sauber hinzubekommen.

Wann externe Hilfe sinnvoll ist

Passen Level 1–6 zu eurem Alltag, reicht oft Studio‑Standard, ein engagierter interner Owner und eine Sandbox, in der gefahrlos getestet werden darf.

Ab Level 7 steigen die Risiken: Automationen können falsche Mails senden, Studio‑Felder Upgrade‑Pfade blockieren, APIs nachts stillschweigend die Lagerbestände nicht mehr synchronisieren.

Das ist kein Teamversagen — es signalisiert, dass Architektur, Testing und Governance jetzt wichtig werden.

Zieht einen Partner hinzu, wenn ihr Multi‑App‑Design, länderspezifische Compliance, komplexe Integrationen oder einen fixen Go‑Live‑Termin habt, den der Vorstand vorgibt.

Zusammenarbeit mit Dasolo

Dasolo unterstützt Unternehmen dabei, Odoo so umzusetzen, wie sie tatsächlich arbeiten: maßgeschneiderte Apps, saubere Integrationen und Schulungen, die nach dem Projekt im Betrieb haften.

Wenn euer Studio‑Roadmap die fortgeschrittenen Use‑Cases dieses Leitfadens enthält, erstellen wir einen Phasenplan: schnelle Erfolge zuerst, danach Automatisierung und Integrationen mit klaren Verantwortlichkeiten und Testskripten.

Ihr behaltet Umfang und Budget‑Kontrolle. Wir bringen die Odoo‑Tiefe, damit euer Team nicht in der Produktion teure Fehler lernen muss.

Kostenlose Erstberatung:

Demo vereinbaren