Running workflows always cache the definitions and are unaffected by any future definition changes. This behavior is by design, however, occasionally it’s desirable to have some of the steps to use the latest definitions, e.g. content of the email. Isolating these steps into a separate child workflow effectively allows users to modify properties of a running workflow.
Let’s say you have a requirement to send an appointment reminder to a customer one day before the scheduled service activity is due. Typical implementation would like this:
The problem is, as soon as the workflow starts (triggered by a service activity record creation), it will be in the waiting state until the time is due. So if you decide to change the email content (to fix a spelling mistake, for example), reminders for the existing appointments will still use the old definition even though the reminders themselves could be in the future.
Solution is to isolate sending email into a child workflow:
In this implementation, email reminders will always use the latest definitions from the Send reminder workflow because it does not actually run until the time is due.
[…] Gus “Answer First Ask Later” Gonzalez, probably after reading our tip about using child labor in workflows, immediately chimed […]
[…] 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 […]