Create Workflow-Related Fields

Some standard fields commonly used within Notes applications and extensively used throughout Domino templates are well suited for workflow applications. Also, these fields are recognized by Notes mail clients if routed to a user's mail file.

Table 11.1 describes the fields in workflow applications and templates.

Table 11.1. Standard Workflow and Template Fields

Field Name	Description
Body	Editable Rich Text field storing the body of the document
ComposedDate	Typically hidden and computed when composed, this is a date/time field containing the time and date the document was created. The formula for this field is typically @Created.
From	Computed when composed, this field contains the document author. The formula for this field is typically @UserName.
Subject	Editable text containing a single line of the document summary.

Conditional/Unconditional Fields

Conditional fields are fields whose values are determined based upon a formula evaluation (condition), whereas unconditional fields have a pre-determined value. When designing workflow applications, both conditional and unconditional fields are used for routing, security, tracking documents.

Workflow applications often require versioning of documents, especially if the document is being routed for mark-up and approval. Adding a reserved field $VersionOpt to a form enables users to create new versions of edited documents on a document-by-document basis. This field is a text field whose value determines which versioning action the application is to take when the document is saved.

Table 11.2 describes the options available for the $VersionOpt field.

Table 11.2. Version Tracking

Value	Description
0	No version tracking.
1	New versions become responses if the user chooses File, Save As New Version.
2	New versions automatically become responses when the document is saved.
3	Prior versions become responses if the user chooses File, Save As New Version.
4	Prior versions automatically become responses when saved.
5	Prior versions become siblings if the user chooses File, Save As New Version.
6	Prior versions automatically become siblings when saved.

FoldersOptions Field

The FoldersOptions field enables users to select a folder in which new documents are to be saved without having to use the Actions, Move to Folder After Saving option. This field enables the designer to prompt the user to choose a folder or automatically save the document to the current folder.

The allowed values for this field are either

• 1— Prompts the user to choose a folder.

• 2— Saves the document to the current folder.

Document Encryption

Many of the features and capabilities used throughout workflow applications (discussed in this and other chapters) display and hide fields, text, and other objects based on user roles, form formulas, view selection formulas, field values, and so forth. Although these features make the application easier to use and streamline the workflow process, they do not provide true document-level security. Users can view documents and data contained within them by using alternate views or personal views, viewing field values in the document properties box, and so forth. However, documents can use encryption to ensure that data contained within fields is secure from unauthorized users.

Encryption is a type of digital lock used to protect data from unauthorized access. You can encrypt databases and/or fields. Although other Domino security features (such as database Access Control Lists, server access, and so forth) are integrated and work in conjunction with one another, encryption does not. You must have the encryption key to access the data. You cannot override or modify the security.

Domino uses two types of encryption for security:

• Public-private key encryption

• Secret key encryption

For more information regarding enabling encryption for specific fields and applying encryption, refer to “Encrypting Documents” in Chapter 10, “Security,” for Exam 611.

Document-level encryption and signatures do not work for Web applications because both methods require keys to be stored in each user's ID. Because Web users do not use ID files, security for the Web is secured by Secure Sockets Layer (SSL). For more information regarding enabling SSL for Web applications, refer to “Set Database Access: Using SSL,” in Chapter 17, “Security,” for Exam 612.

Public Key/Private Key Encryption

Domino assigns a private key and a public key to each user ID. The private key is stored in the ID file. The public key is stored in the ID file and in the corresponding document where the key is publicly available (the Person document in the Domino directory). When data is encrypted, it can be decrypted only by the private key (using complex mathematical algorithms).

Public and private keys can be used to

• Encrypt mail

• Encrypt databases

• Sign documents, fields, and sections

If Jake wants to send encrypted mail to Leah, Jake creates a mail memo and indicates that the mail is to be encrypted. Domino gets Leah's public key from her Person document in the Domino directory and encrypts the memo. When Leah receives and opens the document, Domino uses Leah's private key to decrypt the message.

Secret Key Encryption

Secret keys can be created by any user and must be available to all the users who need to access the encrypted information. Secret encryption keys are often created and distributed by the database manager or the application designer.

Secret encryption keys can be used to

• Encrypt fields

• Provide additional security for documents

To create a secret encryption key for document encryption, follow these steps:

1.	Select File, Security, User Security from the pull-down menu.
2.	Expand the Notes Data section, then click Documents.
3.	Click New Secret Key….
4.	Enter the secret key name (see Figure 11.1). This name should be descriptive of the key purpose. Figure 11.1. Creating a secret encryption key. [View full size image]
5.	If the key is to be used by users who are using an international version of Notes older than release 5.0.4, select Use International Encryption.
6.	Enter comments if necessary.
7.	Click OK.
8.	Click OK to close the User Security dialog box.

After you have created the secret encryption keys, you need to distribute the key to the authorized users. After it has been distributed, they can read the encrypted information.

To send the encryption keys via email, perform the following steps:

