A workflow in a waiting state consumes system resources because it constantly polls the object from which it requires a response. If you know that a workflow will potentially wait for a long time before it receives the response it requires, you can add long-running workflow elements to the workflow.

Every running workflow consumes a system thread. When a workflow reaches a long-running workflow element, the long-running workflow element sets the workflow into a passive state. The long-running workflow element then passes the workflow information to a single thread that polls the system for all long-running workflow elements running in the server. Rather than each long-running workflow element constantly attempting to retrieve information from the system, long-running workflow elements remain passive for a set duration, while the long-running workflow thread polls the system on its behalf.

You set the duration of the wait in one of the following ways:

  • Set a timer, encapsulated in a Date object, that suspends the workflow until a certain time and date. You implement long-running workflow elements that are based on a timer by including a Waiting Timer element in the schema.

  • Define a trigger event, encapsulated in a Trigger object, that restarts the workflow after the trigger event occurs. You implement long-running workflow elements that are based on a trigger by adding a Waiting Event element or a User Interaction element in the schema.