Applications Administration Guide > State Models >

Creating State Models and State Transitions


This section describes how to create and define state models and state transitions.

To enable a state model on a business component, the field used should:

  • Be an LOV (list of values) or MLOV (multilingual lists of values) field.
  • Have no dependencies on other fields. (For example, do not use a constrained LOV field or a calculated field.)

This task is a step in Process of Setting Up State Models.

To create a new state model

  1. Navigate to the Administration - Application screen > State Models view.

    Some fields are described in the following table.

    Field
    Comments

    Activation

    The date on which the state model begins to be enforced.

    NOTE:  You can set up more than one state model for a given field as long as the activation to expiration periods do not overlap.

    Business Component

    The business component that the state model is based on. The dialog box for this field displays all of the business components that have been enabled for the state model. To enable a business component that is not enabled by default, see Configuring Business Components for State Models.

    Expiration

    The date on which the state model is no longer enforced.

    Field

    The name of the field that the state transitions apply to. The dialog box for this field displays the fields that are defined for the business component.

    Name

    A name that uniquely identifies the state model.

  2. Click the States view tab.
  3. In the State list, create a new record and complete the necessary fields.

    Some fields are described in the following table.

    Field
    Comments

    State Name

    The dialog box for this field presents the list of values for this field.

    Default

    The default state name specifies a beginning value for the business component field.

    NOTE:  If the field is predefaulted in Tools, then it cannot be overridden by the state model.

    No Delete 1

    If checked, records in this state cannot be deleted unless they are referenced by a parent record in which the Cascade Delete property is set to Delete. Cascade Delete always overrides the State Model restrictions. For information about how No Delete effects child records, see Configuring Child Modification for State Models.

    No Update 1

    If checked, records in this state are read-only and cannot be updated.

    NOTE:  No Update also affects a record's child records. For example, if an account becomes read-only due to use of the No Update restriction, the related contacts for the account also become read-only, so inserting and deleting contacts is not possible.

    Restrict Transition

    If checked:

    • Only defined transitions from this state are allowed.
    • And there are no transitions defined, the state becomes an end state, where users cannot transition from it to any other state.

    If not checked, this state can transition to any of the defined states.

    1Note: Even if No Delete and No Update restrictions are specified for the state model, MVG fields that do not have a direct parent-child link between the parent field and the MVG applet are not read-only when a record is in a No Update or No Delete state. To avoid confusion for end users, you can remove MVG fields from the child applet.

  4. Click the Transitions view tab.
  5. In the Transitions list, for each restricted transition, create a new record and complete the necessary fields.

    Some fields are described in the following table.

    Field
    Comments

    From State

    The original field value for the state transition.

    NOTE:  If a state transition is not defined for the default State Name value, the field that the state model is based on cannot be changed.

    To State

    The new field value for the state transition, changing from the value indicated in From State.

    Public

    Indicates that all users are allowed to make the transition. If checked, records in the Authorized Positions list are ignored. For more information, see Step 6.

    Rule Field

    Rule Operator

    Rule Value

    These three fields allow you to specify a simple field condition that must be satisfied for the transition to occur.

    For example, a state transition is created that allows users to change the status of a service request from Open to Closed when the sub-status is Resolved uses a rule like this:

     

    The syntax for rules is the same as the syntax for calculated field values and field validation in Siebel Tools. For more information about the syntax, see about operators, expressions, and conditions in Siebel Developer's Reference.

    Rule Expression

    Allows for the creation of complex or multiple conditions that must be satisfied for the transition to occur.

    The syntax for the Rule Expression field is the same as the syntax for calculated field values and field validation in Siebel Tools. For more information about the syntax, see about operators, expressions, and conditions in Siebel Developer's Reference.

  6. To restrict a state transition to a subset of users (positions), clear the Public field for the transition and create records in the Authorized Positions list.

    NOTE:  If the Public Flag is not checked and no positions have been added in the Authorized Positions list, no users are able to make the transition.

Applications Administration Guide