1.	Select File, Security, User Security from the pull-down menu.
2.	Expand the Notes Data section, then click Documents.
3.	Select the appropriate key to distribute from the Document Encryption selection box (see Figure 11.2). Figure 11.2. Select a secret encryption key. [View full size image]
4.	Click Mail Secret Key….
5.	Enter the recipient information (To: and CC: fields) and modify the subject if appropriate.
6.	Click Send.
7.	You will be prompted to select the Allow All Recipients to Forward the Key to Others by Mail or Export? check box. Select the appropriate action.
8.	Click OK.

To export a secret encryption key, perform the following steps:

1.	Select File, Security, User Security from the pull-down menu.
2.	Expand the Notes Data section, then click Documents.
3.	Select the appropriate key to distribute from the Document Encryption selection box (see Figure 11.2).
4.	Click Other Actions, Export Secret Key…. You also have options to Delete Secret Keys, Import Secret Keys, and view Advanced Details as well.
5.	Enter the password for the export file and re-enter the password confirmation, or select No Password (see Figure 11.3). Figure 11.3. Exporting a secret encryption key.
6.	Click Restrict Use to select the name of the person who is allowed to use the encryption key import file. The name is entered in the Secret Encryption Key Restrictions dialog (see Figure 11.4). Figure 11.4. Setting encryption key restrictions.
7.	Click OK.

After the secret encryption keys have been distributed, users need to merge the key with their ID files (users can use the secret encryption keys only after they have been merged with their ID files). The keys are merged from either an email message or a previously exported encryption file.

To merge an encryption key received via email, perform the following steps:

1.	Open the mail message containing the attached encryption key.
2.	Select Actions, Accept Encryption Key from the pull-down menu.
3.	Enter the user password.
4.	Click OK.
5.	Enter any comments regarding the key, if required.
6.	Click Accept.

To import a secret encryption key, perform the following steps:

1.	Select File, Security, User Security from the pull-down menu.
2.	Expand the Notes Data section, then click Documents.
3.	Click Other Actions, Import Secret Key….
4.	Select the encryption key file from the file system.
5.	Enter the password (if required).
6.	Click Accept.

Hide-When Fields

A common way to filter the information displayed to the users is to selectively hide and display fields on the form, dependant on the status of the document in the workflow process. Hide-when properties of fields (and text and other objects) can be used to control the display of information.

Hide-when formulas always evaluate to either TRUE or FALSE. Hide-when attributes apply to the entire line. Therefore, if you have multiple fields on the same line, they share the same hide-when formula. To avoid this, you can place the fields on separate lines or in separate cells in a table. Therefore, each can retain its own hide-when attribute (see Figure 11.5).

Hide-when formulas can contain only formula language evaluations. If it is required that more complex expressions be used to determine the value of a hide-when formula, you can program script to populate another field on the form and then have the value of the hide-when formula evaluate to the prior field name. The formula expressions for hide-when formulas can be simple (such as @IsNewDoc) or more complex algorithms that contain multiple @If statements. Regardless, they must always evaluate to either a TRUE (1) or FALSE (0) condition. Be careful not to create an excessive number of hide-when formulas or formulas that are extremely complex. This can negatively impact application performance.

Keyword Fields

Keyword fields are computed or editable (which are more common) fields that present the user with a list of choices. The list can be predetermined by the application designer, generated by formula, or entered manually by the users of the application. The designer determines whether only one selection can be made, multiple selections can be made, or the user can add selections not currently in the list.

Table 11.3 describes the different keyword field types, how they are used, whether the option is set to allow multiple values, and whether the option to allow values not in the list is available.

Table 11.3. Keyword Field Types

Field Type	Description	Allow Multi-Values	Allow Values Not in List
Dialog List	To view the dialog box, press Enter or the Entry Helper button. You can also type the first letter of a choice to jump to an entry, or press the space bar tocycle through the list of items.	Available	Available
Checkbox	Display all the items with check boxes.	Available	Not Available
Radio Button	Display all the items with radio buttons.	Not Available	Not Available
ListBox	Each choice is displayed with an expanded list box.	Available	Not Available
ComboBox	Each choice is displayed with a drop-down list box.	Not Available	Available

When creating keyword fields, the application designer must select how the available choices will be determined. These options are available on the Control tab of the Field properties box (see Figure 11.6).

Table 11.4 describes the options available for determining the keyword choices.

Table 11.4. Keyword Options

Option	Description
Enter choices (one per line)	The Designer enters the choices in the Edit box (letters, numbers, and any punctuation, except for commas). Select Sort to sort the list in alphanumeric order.
Use Formula for choices	Enter a formula to generate the list of choices.
Use Address dialog for choices	Displays the Name dialog box to select names from the Domino directory.
Use Access Control list for choices	Displays the list of people, servers, groups, and roles in the ACL of the current database.
Use View dialog for choices	Displays a dialog box displaying entries from a column in an existing view.

