| Print Open PDF Version of Online Help

#### About Field Management In Oracle CRM On Demand you can perform the following field management tasks for the different record types: Creating and Editing Fields Managing Field Labels Changing Picklist Values When you create custom fields or edit field definitions, you can specify default values for the field that take effect when new records are created. You can also specify that field validation is performed for the field to ensure that it has a particular value. ### About Copying Fields Most record types in Oracle CRM On Demand have a copy function; that is, users can copy the current record they are using. When a user clicks the Copy button on the Record Detail page, it opens a new record page. This new Record Page contains all the fields that can be copied. A user can change and save these fields. NOTE: When you use the Copy button, only the base record is copied, but not the related item for child records. The following restrictions apply when using the copy function: Web links, concatenated fields, system fields, address fields, calculated and reference fields cannot be copied. The Copy Enabled check box is unavailable for these items. Read-only fields cannot be copied. Read-only fields are fields that are set as read-only in the field set-up or in fields layout. Fields that are unavailable on a user’s form layout cannot be copied. The following attachment fields cannot be copied: Attachment Attachment: File Name Attachment: Size (In Bytes) You can copy fields by using the Copy button in record detail pages in Oracle CRM On Demand. You can enable this setting by using the Copy Enabled check box in the Field Management page of the Application Customisation section of Oracle CRM On Demand. For more information on specifying which fields can be copied in Oracle CRM On Demand, see Administering the Copy Enabled Setting. ### Required Fields There are various situations where you might define fields as required. For example, your company might require that every service request must track information on the cause of a service request. In this case, you specify that the Cause field for service requests is required. Then, when a record is created or updated and then saved, the application validates that the Cause field is NOT NULL. When you specify a field as Required, the validation is enforced through all interfaces, including the user interface, Web Services, and data import. The fields specified as required in the Field Edit page are required fields for all users, regardless of their role. If you need to make a field required for a specific role only, you can do so by editing the appropriate page layout for fields that are not already required fields. For more information, about editing page layouts, see Customising Static Page Layouts. ### Conditionally Required Fields You can configure a field so that it is conditionally required, that is, the field is not required by default, but it becomes required when a defined condition is met. For more information, see About Conditionally Required Fields. ### Read-Only Fields The following are situations in which you might define fields as read-only: Fields from external sources. If your company tracks, for example, the credit rating of an account in an external system, it is likely that you want the credit rating to be updated regularly through a nightly import, but only want the field to be read-only in the UI. Moving an existing field to a custom indexed field. If you want to use one of the index custom fields for an existing custom field, you can specify that users can have read-only access only to the old field while you move data to the new index field. This field definition avoids data becoming out of sync. NOTE: Certain system fields are always read only and can be updated only by Oracle CRM On Demand. Some examples of fields that are always read only are the Created field and the Created: Date field, both of which are available on many record types. ### Custom Field Validation Rules You can use Oracle On Demand Expression Builder (Expression Builder) to create expressions for custom field validation rules. You can click the fx icon next to the Field Validation field to open the Expression Builder window in which you can enter an expression. For information about the syntax you can use for expressions, see Expression Builder. The following are situations in which you might define custom field validation rules: Enforcing business policy. For example, if your company has a business policy whereby an MDF cannot be effective for more than one year, you can define a validation rule on an End Date field to ensure that the field value is never more than one year from the Start Date. As another example, your company might have a business policy whereby if an opportunity is lost, which had an expected revenue of $100,000 or greater, the reasons for losing it must be tracked. In this case, you set up a validation rule on the Status field so that when a user attempts to save an opportunity record with the Status field set to Lost, Oracle CRM On Demand determines whether the expected revenue is $100,000 or greater, and whether the Reason Won/Lost field is blank. You can also set up the message that is to display when the validation fails. In this case, the message warns the user to select a value in the Reason Won/Lost field before saving the record. NOTE: For the business process where you want the Reason Won/Lost field to be required in certain circumstances only, you can alternatively set up the Reason Won/Lost field as a conditionally required field. For more information, see About Conditionally Required Fields. Enforcing data format. For example, if your company uses a value-added tax (VAT) number on a European account, you can specify that validation of the correct VAT format, based on an account's invoicing address. As another example, you might specify that the value for a specific custom field is no more or no less than four digits long. A validation expression for a field is evaluated each time the field is updated on a new or existing record. However, a validation expression is not evaluated in the following circumstances: The field is left blank when the record is created or modified. Field validation does not force a value to be required. The field has a pre-existing value, either valid or invalid, and the value is not changed when the record is updated. If a validation expression is not evaluated, or if a validation expression evaluates to NULL, no error message is generated. An error message is generated only when the validation expression fails (that is, the expression evaluates to FALSE). Field validation expressions assume that the first parameter is the field name itself. If, for example, you are putting a simple field validation expression on an Amount field to specify that the value must be greater than 1000, it is sufficient to enter >1000. You do not need to enter [<Amount>]>1000. For more information on more complicated expressions, see About Expressions. #### Restrictions on Specifying Field Validation Rules You cannot specify field validation rules for the following types of fields: System fields Internal calculated fields RowID and ID fields NOTE: Remember that Row_ID is an internal system field. Depending on the operation transitions, for example, during record creation, it is not always guaranteed to remain static. It can differ to ExternalSystemID or the IntegrationID. Associated fields Multi-select picklist fields Fields with User Property set to exclude them. These fields are set on an exception basis to prevent breaking the existing business logic in the application code. Web links Concatenated fields The following attachment fields: Attachment Attachment: File Name Attachment: Size (In Bytes) ### About Defining Default Field Values You can specify default values for fields in the Default Value field in the Field Edit page when you create custom fields or edit field definitions. Specifying a default value for a field is useful where you require: A constant value for a field. For example, you might want an Account Type field to have a default value of Customer when a new record is created. A formula-based value as default. For example, you might want the default value for a Due Date field of Fund Requests to take a default value of 6 months after the value of the Create Date field. The generation of a unique value for a field. For example, you might want to specify an expression to generate a unique number as an ID for an Expense Report field. (This field is also read-only.) A role-specific default value. For example, in a company where the majority of the service requests (SR) are created by customer service representatives (CSR), a Reassign flag field might be selected by default so that, if, for example, a sales representative opens the SR, it is routed to the correct CSR based on predefined assignment rules. NOTE: Most of these are only possible if your role includes the Advanced Field Management privilege. There are two types of default values for fields: Pre Default. The field is pre-populated with the specified value when a user creates a new record. Users can overwrite the default value or accept the default value. Post Default. The field is not pre-populated with the specified value when a user creates a new record, but the field takes the specified default value when the record is saved, if: The user leaves the field blank The field is hidden from the layout A value has not been supplied by the integration tools Pre Default is the default type of value for fields. You can specify Post Default by selecting the check box of that name in the Field Edit page. Default field values are applicable to new records only, and not applicable to record updates. If you specify a default value for a field that already has a system-specified default, your value takes precedence for your company. An exception to this rule is the Revenue field on Opportunity records. Any default or post default values you specify for this field are ignored, because the field is used in the generation of forecasts based on opportunity revenue. You cannot set default values for the following types of fields: System fields Internal calculated fields RowID and ID fields NOTE: Remember that Row_ID is an internal system field. Depending on the operation transitions, for example, during record creation, it is not always guaranteed to remain static. It can differ to ExternalSystemID or the IntegrationID. Associated fields Multi-select picklist fields Fields with User Property set to exclude them. These fields are set on an exception basis to prevent breaking the existing business logic in the application code Web links Concatenated fields Check boxes (Post Default values) The following attachment fields: Attachment Attachment: File Name Attachment: Size (In Bytes) The following table shows the default values that you can specify for the different field types in Oracle CRM On Demand.
Field Type | Valid Default Values
--- | ---
Check box | Y if the checkbox should be checked and the Boolean value is true. N if the checkbox should be unchecked and the Boolean value is false. Blank represents an undefined value for a checkbox even though it appears unchecked Note: You cannot select Post Default for a check box field.
Currency | A valid numeric value up to 15 digits.
Date | Today + number, where number represents a specific number of days. The default date is calculated as today's date plus the number entered. For example, if today is 1 January 2008, and you enter Today + 7, the default value is set to 8 January 2008.
Date/Time | As for the Date field type, but in addition the time when the new record is opened is also shown.
Integer | A valid numeric value between -2147483648 and 2147483647.
Multi-select picklist | You cannot define a default value for a multi-select picklist.
Note | A text value up to 16350 characters.
Number | A valid numeric value between -2147483648 and 2147483647.
Percent | A valid numeric value between -2147483648 and 2147483647.
Phone | A valid telephone number.
Picklist | The picklist value selected will be the default value for the field.
Text (Long) | A text value up to 255 characters.
Text (Short) | A text value up to 40 characters for custom fields and most preconfigured fields. However, for some preconfigured fields you can enter more than 40 characters. For example, the Account record type can have a name longer than 40 characters, therefore the length of the value for the Default field is not restricted to 40 characters.
Text (Short-Maskable) | A text value up to 40 characters in which some of the data is hidden from view from some users. For example, if a maskable field contains the value 4558785236, then users see XXXX5236. A user role must include the View Masked Data privilege to see the data in the maskable field. For more information, see About Maskable Fields.
Web link | A valid URL. Expressions and validation is not allowed. A default value can be set through the Web Link edit page. The Display Text field can contain up to 250 characters. The URL field can contain up to 8000 characters. Browsers have different maximum URL lengths. If you specify a URL that is too long, it may not work as intended. The URL length changes if you are using parameter substitution.
NOTE: If you create an expression to set a default value, the result of the expression must not exceed the maximum number of characters allowed in the field. In addition, any string or numeric literal passed to a function in Expression Builder must not exceed 75 characters. For more information about using Expression Builder, see Expression Builder. In addition: For all field types, including picklists, you can enter a constant value. For example: Status (Task) = ‘Not Started’ For Date fields, you can specify a number of days from today's date. For example: Due Date (Fund Request) = Today() + 180 For an Owner field, you can specify a <record creator> (variable) or a specific user. No lookup is supported, you must type directly in the field. You can also create complex expressions for default field values. You can enter an expression directly in the Default Value field, or click the fx icon to open the Expression Builder window, where you can enter an expression. For information about the syntax you can use for expressions, see Expression Builder. To use Expression Builder in field management, you must have the Advanced Field Management privilege in your user role. Users who have the Administrator role can enable this privilege for their own role and for other roles.

Published August 2022 | Copyright © 2005, 2022, Oracle and/or its affiliates. Legal Notices.