Workflow Event Lifecycle

The lifecycle of a workflow event is dependent on whether the event has to wait on something before it can complete or fail. For example, an event that creates a field activity has to wait until the field activity is performed before it can be considered complete.

The following diagram shows the possible lifecycle of a workflow event:

The following points explain the lifecycle of workflow events of the normal variety:

• Normal events are initially created in the pending state.
• On a pending event's trigger date, the workflow event activation process (referred to as WFET ) executes the event's activation algorithm.
• An event's activation algorithm may cause a pending event to become in error. For example, if an event used to create a field activity can't find a valid service point, the algorithm could change the status of the event to be in error. A user should correct the cause of the error and then change the event's status back to pending. The pending event will be processed the next time the activation program runs.
• An event's activation algorithm may cause a pending event to fail. For example, if an event used to validate a notification detects invalid information (e.g., an incoming notification is missing the customer's account number), the event will fail.
• A pending event becomes complete when the event's activity is successful. For example, if an event used to validate a notification determines the notification is valid, the event will complete. A user may manually change the status to complete if the event type indicates that manual completion is allowed.

• A pending event will be cancelled automatically by the system if the workflow process is cancelled (a workflow process will be cancelled if an event fails or at the discretion of an operator). A user may cancel an event at will. Refer to How Are Workflow Events Canceled for more information.

The following points explain the lifecycle of workflow events of the waiting variety:

• Waiting events are initially created in the pending state.
• On a pending event's trigger date, the system executes the event. For example, if an event is used to create a "special read" field activity, on the event's trigger date, the field activity is created.
• An event's activation algorithm may cause a pending event to become in error. For example, if an event used to create a field activity can't find a valid service point, the algorithm could change the status of the event to be in error. A user should correct the cause of the error and then change the event's status back to pending. The pending event will be processed the next time the activation program runs.
• If the activation algorithm did not cause the event to become in error, the event's status is changed to waiting while the system waits for the field activity to be performed.

• A waiting event becomes complete when the system sees that the thing that it's waiting for is finished.
• A waiting event fails when the system sees that the thing that it's waiting for didn't complete successfully. For example, an event that sends a confirmation request to a service provider asking if it's OK for a customer to switch suppliers would fail if the service provider denies the request.
• A waiting event will be cancelled automatically by the system if the workflow process is cancelled (a workflow process will be cancelled if an event fails or at the discretion of an operator).
• A pending event will be cancelled automatically by the system if the workflow process is cancelled (a workflow process will be cancelled if an event fails or at the discretion of an operator).