Siebel Business Process Designer Administration Guide > Using State Models >

Using a State Model

After you create or modify a state model, your changes will not take effect until either a new server process is spawned or you restart the Siebel server.

The state model is not stored in the Siebel repository. State models can be created at any point through the Siebel user interface without compiling a new Siebel repository file. For mobile users who connect through Siebel Remote, the state model will be enforced once a user has synchronized with the database server. State models are supported on regional nodes. For more information about support for regional nodes, see Modifying the Replication Field and Siebel Remote and Replication Manager Administration Guide.

The state model is enforced on the Siebel client, not on the Siebel server. When a user activates one of the business components that has a state model, the Siebel client will check to see that any state models created for the business component are enforced. A business component is activated if a user navigates to an applet that is based on that business component.

NOTE:  User-defined business components are not supported.State models are enforced for updates made through Siebel Visual Basic, Siebel eScript, and workflow processes because these updates do not circumvent any business component logic. However, state models are not enforced for updates made through Enterprise Integration Manager or workflow policy programs.

When a user tries to change a field that a state model is based on, such as a Status field, the user sees only the field values that have been defined as possible transitions. For example, if the state transition from Open to Closed has been defined, the value Closed will be available when the current state is Open.

The transition will be available for the user only if either of the following is true:

If the transition has been defined with a condition (rule), this condition is checked when the user selects the new field value. If the condition has not been satisfied, the user will be notified that the condition was not satisfied, and the transition will not take place.

As soon as a state model expires, it will no longer be used. This means that if you have two state models on the same field, the picklist will always behave according to the active state model. There is no need to bounce the server.

However, you should be careful when defining two state models on the same field. For example, suppose that state model A and B are on the same field. When A expires, B is activated. If A has a field called Open and B does not, then it is possible to be stuck in the Open state after A expires.


 Siebel Business Process Designer Administration Guide 
 Published: 29 May 2003