Mein Formular schreibt keine Daten in onOffice

Wenn ein Formular zwar abgesendet wird, die Daten aber nicht in onOffice ankommen — oder nur unvollständig —, liegt das in 9 von 10 Fällen an den Rechten des onOffice-Benutzers, mit dem propform spricht. Hier die häufigsten Ursachen, in der Reihenfolge der Wahrscheinlichkeit:

1. API-Benutzer-Rechte sind nicht (vollständig) gesetzt

Der API-Benutzer in onOffice braucht passende Lese- und Schreibrechte für alle Module, die dein Formular bedient (Adressen, Immobilien, Aktivitäten, Aufgaben, Termine, Suchkriterien, Vorlagen).

Lösung: Die kompletten empfohlenen Rechte sind hier dokumentiert: onOffice API-Benutzer-Rechte.

Achte besonders darauf, dass Lese- UND Schreibrechte auf „alle" stehen (nicht „nur eigene"), wenn dein Formular Datensätze von anderen Mitarbeitern bearbeiten soll.

2. Adresse hat den Haken „Privat" gesetzt

Wenn ein Mitarbeiter in onOffice bei einem Adressdatensatz den „Privat"-Haken setzt, kann niemand außer dem setzenden Benutzer diese Adresse mehr lesen oder bearbeiten — auch der API-Benutzer nicht.

Symptome:

• Formular meldet „Adresse nicht gefunden", obwohl die UUID korrekt ist
• Bestimmte einzelne Adressen lassen sich nicht laden, andere schon

Lösung:

• In onOffice die betroffene Adresse öffnen
• Privat-Haken entfernen, oder
• Die Adresse dem API-Benutzer übertragen

3. Datensatzrechte sind eingeschränkt

In onOffice können auf einzelne Adressen, Immobilien, Vorlagen oder Vorlagen-Ordner Datensatzrechte gesetzt sein, die den API-Benutzer ausschließen.

Häufige Fälle:

• Eine PDF-Exposé-Vorlage liegt in einem Ordner mit eingeschränkten Rechten → propform kann das Exposé nicht generieren
• Eine E-Mail-Vorlage hat Lese-Beschränkungen → propform kann die Vorlage nicht zum Versand nutzen
• Bestimmte Adressen oder Immobilien sind nur für eine Benutzergruppe sichtbar → propform kann sie nicht laden

Lösung:

• In onOffice die jeweiligen Datensatzrechte prüfen (Rechtsklick auf Datensatz/Vorlage/Ordner → Berechtigungen)
• Den API-Benutzer (oder seine Gruppe) zur Berechtigung hinzufügen

⚠️ Häufiger Übersehe-Fehler bei Vorlagen: Es gibt drei Rechte-Ebenen für E-Mail-/PDF-Vorlagen:

1. Die Vorlage selbst (Schraubenschlüssel auf der Vorlage → Datensatzrechte)
2. Der Vorlagen-Ordner, in dem die Vorlage liegt (Schraubenschlüssel auf dem Ordner!) ← oft vergessen
3. Der API-User unter Reiter „Rechte" → Bereich „Word, E-Mail-Vorlagen, Dateien" → „Vorlagen Lesen → alle"

Wenn die Vorlage in propform nicht im Auswahl-Dropdown erscheint, prüfe alle drei Ebenen.

4. API-Benutzer ist keiner Gruppe zugeordnet (Gruppen-Modul aktiv)

Wenn dein onOffice-System das Gruppen-Modul verwendet, sieht ein Benutzer standardmäßig nur Datensätze, die zu seinen Gruppen gehören. Ist der API-Benutzer keiner Gruppe zugeordnet, sieht er entsprechend wenig.

Lösung: Den API-Benutzer einer Gruppe mit möglichst umfassendem Leserecht zuordnen.

So gehst du vor in onOffice:

