From the Create Field dialog box, select Date, Floating Point, Integer, Logical, or Short Text from the Data Type list. The relevant data type settings display.

Select the Computation Values option.

In the Computation Definition field, create a computed expression using the rules described in Computed Expression Rules.

For example:

• To determine how many days a Defect item has not been worked on, create a date field called Days Inactive and type the following expression:

  now() - "Modified Date"

  The Days Inactive field displays the number of days elapsed since the last edit of the Defect item.

• If a Project item type contains Actual Cost and Expected Cost fields, and you want to determine if and how much the actual cost of a project exceeds the expected cost, create an integer or floating point field called Cost Overrun and type the following expression:

  "Actual Cost" - "Expected Cost"

  If the value of the Actual Cost field exceeds the value of the Expected Cost field, the Cost Overrun field appears after editing the item, displaying how much the actual cost overran the expected cost.

• To determine whether the actual cost of a project exceeded 90 percent of what you budgeted for, type the following expression:

  "Actual Cost" > .90 * "Expected Cost"

  If the value of the Actual Cost field exceeds the value of the Expected Cost field by 90 percent, the Cost Overrun field appears after editing the item, displaying the percentage that the actual cost overran the expected cost.

  As project manager, you could closely monitor project budgets by creating a query or e-mail notification that identifies Project items where the cost has exceeded 90 percent of the estimated budget.

To record the computation value at the time of versioning and prevent further updates, disable the Allow Computation Updates on Versioned Items option. By default, computation values on versioned items continue to update based on the computed field definition.

To identify computed fields that continue to update based on the computed field definition, these are known as live fields, indicated by the live field icon () in versioned items.

When working with versioned items through a computed expression, there can be situations where cannot determine the value of the field. To indicate an unknown (or ambiguous) computed field value in a versioned item, displays an ambiguous computation icon ( ).

To indicate how often the computed field should be calculated and stored in the item’s history, select a frequency from the Store to History Frequency list. Selecting a frequency is useful for historical charting. never is the default.

To specify a custom frequency, select never from the list, and create an event trigger that specifies the desired frequency. For more information on configuring the frequency at which the field computes, see Scheduling Computation Times.

If document versioning is enabled and the computed field is configured to store to history, note the following when viewing the item history in a versioned item:

• If a computed value has always been valid, the item history records the valid value.

• If a computed value has always been ambiguous, the item history records the ambiguous computation icon ().

• If a computed value was previously valid and is currently ambiguous, the item history records the valid value.

From the How to Run Computations list, select one of the following computation types:

• static calculates the field based on a schedule and stores it in the item’s history based on the value selected in the Store to History Frequency list. Columns for static fields are stored in the item’s row of the database. You should select static if your expression involves intensive external functions, such as query or aggregate functions. For more information on calculating a static computed field, see Calculating Static Computed Fields.

• dynamic calculates the field every time field values are retrieved. By default, columns for dynamic fields are not stored in the item’s row of the database; however, you can select dynamic and a frequency from the Store to History Frequency list. dynamic is the default.

  • Because dynamically computed fields are not stored in the database, dynamically computed short text fields cannot be located with an all text field search in the . To search for dynamically computed short text fields, create a query that includes a specific “field contains” comparison. If the query does not include additional filters, the query may not return optimal results.

  • To avoid performance issues when working with queries, do not use dynamic computed fields in query definitions. As a workaround you could create a rule based event trigger that fires when a relationship field changes, storing the count in a regular integer field.

  • To avoid performance issues when working with large documents, ensure that any computed fields in Requirements are static, not dynamic.

Fill out the remaining fields and tabbed panels.

Click OK to save your changes.