Save (NotesDocument - LotusScript®)

Saves any changes you have made to a document.

Defined in



flag = notesDocument .Save( force , createResponse [, markRead ] )



Boolean. If True, the document is saved even if someone else edits and saves the document while the script is running. The last version of the document that was saved wins; the earlier version is discarded.

If False, and someone else edits the document while the script is running, the createResponse argument determines what happens.


Boolean. If True, the current document becomes a response to the original document (this is what the replicator does when there's a replication conflict). If False, the save is canceled. If the force parameter is True, the createResponse parameter has no effect.


Boolean. If True, the document is marked as read on behalf of the current user ID. If False (default), the document is not marked as read.

Note: If the database does not track unread marks, all documents are considered read, and this parameter has no effect.

Return value

  • True indicates that the document was successfully saved
  • False indicates that the document was not saved


Avoid using this method in a document returned by NotesUIDocument.Document. Use NotesUIDocument.Save instead. Otherwise, a user who saves in the front-end creates a save conflict.

When you use a NotesDocument, you access the "items" of the note directly, without using any form. Any computed field formulas, input translations, or validations, will not occur when you call the Save method. If you need a field to have a particular value, your code must assign that field. Or, use ComputeWithForm method to recalculate formulas.

The Send method does not automatically convert your document into a regular memo. It is possible to Send documents that contain none of the usual fields that you would expect to find in an email message, such as Subject and Body. You can design custom forms with many fields on them, and mail documents created using those forms to another mail user or to a mail-in database, where the field information remains in its original fields. However, to make use of these documents as you intended, the receiving user or database must have a form with the same name (or alias) and the same fields.

Using the "store form" option, you can have the form accompany the message, so that the recipient does not require a copy of the form in their mail file design. However, doing so is generally not a good idea, because:

These messages are substantially larger than regular emails.

The regular email action buttons will not be available unless you add them.

The Swiftfile header will not be displayed.

It will not work for internet recipients, since the stored form information cannot be represented in MIME.

If the recipient needs to fill in or otherwise edit the document, it is usually better to email a doclink to the original document, or a button containing a "Compose" command into the target database. If the recipient just needs to read the document, you could Forward the document to the recipient - this gives you a regular memo with Subject and Body fields.

See Also