What is a Workflow Application?
A workflow application is a piece of software that’s dedicated to making a particular task - or related group of tasks - faster, easier, and more efficient.
See, most day-to-day internal tasks are actually pretty repetitive. Many are downright menial.
Today, we’re checking out one of the most effective strategies for managing this fact. Workflow applications provide a simple, flexible way to address this - through automation, process improvement, and a host of other interventions.
In this article, we’re covering everything you need to know - from the theory behind when workflow apps are used and what they achieve - to the specific steps you can follow to build working solutions of your own.
Along the way, we’ll see some specific examples of how we can use them to improve workflows, and a couple of different tools and approaches we can use to help us on our way.
By the end, you’ll have a full working knowledge of how to implement workflow apps to manage your own internal tasks.
But first, let’s dive a bit deeper into the basics.
What is a workflow application?
Workflow applications are discrete solutions that are used to improve the way we carry out specific internal tasks. This can either be a solution that we’ve built from scratch - or an existing workflow platform that we’ve configured for our specific processes.
We’ll think about specific functionality in a couple of minutes. For now, the important thing to recognize is that there are a few key ingredients to a successful workflow app.
The first thing is allowing us to codify existing business logic. In other words, workflow applications provide us with the ability to represent and enforce the rules that underpin workflows in a systematic, computable fashion.
The second is the various ways that this can be enforced. Depending on the specific workflow at hand, this can mean a combination of different approaches, including:
- Facilitating user interactions with workflows in a controlled manner.
- Automating key decisions and follow-on actions.
- Providing access to information within workflows.
- Enabling analysis of workflow performance and process adherence.
Any individual workflow application might provide tools to help us achieve some or all of these.
For instance, some might be aimed at automating the full workflow - with a view to entirely eliminating the need for human interactions. Others might only automate the most repetitive elements - retaining manual inputs for more complex or discretionary decisions.
(McKinsey )
To get a better grasp of this, it’s worth taking a step back and thinking more deeply about the role of workflows in general.
What is a workflow?
A workflow is a defined set of steps that are required to complete a regular task. Depending on the specific task in question, these might follow a fixed sequence - or, they might be based on more complex logic.
So, we can break a workflow down into a few constituent parts:
- The ultimate goal we’re trying to achieve in completing the task.
- The decisions we’ll have to make along the way.
- The follow-on actions that accompany each of these decisions.
- The logic that governs how we move from one step to the next.
- The roles and responsibilities delegated to different colleagues within the workflow.
- Any metrics that determine the performance or success of the workflow.
It’s important to note that when we talk about workflows, we’re specifically referring to regular tasks.
That is, tasks that occur with a certain degree of frequency and are always carried out in a similar way.
In very simple workflows, this means that the same constituent steps are involved for each individual instance of the task. In more complex scenarios, the actual steps might vary, but the logic that dictates which steps are required is the same.
To get a better feel for what this means in practice, let’s take a look at the kinds of tasks that are most often managed using workflow applications.
What kinds of tasks can we target?
In truth, the breadth of potential use cases for workflow applications is enormous. Essentially, this can include any task with sufficient repeatability for us to approach systematically.
At least, that’s where we stand in theory. In practice, we’re also constrained by other factors - including our own technical capabilities and the specific data we have available in order to codify processes.
Since this is going to vary massively across individual businesses, it’s worthwhile thinking about the specific types of tasks that we can tackle using workflow applications.
We can point to a few broad categories of tasks that most commonly crop up.
These include:
- Approval workflows - Where different categories of users can make and respond to requests to access information, take specific actions, or submit work.
- Information management - For dealing with documents, data, and other information at various stages of their lifecycles.
- Resource management - Tracking, deploying, analyzing, and managing physical, digital, and human resources.
- User-centric workflows - Regularized HR, customer service, support, and other human-focused tasks.
- Auditing and analytical workflows - Tasks concerning how we achieve oversight into various business activities.
- Numerical tasks - Repeatable calculations, aggregation, and other numerical tasks.
- Logistical/operational workflows - Tasks relating to how we manage inventory, resource tracking, and other business processes.
- Data management workflows - Specific tasks relating to our internal data assets.
- Response workflows - Event-driven tasks, like how we deal with IT incidents, customer complaints, or other occurrences that require a systematic response.
Again, the idea here isn’t to provide a categorical account of every possible task that we could approach using a workflow application.
Rather, we want to demonstrate the broad clusters of forms that workflows can take. We’ll return to some of the specific capabilities we’ll need under these when we think about types of workflow apps in a second.
(McKinsey )
What do workflow applications do?
First, though, let’s explore the core functionality and capabilities that we can achieve with workflow applications a little bit more fully. Earlier, we gave a very high-level summary of this, including codifying business logic, facilitating automations, and managing user interactions.
Now, we want to break this down into what’s actually going on under the hood to achieve this.
Let’s break it down into five clusters of capabilities.
Handling business logic
First, there’s how workflow apps help us to handle business logic. Very broadly speaking, this can work in two ways.
The first is using what’s known as a workflow management database .
Essentially, this means storing the various states that a workflow can be in at any point in time in our application’s data layer - alongside the potential paths it can take thereafter and the actions required to progress it.
Alternatively, we might codify business logic within the process layer of our application. In this case, our data layer only stores information relating to relevant data objects within our workflow - not the rules that govern them.
We’d then use if/then rules or event-driven functions in order to apply logic to this data - using either hard-coded rules or low-code solutions.
It’s also relatively common to see workflow applications that leverage a combination of these two approaches in tandem.
Workflow automation
Next, we have automated tasks. As we said earlier, there are two elements to this:
- Replacing human decision-making with computation.
- Triggering defined actions in response to defined events or certain conditions being met.
It’s worth considering how each of these works in turn.
With regard to digitalizing common decisions, the first challenge is representing whatever resources or requests we’re dealing with within our workflow. Then, it’s relatively straightforward to enforce rules based on different attributes stored against these objects.
For example, if we had a table storing our invoices - including status and value attributes - we might automatically give set the status to approved if the invoice is under a certain value threshold.
This might be implemented in a couple of different ways, at different layers of the application. For instances:
- Handling it from the process layer with an event trigger - say, when a database row is added.
- Using a stored procedure within our database.
- Using a formula attribute within the invoices table itself.
So what about handling more complex follow-on actions within workflows?
Say for example we’re still dealing with a workflow application for invoice submissions - but this time want to configure the flow of individual tasks that are required when a submission exceeds our automatic approval threshold.
In other words, when the items in question are expensive enough that someone from our finance team needs to manually review the submission. The sequence of steps here might be as follows.
An automation rule is triggered when a user submits a new invoice. The relevant row’s status is changed to pending. Then, the finance team receives a notification that they have a new invoice to review.
Simultaneously, we could have a separate rule that iterates through all of the pending submissions each day, and sends a reminder to our finance team for each of these where a certain period of time has passed since its submission date.
Often, workflow applications are heavily reliant on third-party integrations for both automation triggers and actions. Take a look at our guide to workflow automation to learn more.
Managing user interactions
Earlier, we hinted at the fact that different kinds of users are going to interact with our workflow application in different ways - based on their particular roles and responsibilities. There are a couple of key pieces of functionality that facilitate this.
First, we have what’s known as role-based access control . In essence, this is an approach to granting in-app permissions that’s based on clustering users into distinct groups based on their roles and responsibilities within relevant processes.
For example, the head of your HR department is going to interact with an employee management tool very differently from any given on-the-ground colleague.
More specifically, we’re dealing with how we grant permissions for users to access different databases, tables, or individual entries, as well as specific in-app screens, automation rules, admin functions, and other resources.
The idea is that users should only have exposure to resources and data that are strictly necessary for them to carry out their daily tasks - for the dual purposes of ensuring maximum security and usability.
To complement this latter point, many workflow applications leverage what’s known as conditional design. Essentially, this means displaying UIs differently based on contextual factors.
In the specific context of workflow applications, this could be:
- The current user’s role or other attributes.
- The current status of individual workflow instances.
- Other attributes relating to relevant workflow data objects.
- Environmental factors - like the location or type of device an application is accessed from.
- Any other data conditions we might want to implement.
Conditionality is a powerful tool for enabling us to build sleek, efficient user experiences for managing workflows.
(VentureBeat )
Access to information
Workflow applications also have a role to play in getting the right information in front of the right users at the right time. This is a huge but widely underappreciated driver of efficiency within internal processes.
There are a few distinct kinds of information access we could be dealing with here - which each present subtle differences.
The first is relatively simple - retrieving individual objects or values from a database. For instance, if our HR colleagues need to look up details of our vacation request in order to make a decision.
The two priorities here are effective searchability and presentation of information.
A slightly more complex category of information access relates to data that’s been transformed or aggregated in some way. For instance, if the same HR colleagues needed to look up how many vacation days the company’s employees have left on average.
The key here is providing pre-built dashboards for relevant KPIs within workflow applications.
Lastly, we have information access that relates to documents or other resources and digital assets. This is a bit more challenging from a technical point of view - in the sense that there’s a bit more leg work that goes into making documents searchable compared to tabular data.
The biggest thing we can do is implement effective metadata management, to provide more contextual information that makes it easier for colleagues to search and locate documents.
Building on this, we might also use more advanced parsing or information scraping to further improve metadata usage within our workflow applications.
Types of workflow apps
Now that we have a better picture of what workflow apps actually do, we can move on to thinking about some more specific examples.
Of course, there’s a huge degree of potential variance out there - and to some degree, every workflow app is unique.
At the same time, there are a few categories of workflow apps that we can use to illustrate the kinds of solutions you’re most likely to leverage.
These include:
- Request/approval apps - Tools that are specifically designed to streamline the way we handle requests.
- State machines - More complex solutions that enable data objects to transition between distinct states.
- Dedicated calculators - For complex, workflow-specific financial tasks.
- Information management tools - For managing information, documents, and data through defined flows.
- Automation engines - Workflow applications that are primarily used to coordinate and enforce automation actions.
- Other internal tools - Any other task-specific internal tools we might want to create.
Of course, real-world workflow applications might draw on a combination of several of these types of platforms. Indeed, the specific scope of individual workflow apps can vary greatly - from the simplest approval tools to highly sophisticated automated solutions.
We’ll touch on this again when we consider some of the tools and technologies that can support your efforts in building solutions for handling your workflows.
Who builds workflow apps?
First, though, it’s important to get a bit of additional context on who typically builds workflow applications.
See, this is one type of application that can often be a bit different from your typical software development project. One issue here is that real-world knowledge and experience of how individual workflows operate is such a central success factor.
Who’s involved in building workflow tools can also be dependent on other constraints - like resource availability, technical skills, development budgets, and more. So, this can vary from company to company.
With that in mind, there are a few distinct clusters of colleagues who might be responsible for building workflow applications.
Of course, many times, this will be traditional software development teams. Alternatively, there are plenty of situations where we might rely on non-developers within the IT department.
These days, more and more organizations are empowering colleagues from outside of the IT team to build custom solutions - especially operations team members or colleagues from other departments with some degree of technical competence.
Again, there’s no right or wrong answer, with each of these approaches presenting its own unique benefits and challenges.
Not least of all, there’s the fact that we can’t simply task a non-developer with building custom solutions without providing them with the appropriate tools for the job.
That leads us neatly to…
Tools for building workflow apps
How you opt to create your workflow apps is naturally going to have an outsized impact on the ROI of the project. As with any development project, we’re ultimately trying to balance the cost of the project itself with the specific capabilities that we’re trying to achieve.
There are three primary approaches that we’d like to highlight here.
Our first option is to rely on traditional development tools to build a hard-coded solution. So, a traditional DBMS, IDE, testing tools, and our preferred programming language - in other words.
On the one hand, fully custom developments offer us a pretty much unrivaled level of control and flexibility within projects. On the other, this is by far the most expensive and least expeditious method for building workflow apps.
Given that workflow applications are relatively simple tools from a technical perspective, unless we have particularly advanced requirements, this method might not offer us the best return on investment.
One alternative is leveraging configurable off-the-shelf workflow management tools. These might variously bill themselves as automation tools, workflow management tools, or some other product focus.
The idea is that we can build automated workflows and a range of other tools - like data entry forms and complex business logic, without really needing any custom development. The downside is that we’ll have access to much more limited functionality.
Some might resemble project management software more, with team collaboration tools, task dues dates, drag-and-drop kanban boards, and other functionality to enable colleagues to assign tasks, workflows, and processes.
Therefore, this approach might only be suitable in relatively simple or generic cases.
(BP Trends )
Finally, we have low-code development tools. Low-code is all about providing developers and less technical colleagues alike with the tools they need to build custom solutions, in a fraction of the time.
Check out our features overview to find out more about Budibase.
How to build a workflow app in 6 steps
Finally, let’s wrap up by placing everything that we’ve learned so far into a repeatable framework for building workflow applications.
Follow these steps to create solutions to streamline your internal processes:
- Audit workflows - Determining the constituent tasks that make up a workflow and the logic that governs these.
- Define a new workflow model - Removing any extraneous steps to ensure that our theoretical workflow is as efficient as possible.
- Identify automation opportunities - Determining which tasks can be automated and which will still require human intervention.
- Design optimal user experiences - Figuring out the most efficient way to carry out remaining manual actions.
- Testing and deployment - Ensuring that our workflow application functions as intended and rolling it out to real-world users.
- Performance monitoring and continuous improvement - Monitoring the success of our new tool and seeking out new opportunities for further improvements.
Check out our ultimate guide to internal processes to learn more.