Siebel Business Rules Administration Guide > Implementing Rules in Siebel Task-Based UI >

Scenario for Using Rules to Provide Dynamic Navigation in a Siebel Task

This topic provides an end-to-end example in which a task is configured to create an opportunity, categorize the quality of the lead based on its potential revenue, and branch accordingly to populate other fields on the opportunity. Output from the rules engine provides the criteria for the branching.

Each of the following sections applies to one job role on the Siebel project that is responsible for completing the implementation tasks in that section.

The two job roles are:

• Business analyst or business developer. This individual is responsible for specifying the business process flow, the business logic requirements, and the UI requirements.
• Siebel configuration developer. This individual implements the requirements provided by the business analyst or business developer by performing configuration tasks in Siebel Tools, HaleyAuthority, and in the Siebel application.

The implementation process includes the following subprocesses and top-level tasks, by role.

• Design process. The tasks in this process are done by the business analyst or business developer:

1. Defining the Business Process Flow
2. Creating View Mock-ups
3. Specifying Business Logic Requirements
4. Specifying Invocation Requirements

• Development process. The tasks in this process are done by the Siebel configuration developer:

5. Creating the Task
6. Creating Business Component and Task Group Definitions
7. Creating UI Elements
8. Binding Views to Task Steps
9. Adding Business Logic
10. Deploying and Activating Rule Modules
11. Testing Rule Modules
12. Providing Calls to the Rules Engine
13. Deploying, Administering, and Testing the Task