Similar to the previous recipe, a System Customizer or higher security role is required to perform the configuration as well as a solution to contain the changes.

In step 2 to step 4, we created a workflow that triggers on creation (when the contact record is first created, the workflow will start waiting). The workflow can also be called on demand in case we want to trigger it again. In this example, the contact might already be created but not as a Student. Once the contact is set as a Student, the workflow can be triggered manually to send the welcome e-mail.

In step 5 and step 6, we set up the wait condition to wait for a day.

In step 7 and step 8, we checked if the contact is an active student with an e-mail address.

In step 9 to step 12, we created a personalized e-mail for the contact and welcomed them.

In step 13, we activated the workflow.

When asynchronous workflows are triggered, they enter into a pool to be processed when the asynchronous service is free. Asynchronous workflows are typically executed within seconds or minutes. If the execution is taking hours, then you might want to raise a support ticket with Microsoft to investigate. Executing workflows asynchronously is a great way to lighten the load on your Dynamics instances.

When workflows instances are waiting for a condition to be satisfied, they do not consume resources or affect your instance's performance. However, it is generally agreed by the community that it is a bad practice to have too many workflow instances in a waiting status.

In more recent releases, synchronous workflows that turn your workflow into a configurable plugin became available. Microsoft does not recommend synchronous workflows for long processes due to the load that is associated with them. Furthermore, online instances have a limit of 2 minutes per synchronous workflow or plugin. Nevertheless, synchronous workflows are there to be used. Use them wisely.