• UID - internal identifier assigned to the state by the system.
• State ID - unique identifier you assign to the state. This identifier must be unique among all states in this model including children states and all states in any sub-models referenced by this model.
• Description - a textual description for the state.
• Tags - requirements tags, separated by semi-colon if multiples are specified. These tags are then used to track success and failures (states and transitions).
• link show - to bring up the requirements corresponding to the tags entered if you have configured the requirements tag integration.
• Reset URL - url to be used to set current page when the validation fails for the state. This is used to ensure the subsequent test steps can continue when the AUT and the model got out of sync due to failures. For example, the model might be expecting AUT to be at order page but due to failure the AUT actually is at shopping cart page. In this case, system will automatically set AUT to order page using this url.
• color - choose a color for the state node on the graph.
• Initial State - if this state is an initial state for the model. There should be only one initial state in the model.
• Final State - if this state is a final state. The model can have one or many final states. Normally each model should have at least one final state.
• State Init - link to mScript for the state init trigger. Init trigger is executed once per model execution during the model initialization.
• OnEntry Trigger - link to mScript for the onentry trigger. OnEntry trigger is executed each time the state is traversed.
• OnExit Trigger - link to mScript for the onexit trigger. OnExit trigger is executed each time the execution exits the state and before any of the transition triggers.

• button OK - to accept the changes. The changes will then be saved to the server memory. You must select “File / Save” menu action to actually save the changes to file. This button is initially disabled until changes are made.
• button Cancel - to undo changes made to this state.

The state node is used to represent a state in your model. Note a state may contain children states, which is called a super state. If you have a large model, super state is useful to organize states in groups making a large model much easier to work with and test.

The state node should contain at least one transition leading to another state and should have at least one transition pointing to it from another state.

Drag and drop a state to another state moves the state into another state. Drage and drop a state to an mCase does not move the state, instead it creates test step(s) in mCase that represents the state or transition copied previously.

New in release 2.1: when the state verification fails it usually causes the rest of the test to fail as AUT is not in the correct state. With new state url, you can reset the state and the rest of your testing can continue.

New in release 3.0: you may attach a submodel to a state. A submodel is another MBT model which can be included in different models. When a submodel is attached to a state, it is populated with all states/transitions from the submodel including mScripts, but they should not be changed from the model referencing it.