Workflows is how you augment the functionality of Blueprint's Elements to out together the processes you will be executing within your Organization or Team.
One of the most common ways of building a workflow is by linking an event that's triggered by the underlying Blueprint Platform (like the hiring of a new team member) or by another element within the same blueprint (like the completion of a Task).
For example, in a typical employee onboarding process, you might want the managers within your organization to create a development plan for each new team member that joins their teams. Still, you want those new team members to have their input into the plan. What you might want to do is have the team member complete a task where they answer a few questions about areas they'd like to improve, areas of strength, and goals for the next 6 months then use this information to trigger a new task for your manager to have a 1:1 conversation and put together the development plan. To codify this process in a workflow, you'll link a task named "Hold 1:1 Conversation on Development Plan" for example, to the completion of a team member task named "Input for Development Plan." This way, both Content and Due Date of the second Task is infinitely more contextual than if we blindly execute them in parallel.
A second way of creating workflows is by simply parallelizing the execution of tasks. For example, say we are codifying the blueprint for our perfect Scrum retrospective, we might want the execution of elements to happen in parallel. We can think of a Survey element for every member of the Scrum team with questions about what worked, what didn't and what's the team commitment for the following sprint, and a simple Task that reminds the Scrum master to collect the right metrics and prepare to moderate the retro discussion. We don't want any dependency between these two elements. See the image below.