1. Klicke in der Menüleiste auf Extras → Einstellungen → Benutzer
2. Wähle den API-Benutzer aus
3. Wechsle auf den Reiter „Gruppen"
4. Füge den Benutzer zu einer Gruppe hinzu, die maximales Leserecht hat (oder lege ggf. eine eigene „API-Benutzer"-Gruppe an)

Falls du dir unsicher bist, welche Gruppe die richtige ist, frage deinen onOffice-Administrator oder den onOffice-Support.

5. Feld in onOffice nicht aktiviert

Wenn ein bestimmtes Feld in deinem Formular keine Daten überträgt, prüfe in der onOffice-Administration, ob das Feld dort überhaupt aktiviert ist. Inaktive Felder werden propform nicht angeboten — und wenn du es per Migration kopiert hast, verschwindet der Wert ins Nirvana.

Spezialfall Suchkriterien: Felder müssen in der onOffice-Administration explizit als Suchkriterien-Feld definiert sein, sonst werden sie propform nicht im Suchkriterien-Modul angeboten.

6. Fehlermeldung „onOffice Resource konnte nicht gelesen oder gefunden werden"

Diese typische API-Fehlermeldung erscheint, wenn propform versucht, einen Datensatz aus onOffice zu laden, aber keinen passenden findet.

Häufige Ursachen:

• UUID falsch oder veraltet — der Datensatz wurde in onOffice gelöscht oder die UUID stimmt nicht mehr (z.B. weil ein Datensatz per Migration neu angelegt wurde)
• API-Rechte eingeschränkt — der API-Benutzer darf den Datensatz nicht sehen (siehe Punkte 1–4 oben)
• Modul nicht aktiviert — z.B. das Modul Suchkriterien oder Aufgaben ist im onOffice-Account gar nicht freigeschaltet

Vorgehen zur Eingrenzung:

1. UUID per Hand in der onOffice-Suche eingeben — wird ein Datensatz angezeigt?
2. Wenn ja: Mit dem API-Benutzer einloggen und prüfen, ob er den Datensatz sieht
3. Wenn der API-Benutzer ihn nicht sieht → Rechte-/Gruppen-Problem (siehe oben)

Wenn du die Ursache nicht findest, schick uns eine Mail mit der UUID, dem Formular und der Fehlerzeit — wir schauen uns die Logs gemeinsam an.

7. Formular hat zu viele Felder → onOffice-API liefert NULL

Bei sehr großen Formularen (viele Felder, insbesondere komplexe Custom-Felder) kann es passieren, dass die onOffice-API gar keinen Datensatz mehr zurückgibt — nicht nur ein Feld fehlt, sondern der gesamte API-Call liefert NULL.

Symptome:

• Formular lädt einen Datensatz scheinbar gar nicht (alle Felder leer, auch die, die definitiv Daten haben)
• Das Verhalten verschwindet, wenn man bestimmte Felder aus dem Formular nimmt

Hintergrund: Das ist ein Limit auf Seiten von onOffice/MariaDB — bei zu vielen oder zu komplexen Feldern (insb. lange Texte, viele Multi-Select-Felder) reißt die API-Antwort. propform-seitig nicht behebbar — wir haben das mit onOffice mehrfach besprochen.

Workaround:

1. Formular schrittweise verkleinern, bis der Datensatz wieder geladen wird
2. Das verursachende Feld identifizieren und ggf. in ein separates Folge-Formular auslagern
3. Bei Custom-Feldern mit langen Texten prüfen, ob der Inhalt zwingend mit gelesen werden muss

8. Marketplace-Benutzer ohne API-Rechte-Konfiguration

Wenn du propform.io über den onOffice-Marketplace freigeschaltet hast, läuft propform mit einem speziellen Marketplace-Token, nicht mit einem klassischen API-Benutzer. Hier kannst du die Rechte normalerweise nicht selbst feinjustieren — sie sind durch die Marketplace-Konfiguration vorgegeben.

Wenn du sehr feingranulare Rechtekontrolle brauchst, wechsle auf einen klassischen API-Benutzer mit eigenem Token & Secret. Anleitung: API-Benutzer anlegen.

9. API-Benutzer „Nur auf der Internetseite veröffentlichte Immobilien"-Falle

Im API-Benutzer-Rechte-Reiter unter Immobilien gibt es das spezielle Häkchen „Kann nur Objekte lesen, die auf der Internetseite veröffentlicht sind".

⚠️ Diese Einstellung überschreibt das generelle „Immobilien lesen → alle"-Recht. Auch wenn du oben „alle" gewählt hast, sieht der API-Benutzer mit aktiver Einschränkung nur die Objekte, die auf einer Internetseite aktiviert sind — alle anderen sind unsichtbar, als gäbe es sie nicht.

Symptome:

• Bestimmte Immobilien werden in propform-Formularen nicht gefunden, obwohl die UUID korrekt ist
• PDF-Exposé-Generierung schlägt silent fehl (API gibt NULL zurück)
• Workflows funktionieren nur für „aktive" Immobilien, nicht für interne / archivierte / unveröffentlichte

Lösung: Häkchen deaktivieren, wenn propform für alle Immobilien arbeiten können soll (auch interne Bewertungs-/Akquise-Objekte).

10. PDF wurde erstellt, aber im Datensatz-Reiter „Dateien" nicht sichtbar

Nach Submit wird die PDF asynchron im Hintergrund erstellt — typische Verzögerung 10-30 Sekunden. Wenn die PDF dann immer noch nicht im Reiter „Dateien" der Adresse oder Immobilie auftaucht:

Häufige Ursache: Datei-Filter im Reiter „Dateien" ist aktiv.

In der onOffice-Maske ist im Reiter „Dateien" oft ein Standard-Filter voreingestellt (z.B. „nur Bilder", „nur Energieausweise", „nur eigener Reiter"). Die frisch erstellte PDF entspricht möglicherweise nicht den Filterkriterien und wird ausgeblendet, obwohl sie da ist.

Lösung:

• Im Reiter „Dateien" oben den Filter auf „Alle Dateien" zurücksetzen
• Oder den Filter bewusst auf das Dokumentenmerkmal der propform-PDF stellen

💡 Wenn die PDF auch nach Filter-Reset nicht da ist: erst noch ein paar Sekunden warten, dann F5 drücken. Bei wiederholtem Fehlen → API-Rechte (Punkt 1) und Datensatzrechte (Punkt 3) prüfen.

Wenn nichts hilft

Schreib uns eine Mail an hello@propform.io mit:

• der Formular-URL,
• Datum & Uhrzeit der fehlgeschlagenen Absendung,
• einer kurzen Beschreibung, was passiert ist und was nicht.

Wir schauen uns dann gemeinsam mit dir die Logs an.