Field Types and Field Properties
Fields can be one of several types, such as a number field or formula field. And, each field type has a set of standard properties. Read this topic to learn about field types and common field properties.
This topic explains:
-
The types of fields that you can create
-
How fields work with other components
-
The common set of field properties that you can specify for a field
Most properties are common across all types of fields, although some are specific to the type of field you're creating. For example, all field types have a display label, but only some field types can be indexed for search.
-
How to index fields for faster searches
-
Modifying standard fields
Field Types
Application Composer provides a set of standard field types that you can choose from when creating a new field for an object.
The types of fields that you can create are:
-
Check box
Select to indicate a true or false attribute of a record.
-
Currency
Enter a currency amount.
-
Date
Enter a date, or select one from a calendar.
-
Datetime
Enter a date, or select a date from a calendar, and enter a time of day. During field creation, you choose whether to show the date or time.
-
Dynamic choice list
Select from a list of values populated from another object's set of records.
-
Fixed choice list
Select from a list of static values populated from an FND lookup type.
-
Formula
Calculated in the runtime application using the Groovy-based expression included in the formula field's definition. This is a read-only field that users in the runtime application don't update. However, the application logic that you write can update these fields directly.
-
Long text
Enter a combination of letters, numbers, or symbols. This field type supports 32,000 characters.
-
Number
Enter a number in this field.
-
Percentage
Enter a percentage. The percent sign is automatically added.
-
Record Type
Select from a list of static values populated from an FND lookup type. You can associate each choice list value with a role or a page layout.
-
Text
Enter a combination of letters, numbers, or symbols. This field type is limited to 1500 characters.
How Fields Work with Other Components
When you create new fields for objects, Application Composer limits you to a set of standard field types. The field types that you can select from are already integrated with other components of the Extensibility Framework to provide you with the maximum flexibility when extending your implementation:
-
All field types correspond to API data types. Each field type has an API name, such as customfield_c.
When writing a server script using the expression builder, use this _c field name to reference fields.
-
All field types correspond to your web service XSD payload.
-
All field types correspond to your import ODI mappings when using Application Composer's import and export feature.
-
Most field types correspond to available fields that you can use to create a custom subject area for reporting. Exceptions include long text and formula fields.
Common Properties for Custom Fields
When you create a custom field, you first select the field type. You can't change the field type after the field is created. The specified field type controls which field properties you must define when creating the field. Some properties are common across field types, while other properties are unique to a specific field type.
The common field properties that you can define for a custom field are listed in this table, along with the regions on the field configuration pages where they appear and a list of the applicable field types that you must set these properties for. Use this table to understand the common properties that you must define when creating a new field.
Field Property |
Description |
Field Property Region |
Related Field Types |
---|---|---|---|
Label |
Specify the display label for the field. You should limit the label to a maximum length of 80 characters, although no maximum length is enforced. |
Appearance These properties control how the field appears to your users in the runtime application. |
Set this property for all field types. |
Help Text |
Displays when users hover over the field in the runtime application. You should limit the label to a maximum length of 80 characters, although no maximum length is enforced. |
Appearance |
Set this property for all field types. |
Display Width |
Do not use. A field's display width is dynamically calculated based on the field type and resolution. |
Appearance |
Do not use. |
Name |
A unique field name for internal use only. The field name is automatically populated based on the field label you enter, but without spaces. Field names can contain only underscores and alphanumeric characters. They must:
You can't change this property after the field is created. Tip:
It is possible to create custom fields with different names, but the same display label. Avoid this scenario, however, to avoid seeing two fields with the same display label when configuring a user interface page. The API name, used in your Groovy scripts, is also automatically generated for a field by taking the logical name and appending _c. Don't use special characters in the API name. Also, the API name must be in English. Otherwise you won't be able to add the field to any page. |
Name |
Set this property for all field types. |
Description |
A unique field description for internal use only. |
Name |
Set this property for all field types. |
Required |
Indicate if the field is required. You can also optionally use the expression builder to write an expression that specifies the conditions that must apply for this field to be required. If you write an expression to control whether a field is required, then you must also configure the Depends On choice list. This choice list includes fields from the current object, and is used in the evaluation of your expression at runtime. Default values aren't necessary for required fields. However, you must expose all required fields on the object's creation and details (update and edit) pages wherever those pages appear (such as in the application, mobile, or Outlook UI). Required fields without any default values are automatically added to an object's creation pages. However, required fields with default values must be added manually to creation pages. Also, required fields aren't automatically added to details pages; you must add them manually. This lets your users populate the fields at runtime. The object's web services also reflect the required fields when your sandbox is published to the mainline metadata. |
Constraints Specify constraints, which let you control the runtime behavior of the field. |
Set this property for all field types except for formula fields. |
Updatable |
Indicate if the field is updatable. You can also optionally use the expression builder to write an expression that specifies the conditions required for this field to be updatable. If you write an expression to control whether a field is updatable, then you must also configure the Depends On choice list. This choice list includes fields from the current object, and is used in the evaluation of your expression at runtime. Here are a few things to note about the updatable property:
|
Constraints |
Set this property for all field types except for formula fields. |
Searchable |
Indicate if you want this field to be made available for selection as an additional search criterion from the Add Fields choice list in the Advanced Search mode. |
Constraints |
Set this property for all field types except for long text and formula fields. |
Indexed |
Index the field to speed up the performance of saved searches in the different object work areas. The global search isn't affected. Use this option only on the most frequently searched custom fields to ensure optimal search performance. See Indexing Fields. |
Constraints |
Set this property for the following field types, either during creation or when editing them:
You can't index these field types at all:
|
Include in Service Payload |
Specify whether the field value can be included in a web service request or response. |
Constraints |
Set this property for all field types. |
Fixed Value |
Specify a literal default value for the field. Don't assign a literal default value to fields that are both required and intended to be unique, as a runtime error can occur. |
Default Value |
Set this property for all field types except for formula fields and dynamic choice lists. |
Expression |
Use the expression builder to write an expression that dynamically sets the default value for a field at runtime. |
Default Value |
Set this property for all field types except:
For these field types, write server scripts. |
Modifying Standard Fields
You can modify the properties of some standard fields, as well. The properties that you can modify are listed in this table.
Field Property |
Description |
Field Property Region |
---|---|---|
Required |
Indicate if the field is required. You can also optionally use the expression builder to write an expression that specifies the conditions that must apply for this field to be required. If a standard field is already set to required by Oracle, however, then you can't change the field to be not required. If you write an expression to control whether a field is required, then you must also configure the Depends On choice list. This choice list includes fields from the current object, and is used in the evaluation of your expression at runtime. Default values aren't necessary for required fields. However, you must expose all required fields on the object's creation and details (update and edit) pages wherever those pages appear (such as on the desktop, application, mobile, or Outlook UI). Required fields without any default values are automatically added to an object's creation pages. However, required fields with default values must be added manually to creation pages. Also, required fields aren't automatically added to details pages; you must add them manually. This lets your users populate the fields at runtime. The object's web services also reflect the required fields when your sandbox is published to the mainline metadata. |
Constraints |
Updatable |
Indicate if the field is updatable. You can also optionally use the expression builder to write an expression that specifies the conditions required for this field to be updatable. If you write an expression to control whether a field is updatable, then you must also configure the Depends On choice list. This choice list includes fields from the current object, and is used in the evaluation of your expression at runtime. Here are a few things to note about the updatable property:
|
Constraints |
Number of Field Types per Object
An object can have a total of 625 fields. The following table describes how this number is distributed among the various field types:
Number of Fields |
Reserved for... |
---|---|
350 |
|
200 |
|
50 |
|
25 |
Long text fields |
No limit |
Formula Fields Note:
A formula field is a computed attribute, and exists only at runtime. This is a transient type of attribute that doesn't persist in the database as a table column. Hence, no maximum number of formula fields exists for an object. |