Workflow wait conditions can be very useful. Say you need to have an email go to a customer 30 days prior to their contract renewal, it can be tempting to use a wait condition. However, excessive use of wait conditions has a downside.
- Performance: each waiting workflow instance carries performance overhead. The more waiting workflow instances that you have, the more server resources will be consumed by the Asynchronous Processing Service.
- If you change the logic in your workflow and republish (like update the text of the email sent to your client), it does not change waiting workflow instances. For example, if you change the renewal email frequency to 15 days rather than 30 days, any workflow instances that are waiting will not be updated. (See tip # 24 for a potential way to minimize this risk).
As an alternative to wait conditions, use a scheduled batch process using Scribe or SSIS with Kingswaysoft to fill the role of the wait condition. This can be scheduled to run in batch with no impact to performance of the Asynchronous Processing Service.