This event is triggered when a workflow group changes from one state to another.

The following states are available:

1. Idle - This is the state of a workflow group that is valid but where no workflows are being executed.
    

2. Invalid - A workflow group will change state from Idle to Invalid if the configuration is made invalid. Once the configuration is valid again, the workflow group will change back to the Idle state.
    

3. Hold - A workflow group will change state from Idle to Hold if configurations are being imported with certain options selected. Once the import is finished, the state will change back to Idle again. If a default import is made, the workflow group will not change into the Hold state.
    

4. Running - A workflow group will change state from Idle to Running as soon as it is being executed. If the execution is allowed to finish, the state will change back to Idle.
    

5. Suppressed - If configurations are being imported with certain options selected while a workflow group is in Running state, the state will change to Suppressed. For real-time workflows, the state will change back to Running again once the import is finished. Batch workflows will remain in Suppressed state until all members have finished execution and will then change to Idle state. If the workflow group is manually stopped, the state will change to Stopping. If a default import is made, the workflow group will not change into the Suppressed state.

6. Stopping - If the execution of a workflow group is manually stopped, the state will change from Running or Suppressed to Stopping.
    

7. Aborted - If one of the members of the workflow group aborts, the workflow group will change state from Running or Suppressed to Aborted once all of its members have finished execution.

See 3.2.3 Workflow Group States for further information about workflow group states.

Filtering

In the Event Setup tab, the values for all the event fields are set by default to All in the Match Value(s) column, which will generate event notifications for all state changes for all workflow groups. Double-click on the field to open the Match Values dialog where you can click on the Add button to add which values you want to filter on. If there are specific values available, these will appear in a drop-down list. Alternatively, you can enter a hard coded string or a regular expression.

The following fields are available for filtering of Group State events in the Event Setup tab:

Group State event specific fields

• groupName - This field enables you to select which workflow groups you want Group State event notifications to be generated for.
  
  
  Adding Workflow Groups
   

• groupState - This field determines for which states you want Group State event notifications to be generated. If the state for one of the matching workflow groups changes into any of the states added for this field, a group state event notification will be generated.
  

  Adding workflow states

Fields inherited from the Base event

The following fields are inherited from the Base event, and can also be used for filtering, described in more detail in 4.3.1 Base Event:

• category - If you have configured any Event Categories, you can select to only generate notifications for Group State events with the selected categories. See 4.4 Event Category for further information about Event Categories.

• contents - The contents field contains a hard coded string with event specific information. If you want to use this field for filtering you can enter a part of the contents as a hard coded string, e g the state you are interested in Idle/Running/Stopping/etc. However, for Group State events, almost everything in the content is available for filtering by using the other event fields, e g groupName, groupState, etc.

• eventName - This field can be used to specify which event types you want to generate notifications for. This may be useful if the selected event type is a parent to other event types. However, since the Group State event is not a parent to any other event, this field will typically not be used for this event.

• origin - If you only want to generate notifications for events that are issued from certain Execution Contexts, you can specify the IP addresses of these Execution Contexts in this field. However, since the Group State events are only issued from the Platform, this event field should typically not be used for filtering.

• receiveTimeStamp - This field contains the date and time for when the event was inserted into the Platform database. If you want to use timeStamp for filtering, it may be a good idea to enter a regular expression, for example, "2012-06.*" for catching all Group State events from 1st of June, 2012, to 30th of June, 2012.

• severity - With this field you can determine to only generate notifications for state changes with a certain severity; Information, Warning, Error or Disaster. For example, a state change from Idle to Running will typically be of severity Information, while a state change to Abort state will typically be of severity Error.

• timeStamp This field contains the date and time for when the Execution Context generated the event. If you want to use timeStamp for filtering, it may be a good idea to enter a regular expression, for example, "2012-06-15 09:.*" for catching all Group State events from 9:00 to 9:59 on the 15th of June, 2012.
   

Examples Group State Event Configuration