Maintaining a Notes or Domino application begins with matching the question to the right product, version and execution context. Use this directory to find official documentation, distinguish an application problem from a server problem, and collect enough evidence for a reproducible troubleshooting report.
Write down which system you are maintaining
A familiar database title can hide several different environments. Record the Notes client version and fix pack, Domino server version and operating system, Designer version, database path and whether the problem occurs in a local replica, on a server or through a browser. Include the template or application design version if the team tracks it. These details determine which documentation and reproduction steps are useful.
Start at the HCL Domino documentation portal. It separates Domino administration, Domino Designer, REST API and C API resources. At the October 2026 review, its administration and Designer links opened 14.5.1 documentation. The versioned links below make the reference used here explicit; select documentation matching your installed release before applying a procedure. Documentation availability and a supported production configuration are separate checks.
State the task as an observable result: “A scheduled server agent should update one status field” is more useful than “LotusScript is broken.” Record who runs it and where. A form button in a Notes client, a scheduled agent and an HTTP request can exercise different code paths and identities.
Choose documentation by the task
| Task | Reference | Bring these details |
|---|---|---|
| Configure or administer a server | Domino 14.5.1 administration | Server release, OS, topology and affected service |
| Maintain forms, views or application code | Designer 14.5.1 documentation | Design element, language, event and execution location |
| Understand a formula or script | Formula language and LotusScript language | Exact function or class, inputs, expected type and error |
| Investigate database access | Database access control list | Test identity, relevant groups/roles and the attempted operation |
| Narrow an unexplained failure | HCL's troubleshooting approach | Reproduction steps, timing, scope and recent changes |
The ACL reference distinguishes access granted to users from access granted to servers for replication. That distinction makes “the user can open the database” only one part of a replication investigation. Have the responsible administrator inspect the relevant identities and rules; broadening access to make an error disappear can conceal the actual problem.
For a REST integration, use the REST API route in the portal and establish its installed version and configuration separately. For C API code, start with its own toolkit reference. A similarly named operation in another API can have different arguments or behavior.
Worked example: a document save behaves differently
HCL's current-document reference distinguishes the on-screen NotesUIDocument from the back-end NotesDocument. It specifically warns against calling NotesDocument.Save on the document obtained from a NotesUIDocument, because a later front-end save can produce a conflict. That is a concrete hypothesis for this example, to be checked against the actual code.
The separate NotesDocument.Save examples illustrate checking the Boolean result and different conflict choices. A call that forces a save changes conflict handling; it is a consequential design decision. Document whose edits should survive before selecting it.
- Capture the exact failing event and document-access path.
- Open the installed-version reference for that class and method.
- Reduce the issue to one test document and one intended change.
- Check the saved value, method result and any subsequent UI save.
- Record the observed cause and test the correction through the original workflow.
This exercise demonstrates a documentation route. It supplies no diagnosis for an uninspected application, and the article's examples have not been executed in your Domino environment.
Make the next investigation reproducible
Use the Domino troubleshooting record to capture versions, environment, steps, expected and actual results, timing and the exact references consulted. HCL's troubleshooting guidance examines symptoms, location, timing, conditions and reproducibility; a report that separates observations from hypotheses is easier for another maintainer to follow.
Keep diagnostic attachments in an approved private location. Remove passwords, identity files, tokens and unrelated document contents from material shared outside the team. Include a minimal reproducible sample where practical, plus the test identity's relevant access context rather than a production credential.
Confirm the repair with the affected user or representative test identity, then record what changed and how to reverse it. For an intermittent failure, state how many repetitions passed and under which conditions. That makes the scope of the evidence clear.
Keep historical references useful
Lotus and IBM-era articles can explain why a long-lived design works as it does. Label each retained reference with its product release, date and purpose. Use it to understand the design, then verify consequential instructions against applicable documentation and a test environment. Replace abandoned links with an authoritative current equivalent only when it answers the same question.
Maintain a small resource list with an owner, the supported task and the last successful check. Remove redundant starting points so the next maintainer can choose quickly. For web-facing applications, pair the technical investigation with a test of the visitor's actual task.