Here are some benefits of using the View dialog for choices:

• Non-designers can maintain the choices without affecting the database design.

• You avoid hard-coding the keyword options.

• The database design can be hidden and restricted without affecting future maintenance.

• It is easier to upgrade the application to multi-lingual capabilities.

• Keyword choices are more easily modified outside the current form or database.

Reserved Word Fields

Several reserved word fields are intended to provide an easy mechanism for incorporating some of the more common features of Domino. Using these reserved field names enables developers to easily add functionality rather than program it from scratch. Developers need only use the reserved word names and appropriate values to create fields, and Domino automatically enables the respective functionalities.

SendTo Reserved Field

The SendTo field is a reserved field that contains value(s) of the intended mail recipient(s) of the Notes document. This field can contain individual usernames, groups, or databases. Each is defined in the Domino directory. The value of this field can be either computed or editable. While you are designing the document and placing this field on the form, consider the placement of the field and how its value is computed. The field type can be Text, Keyword, or Names, and can contain a text string or text list. The value of the field can be

• Hard-coded with the recipient list.

• Computed with the recipient list based upon another field value located on the form (above or to the left of the current field).

• Computed with the recipient list based upon a formula or condition.

MailOptions Reserved Field

The MailOptions field can be used to

• Programmatically force a document to be routed when the user closes the document, independent of user intervention.

• Prompt the user to send the document when the document is closed.

The MailOptions field should be a computed text field with a value of 1 to automatically route the document, or 0 to prevent the document from routing.

Form Reserved Field

The Form field is a reserved field that contains the name of the form to be used to display the document if the form design is not stored in the document. If the form design is not stored in the document opened for reading or editing, Domino uses the value contained in the “Form” item in the document. Domino automatically creates a Form item when a document is created and saved. The default Form item name is the name (or alias) of the form design element used to create the document. However, this form value can be later modified by using the formula language or script, or by opening with another form (using and alias).

Signing

Signing a document causes Domino to combine the user's private key and the value of the signed field to create a unique electronic signature. Therefore, if the document or mail message is altered in transit, the unique signature changes. The user is then notified that the document cannot be authenticated. Creating signatures does not secure the data. It only establishes that the user who saved the document last is authentic and informs the user whether this is the case. In addition, signing works only for Notes clients and is not supported on the Web.

Electronic signatures provide the capability to verify that particular messages and documents have been modified by particular individuals. With Domino, electronic signatures ensure that the ID of the user that created or modified the specified document is genuine and that the document, and information contained within it, have not been modified since the user saved and/or mailed the document. Signing documents is important with sensitive information.

Because the signature is applied when the document is saved or mailed, the following occurs:

• If the document was signed, Domino checks the signature against the data to ensure that the data matches.

• If the signature and data match and are verified, Domino displays a message to the user identifying who signed the document.

• If the signature and data do not match (the data has been modified), Domino displays a message indicating that the document has been changed or corrupted since the document was last saved or mailed.

To enable documents to be signed, at least one field on the document must have the Sign If Mailed or Saved in Section property enabled in the Field properties dialog box (see Figure 11.7). In addition, the form must also be mail-enabled, containing the SendTo field or an access-controlled section.

If the field is located within an access-controlled section, the signature is contained within the section and generated when the document is saved.

To sign-enable an access-controlled section, one of the fields must be sign-enabled. When the document is saved, the section is signed.

You can create multiple sign-enabled sections on the document by creating multiple sign-enabled fields placed in each access-controlled section.

If the field is not located within an access-controlled section, the signature is contained within the document and generated when the document is mailed.

The signing occurs when the document is mailed as a result of one of the following:

• The sender chooses the Sign option in the Send Mail dialog box.

• The form design contains a field named Sign that has a value of 1.

• The form has a @MailSend function that uses the [Sign] flag.

• The form has LotusScript code that has the SignOnSend property set to TRUE.

Workflow-Related Field Attributes

Building from the native workflow capabilities of Domino, many of the field types and attributes allow for easy implementation of workflow-specific features. Simply selecting certain field types or certain parameters on fields can enable powerful workflow and security features.

In addition to enabling signing and encryption and creating keyword fields, some other workflow-related field attributes are described in Table 11.5.

Table 11.5. Workflow-Related Field Options

Option	Description
Names fields	Display and store usernames the way they appear in the user's ID.
Authors and Readers fields	Control who can read and edit documents.
Password fields	Text fields that display each character entered as an asterisk on the screen.
Field inheritance	A field can inherit its value from another document in the same database or another field in the same form. This is particularly helpful with workflow documents in which much of the information is shared among different documents.
Automatically refresh fields	The document refreshes when a different choice is selected.
Automatically refresh choices	If the options are based on a formula, they are recomputed if the document is refreshed.
Security Options	Several workflow options are available to further refine security with in the document. The options available are None Sign if mailed or saved in section Enable encryption for this field Must have at least editor access to use