Print      Open PDF Version of Online Help

Administering Oracle CRM On Demand > Application Customization > Record Type Application Customization Page > About Field Management

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
• Renaming Fields
• 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, 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 setup 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 Customization 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.

About Field Validation

When you create custom fields or edit field definitions, you can specify in the Field Edit page that fields are required or read-only. You can also specify predefault or postdefault values on new records.

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 saved, the application validates that the Cause field is NOT NULL.

As another example, your company might have a business policy that if an opportunity is lost, which had an expected revenue of $100,000 or greater, the reasons for losing must be tracked. In this case, you define the Reason field on Opportunity as required only when the Revenue field has a value greater than 100,000. When an Opportunity record is saved, the application validates that the Request field's value is greater than 100,000.

If a validation fails, an error message is displayed, warning users to enter a value for the required field before saving the record. You can also specify a custom error message (in the Field Validation Error Message field) to be displayed if the validation fails.

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 only for a specific role, 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 Customizing Static Page Layouts.

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.

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 that 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.
• 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 billing 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.

The following circumstances prevent a field validation expression from being evaluated:

• A field is left blank when the record is created. Field validation does not force a value to be required.
• A field has a pre-existing invalid value, and it is not changed when it 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 these 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
• 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 checked by default so that, if, for example, a sales representative opens the SR, it is routed to the correct CSR based on pre-defined assignment rules.

NOTE: Most of these are possible only if your role includes the Advanced Field Management privilege.

There are two types of default values for fields:

• Pre Default. The field is prepopulated 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 prepopulated 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.

NOTE: Post Default field values are not supported in the Offline client, and display as blank fields.

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 these 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
• 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.

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.