Scriptless ways to validate field input in Siebel CRM

There are lots of articles on how to do X without using script. Reasons why not to use script include performance, maintainability and reduced complexity. See Declarative Alternatives to Using Siebel Scripting (Doc ID 477842.1) for details on how to avoid scripting in various contexts.

Also you can find interesting scriptless examples/challenges on various topics on Siebel Hub: http://www.siebelhub.com/main/?s=scriptless

This article is all about Scriptless Field Validation. Here is a list of possible validations. There are most likely even more possibilities. Feel free to add your ideas in the comments. Please also leave a comment or email me if you find any errors (:

Validate the data input of a field

The following tools are available to restrict user input:

• Check if value is null (Nullable, Required)
• Uniqueness of field values (unique index)
• Data types / domaints (Physical Type, Type, Length)
• Field Validation
• Data validation manager (validations of various fields within a record)
• Value constraints:
• Picklists
• Pickmap constraints
• Picklist Search Specification
• Picklist's BC: Search Specification
• Picklist's BC: Join Spec / Join Constraint

In the following text, each of these settings is discussed:

Can the field be empty?

• Table level: Nullable
• BusComp level: Required

Use this to force the user to enter a value into the field. If you meet a not-null-requirement consider first to implement it on table level. Leaving the table column nullable while setting the required flag only on BC level could be a potential source of errors. However, if the field should only be required for some BC's/views while it can be null in other BCs/views, you have the possibility to fine-tune the behaviour by using combinations of those two flags.

Are multiple instances of the same field value (or the combination of values in various columns of a single table) allowed?

• Table level: Unique Index

Keep in mind that unique indices need space and may decrease performance on insert/update/delete - heavy tables. On the other hand, unique indexes can be way more performant to prevent doublettes than querying for the existance of a record in the PreWriteRecord-Event of a BC.

Domain range / format of the field value

• Table level: Physical Type / Length
• BusComp level: Type / Text Length BusComp level: Validation (Rule that yields true/false)

This should be obvious. If you only want integer values in a field, make it an integer field! Same goes for date/time, etc.


Validating the field value in run-time (possible: combination of values of multiple fields the record)

• Use the Data validation manager to check field values in runtime. 

Thus, the corresponding rules can be changed without the need to redeploy your solution.

Validate the field value against a list of possible values (Lookup)

Which field value from which entity should the field value be picked?

• Define Picklist / Pickmap

Whenever a user should input only from a range of possible values, define a picklist (that either takes the value from an LOV or from another entity/BC). This not only helps the user (via the pickapplet search possibilities) but also keeps you data clean. Hardly anything is more frustrating than searching for all PhD employees in your database when the users can input the academic title as free text - resulting in various values like "PhD", "PHD", "Ph D", "Ph. D", "Ph.D",etc... it's avoidable!

Restrict picklist: Only allow records of the picked BC that have field values equivalent to field values of the picking BC:

• Pickmap constraint

This is a nice one. With picklist constraints you can constraint what the user can input into a field based on the values of other fields of the same records.
Note the possible use of calculated fields. Eg. if you only want to allow records which's "Main Flag" is set to "Y", you could define a calculated field in the picking BC that is always "Y".


Filter records that can be picked:

• Picklist level: Search Specification

Picklists themselve can be constrainted already by their search specification. For example, you can create separate picklists for "All Employees" and "Active Employees" by using search specifications.
Also keep in mind that this search specification is additive to the search spec that is already defined in the picklist's underlying BC.
Furthermore the available records can be constrainted by having (inner) joins defined in the underlying BC.
So whenever you ask yourself "why can't i choose record XX", you now know the first places to search for any constraints :)


Only pick values if the picking field does not already contain a value:

• Pickmap Field level: UpdateOnlyIfNull

This is not really a constraint, but it's nice to mention that automatically picked values (within the pickmap) can be configured so they are only picked if the target field is null. This way you easily can create a default value for a field which's value is retreived from a record of another entity (the picklist's BC).