Um die Konfiguration einer Notes-Anwendung zu speichern, gibt es zwei offensichtliche Möglichkeiten und eine dritte, nicht ganz so offensichtliche, die die Vorteile der anderen beiden Alternativen in sich vereint, in zwei Varianten:

Erste Alternative: Profil-Dokumente
Für diese Methode erstellt man ein oder mehrere Masken, aber keine Ansichten. Die Konfigurationsdokumente erstellt man dann nicht mit @Compose, sondern mittels @EditProfileDocument. Für den Zugriff auf die gespeicherten Werte benutzt man dann @GetProfileField oder NotesDatabase.GetProfileDocument. Der Hauptvorteil ist Geschwindigkeit: Man kann sehr effizient auf Profil-Dokumente zugreifen und sie werden im Speicher des Notes-Clients gecacht. Das ist aber auch schon gleich ein Nachteil: Wenn ein Profil-Dokument durch einen anderen Benutzer geändert wird, erhält man solange noch die alten Werte, bis man die Notes-Anwendung geschlossen und wieder neu geöffnet hat. Ein anderer Nachteil ist die Zuverlässigkeit: Es passiert hin und wieder mal (nur in alten Notes-Versionen?), dass das Profil-Dokument plötzlich komplett leer ist. Das kann zum Beispiel passieren, wenn es Repliken gibt, in denen das Profil-Dokument - aus welchen Gründen auch immer - nicht existiert. Beim (lesenden !) Zugriff darauf wird dann ein neues erstellt. Und da es neuer ist, wird es bei der nächsten Replikation auch auf andere Repliken verteilt.

Zweite Alternative: normale Dokumente und Ansicht
Hier erstellt man eine oder mehrere Masken und mindestens eine Ansicht. Die Konfigurationsdokumente werden mittels @Compose oder über Ansicht - Erstellen erzeugt. Um auf die gespeicherten Werte zuzugreifen, benutzt man @DbColumn und @DbLookup bzw, NotesView.GetDocumentByKey und NotesView.GetAllDocumentsByKey. Vorteile: Die Dokumente sind "sichtbarer", Änderungen wirken sich sofort aus (außer bei Verwendung von [Cache] bei den @-Formeln) und die Lösung ist zuverlässiger. Diese Vorteile erkauft man sich aber mit einer deutlich schlechteren Performance, da das Suchen des Konfigurationsdokuments in der Ansicht wesentlich länger dauert.

Dritte Alternative: Kombination
Hier versucht man die Vorteile beider Methoden zu kombinieren. Dazu gibt es zwei verschiedene Ansätze:

Variante 1: Doppelte Datenspeicherung
Wie bei der zweiten Alternative erstellt man Masken und Ansichten und erstellt normale Dokumente, um die Konfiguration zuverlässig zu speichern. Aber zusätzlich erstellt man beim Speichern eines Konfigurationsdokuments (z. B. im PostSave-Ereignis) ein Profil-Dokument bzw. aktualisiert es. Zum Zugriff auf die Daten benutzt man dann das Profil-Dokument, also @GetProfileField und NotesDatabase.GetProfileDocument. Wenn das Profil-Dokument mal verloren geht, muss man nur das normale Dokument noch einmal speichern, und das Profil-Dokument wird automatisch wieder mit den richtigen Werten neu erstellt. Es bleibt allerdings der Nachteil durch das Cache des Profil-Dokuments.

Variante 2: "Zeiger" auf normales Dokument cachen
Auch hier gibt es wieder Masken, Ansichten und normale Dokumente für die zuverlässige Speicherung der Konfiguration. Im Unterschied zur vorigen Variante speichert man jetzt beim Speichern eines Konfigurationsdokuments aber nicht das ganze Dokument noch einmal als Profil-Dokument, sondern lediglich die UNID (@DocumentUniqueID bzw, NotesDocument.UniversalID) in einem Profil-Dokument. Um auf gespeicherte Werte zuzugreifen, holt man sich mit @GetProfileField oder NotesDatabase.GetProfileDocument erst einmal die UNID des richtigen Dokuments und dann mit @GetDocField bzw. NotesDatabase.GetDocumentByUNID den Wert bzw. das Konfigurationsdokument selbst.

Diese Variante ist fast so schnell wie die erste Alternative, da kein Suchen in einer Ansicht notwendig ist, aber die Werte werden sicher und zuverlässig in normalen Dokumenten gespeichert. Außerdem wirken sich Änderungen an Konfigurationsdokumenten sofort aus, da nur deren UNID, nicht aber die Werte selbst gecacht werden.

Geht das Profil-Dokument mit der UNID einmal verloren, kann man im Code, der versucht darauf zuzugreifen, ein Fallback einbauen: das normale Dokument in der Ansicht suchen und natürlich seine UNID wieder ins Profil-Dokument eintragen (für das nächste Mal). Das kann dann sogar vollautomatisch passieren und erfordert nicht wie bei der ersten Variante einen manuellen Eingriff eines entsprechend berechtigten Benutzers.