Print      Open PDF Version of Online Help


Previous Topic

Next Topic

About Expressions

An expression is a valid combination of one or more operators, functions, fields, and literals that can be evaluated by Oracle CRM On Demand. This topic provides information about the following features of expressions:

  • Expression length
  • Literal length
  • Conditional expressions
  • Validation expressions
  • Using dependent fields in expressions

Expression Length

For the message body of an email configured through the Send Email action on a workflow rule, the maximum supported length of an expression is 2000 characters, including spaces. You can insert a line break in the email message by pressing Enter. A line break is counted as two characters in the text box.

In all other cases where Expression Builder is used, the maximum supported length of an expression is 1024 characters, including spaces.

You must also ensure that the total number of characters in the field where you are saving the expression does not exceed the limit for that field. In the following workflow fields, three percent signs (%%%) are placed before and after functions and field names:

  • The Subject and Message Body fields in an email configured through the Send Email action
  • The Subject and Description fields in a task configured through the Create Task action

The percent signs indicate that the function or field name is to be converted to a text value. Each percent sign is counted as one character in the field where the expression is saved.

If you type a function or field name directly in the field, you must type three percent signs before and after it. If you use Expression Builder to embed a function or field name, the percent signs are automatically added.

For example, if you use Expression Builder to insert the following field name into the message body of an email on a workflow action:

[<AccountName>]

Expression Builder inserts the following (a total of 21 characters) into the message body of the email on the workflow action:

%%%[<AccountName>]%%%

Literal Length

When you pass a string or numeric literal to a function in Expression Builder, the literal must not contain more than 75 characters, including spaces. If a literal exceeds 75 characters, then Expression Builder considers the literal to be a syntax error. When you pass a string to a function by referencing a field name, the limit of 75 characters does not apply to the length of the value in the field passed to the literal.

When you create an expression to set a default value for a field, the limit of 75 characters applies to any string or numeric literals passed to any function in the expression. In addition, the number of characters in the result of the expression must not exceed the maximum number of characters allowed in the field.

Conditional Expressions

A conditional expression is an expression that, when evaluated by the application, always returns a Boolean value such as True or False.

NOTE: Yes, No, Y, and N are not Boolean values. If you specify True or False as return values for functions such as the IIf function, then True and False are returned as strings and not as Boolean values. Using incorrect Boolean values in conditional expressions can result in unpredictable behavior.

An expression used in any of the following contexts must be a conditional expression:

  • To specify a field validation rule
  • To specify a condition in a workflow rule
  • As the first parameter in an IIf function

Validation Expressions

Validation expressions are used to ensure that the data entered in fields is valid. A validation expression must be a conditional expression.

A validation expression for a field is evaluated when the record is created, and each time the field is updated by a user, except in the following circumstances:

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

A validation expression is different from other types of expressions in that it can start with a conditional operator. For example, if Account Name is the field being validated by the expression, the expression can start with:

= 'Acme Hospital'

This expression, though not well formed, will pass a syntax check, because Oracle CRM On Demand inserts the name of the field being validated before the expression if it does not find a field name at the start of the expression. You can also enter the validation expression as follows:

[<AccountName>]= 'Acme Hospital'

where [<AccountName>] is the field being validated.

If the expression requires other fields to be evaluated in addition to the field being validated, it is standard practice for the first comparison in the expression to be performed on the field being validated.

Validation expressions are used only in the Field Validation text box in advanced field management in Oracle CRM On Demand.

Validation Expression Examples

Example 1: A business process requires that the close date of an opportunity must be later than the created date of the opportunity.

To implement this process, create a validation expression for the Close Date field (in the Field Setup page for opportunities) as follows:

> [<CreatedDate>]

Alternatively, you can use the following example, but note that the field that is being evaluated (Close Date) must be the first field in the expression:

[<CloseDate>] > [<CreatedDate>]

For information about creating and editing fields, see Creating and Editing Fields.

Example 2: A business process requires that the revenue of an opportunity must be a nonzero value when the probability of the opportunity is 40% or greater.

The business rule indicates that the dependency is on both fields and can be restated as follows:

For an opportunity, revenue cannot be zero when the probability is greater than or equal to 40. Conversely, the probability cannot be greater than or equal to 40 if the revenue is zero.

A validation expression for a field is evaluated when the record is created, and each time the field is updated by a user. Because an update to either the Probability field or the Revenue field can affect both fields, you must have validation rules on both the Probability field and the Revenue field to implement the business rule correctly. (For information about creating and editing fields, see Creating and Editing Fields.)

The steps required to implement this example are as follows:

  1. Configure the following validation rule for the Probability field:

    < 40 OR ([<Probability>]>= 40 AND [<Revenue>]> 0)

    Note that you do not use the percentage sign (%).

  2. Add a validation error message such as the following to the Probability field:

    Revenue must be greater than 0 when the probability is greater than or equal to 40%.

  3. Configure the following validation rule for the Revenue field:

    (> 0 AND [<Probability>]>= 40) OR [<Probability>]< 40

  4. Add a validation error message such as the following to the Revenue field:

    Revenue must be greater than 0 when the probability is greater than or equal to 40%.

Using Dependent Fields in Expressions

A dependent field is a joined field whose values depend on a foreign key. A joined field is a field on a record type that uses a foreign key to reference a field on another record type. An example of a dependent field is the AccountName field on the Opportunity record type. The AccountName field on the Opportunity record type is a joined field whose values depend on the AccountId foreign key field, which references the Account record type.

If your expression has to determine the value of a dependent field, then it is recommended that you use the JoinFieldValue function and get the most recent value of the field by referring to the ID field; that is, the foreign key field. Otherwise, the results of your expression might be incorrect, and the outcome of the expression value might be invalid. For more information about joined fields and the JoinFieldValue function, see JoinFieldValue.

Related Topics

See the following topics for related Expression Builder information:


Published 5/4/2012 Copyright © 2005, 2012, Oracle. All rights reserved. Legal Notices.