Page Comparison

...

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 a 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 the Suppressed state until all members have finished execution and will then change to the 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.

...

• 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 the 1st of June, 2012, to the 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.
   

...

...