Siebel Business Rules Administration Guide > Integrating Rules with Siebel Runtime Events > Scenario for Using Rules to Validate Data at Runtime >

Specifying Business Logic Requirements

This topic is a task in the design process that is listed in Scenario for Using Rules to Validate Data at Runtime.

A PreWriteRecord event provides the following validation actions for a new or modified service request record:

• Disallow a service request with no description and provide an explanation to the user.
• Disallow a service request with no associated account and provide an explanation to the user.
• Disallow a service request with no associated contact and provide an explanation to the user.
• If a service request does not have an area, display a message requesting an area entry.
• If a service request has an activity plan that does not have a name, display a message to make the user aware.

  NOTE:  This rule could be also be implemented in a PreWriteRecord event on the Activity Plan business component, so that when a user creates or modifies an activity plan, the user is warned to assign a name. Implementing this rule on the Activity Plan business component is appropriate if it should apply to activity plans in all contexts; that is, activity plans associated with agreements, accounts, and so on, as well as with service requests.

A WriteRecord event sets several field values for a new or modified service request record:

• If a service request has an organization whose name begins with PCS and the service request has no primary organization then set the organization of the service request to Default Organization.
• If a service request's commit time is not set, then set the commit time to the current time.
• If a service request's reproduce is set to Always, then set the priority of the service request to low.
• If a service request's reproduce is not set, then set the reproduce to Always.

A PreWriteRecord event sets a field value for a new or modified activity that is associated with a service request:

• If an activity is associated with a service request, and the status of the activity is Unscheduled, then change the status of the activity to Alerted.

  This rule should execute correctly in both the Service Requests screen and in the Activities screen.

  NOTE:  The intent of the business rule in this case is to insure that any activity with a status of Unscheduled that is associated with a service request should have its status changed to Alerted. You could implement this rule in a PreWriteRecord event on the Service Request business component instead of on its child Action business component. However, if you implement this rule on the Service Request business component, then an activity can be assigned to a service request without the service request being subsequently saved. In such a scenario, the activity's Unscheduled status is not set to Alerted. Thus this rule is written on the Action business component so that the Status field is set appropriately whenever the condition is satisfied.

  For guidelines on writing rules on child business components, see Writing Rules that Involve Parent and Child Business Components.