Profile documents are special in several ways:

• They do not appear in views and are only accessible through formulas and scripts as mentioned above.
• They replicate even if there's a replication selection formula that doesn't select them.
• They are cached in the memory of the client for best performance. Users do not see change until they exit and reopen the client.
• Web servers also cache them, and may cache multiple copies for multiple server threads. It may take awhile for a Web application to reflect a change to a profile document.

You specify a profile document with one or two values: a name and an optional key. If a key is not specified, the profile is per-system, that is, shared by all users. The following types of information are often stored in such documents:

• Lists of keyword values, so that they can be updated without having to change the database design.
• Replica IDs or filepaths of other databases that this database needs to locate. This supports the ability to design groups of databases that refer to each other, but whose design is maintained through a set of templates (so that you can easily create a similar group of databases for another department or customer).
• Email addresses to be notified in case of problems.
• Default values for certain fields, including rich text fields (for example, a blank table that will be copied into a rich text field for a user to fill in).

• Personal settings that customize the user's experience, such as a list of teams.
• A list of recently entered values for a particular field, to provide type-ahead assistance to users filling out forms.
• Personal preferences, for example, whether users have clicked a "do not show me this message" checkbox for a particular messsage.

A profile form is a regular form. The term describes how the form is used: to view and edit profile documents.

See Also

Creating a profile form

Glossary