I Wish I’d Started Using Workflows Sooner
Sometimes in life, you catch yourself being resistant to change, even when you are losing out by not adapting. Workflows were one of those things that to me, just seemed like “…if it’s not broke, don’t fix it”. It’s quite strange to find yourself opposed to something purely because you liked the way it was before – I liked controlling all the details using microflows, and didn’t want to give up control over the little things in my projects. Let’s go over why I was mistaken and why it’s not workflows vs. microflows – it’s workflows AND microflows.
What are workflows
Workflows are a way to define processes at a higher abstraction level compared to microflows. They are a way to manage and extend common business processes that are executed on a regular basis within an organization. While they look visually similar to microflows inside of Studio Pro – they are more focused on tasks that are executed by the user or system, normally over a period of time ranging from a few hours and, in rare cases – sometimes even years. As they are more focused on tasks, you get fine-grained control over each task and the overall state of the Workflow.
They achieve this with a variety of tools in the toolbox which allow you to jump steps and wait for confirmation others have completed their execution before proceeding with the next, to name just a few.
And for anything out of the ordinary you can always extend the toolbox using your own microflows and even trigger new workflows to quickly adapt to changing scenarios.
Isn’t all that possible with microflows?
Yes. This is what confused me for a long time. While everything is achievable with microflows, sometimes workflows just make the process better for everyone involved.
While it is possible to build processes without using workflows, building all that manually requires careful planning and additional effort to ensure processes are managed effectively. Utilizing microflows alone to manage state, send notifications, handle security, navigation…you can achieve similar outcomes, but you will create additional complexity and with less out-of-the-box support than when using workflows.
This complexity can create a jumbled mess which is hard to understand for other people who work on the project with you, and who may have to maintain the application in the future. As workflows clearly lay out the process in sequence, they’re kind of self-documenting, and therefore an easy way to clearly document a process which spans many steps. While workflows may save time developing, one of the biggest benefits is to the team and the organization, through time saved in maintaining apps built using workflows.
When workflows are a good idea
There are some other considerations as to when a workflow is needed, or helpful.
Workflows are best when used to define and outline large processes, things which can take place over an extended period of time and normally have a lot of steps. A good example is getting a quote for insurance or some other type of contract. There is the initial contact, information gathering, and creating a quote, the customer must then accept or reject the offer before the application can be concluded. This is a clearly defined process which involves both human and system tasks.
It is also a process which will not change frequently. Over time the company may offer different options or new products, but the process of getting a quote and accepting it will not change dramatically.
You should also consider using workflows when there is a mix of system and user tasks. In the example of an insurance policy – the customer will have to accept certain disclaimers and compliance documents, which are normally sent via email. Triggering emails from the system which await an action from the user or customer are simplified using the parallel split and wait functions baked into workflows.
It also has the added benefit of self-documenting the process, creating a clear decision tree which can easily be understood by any who open the project
When not to use workflows
Not complying to the criteria above is not an instant disqualification for using a workflow, though it should raise some red flags. However, there are several clear indicators that you should not use workflows:
- When the process is likely to change in the future. The nature of unpredictable work with unexpected outcomes does not fit nicely into the workflow box.
- If the process is unpredictable and more focused on achieving the correct outcome, the rigidity of workflows will not accommodate the many possible outcomes. Having a clear goal or destination is preferrable.
- Processes which require a high degree of freedom for users to decide the best path might not fit well with the tight constraints of workflows.
In summary, it’s best to use workflows for predictable processes which are repeated often and will not deviate from the standard process outlined in the workflow.
They aren’t exclusive
The biggest reason I shifted my opinion of workflows was realizing they aren’t one or the other. You can and should have both in an application. You may think your app is niche and will not fit into a box, but every app has processes which are commonplace and can easily be defined in a workflow, and for more complicated bits, microflows are always an option.
Using the example of an insurance quote again, anyone who has insurance knows what the process is like- the agent spends time gathering your details, asking questions about lifestyle and risk, submitting your details to be underwritten and then either accepting or rejecting the offered quote before firing off emails to confirm and document the entire deal. These are clear steps that will not change, with a clear mix of user and system-based tasks. The process normally takes a few minutes to up to an hour to complete and may involve the user leaving the application for a bit to perform a task outside of your system (opening the email to confirm your account).
You could build a fully custom solution for this, but it would quickly generate hundreds of documents in your project, which can easily be replaced by a single workflow with some carefully crafted microflows sprinkled in. You don’t have to create your entire app using only workflows, but finding clear processes that can be replaced with them will make the project easier for yourself and others to maintain. Saving time both during and after development has ended. Both microflows and workflows have uses and advantages in this case and failing to include both would be a missed opportunity in creating a better application.
Why I was resistant to change
I think the reason I avoided workflows was a misunderstanding of what workflows are. They are not a direct replacement to microflows but are a more efficient way to organize complex processes at scale. They aren’t meant to replace microflows but instead provide a framework and structure to how microflows are used to support business processes, making the project easier to maintain and change in the future. While they are meant to improve efficiency, the greatest efficiency gains are after initial development of the project and mostly involve streamlining the process and making it more readable to the developers who come after you.
Looking back at some of the apps I built, I could have saved myself and others a lot of time if I opted to use workflows. Sometimes it makes more sense to spend time understanding something new instead of forging ahead the same way you always do.