Designing a Configurable Process Engine

A workflow tool supporting users to efficiently configure, manage, and progress their day-to-day tasks.

Cody Lindsay Gordon
8 min readSep 24


The Process Engine is a workflow configuration tool that enables agencies to implement their own processes into the Rex PM platform — supporting users to efficiently manage and progress their day-to-day tasks in line with their unique business processes.

This is a case study of the Process Engine project for Rex Property Management where I was the sole designer working on this project.

An impressionist painting of two hands working on a laptop with UI elements floating out of the screen


The Rex PM platform enables Property Managers to effectively manage their entire property portfolio. At its core is a task model which is used to drive action and improve the day-to-day workflows of users — ensuring tasks are logged and surfaced at the correct times. Tasks cover a range of core activities for a property manager — for example; routine inspections, maintenance requests, compliance checks, lease reviews, and more.

The Problem

We had been getting a lot of customer feedback on the task model. Tasks were helping agents keep track of jobs to be done and surface what they need to focus on — but only at a high level. For example; an agent can ascertain that a maintenance request is in progress, but it’s not clear at what stage the task is at and what needs to be done next to progress it.

Research and Discovery

The primary research goal was to learn more about these agency processes. I ran discovery sessions with agencies of varying sizes and structures and walked through their internal processes for various tasks — what happened at each stage of progressing a task and what roles within the agency were involved.

From this I was able to build out a set of user journey maps covering different tasks for a broad range of agencies. The purpose of this was not to come up with a one-size-fits-all process, but to get a complete understanding of the varying ways agencies operate.

A section of a user journey map showing the start of a change of sharer process for an enterprise agency
A sample of one of the user journey maps synthesised for a task process

Insights and Opportunities

The key insight from the research conducted was that agencies are process-driven, and while processes across different agencies are similar at a high level, it’s the low level distinctions that are important — and are often a core part of the brand identity of the agency.

Trying to create a one-size-fits-all process for each type of task would not solve for the entire problem, and may even drive some agencies away from engaging with it. We needed a more flexible approach that could still provide some general processes as a starting point, but give agencies the power to customise them to suit their own business requirements.

Problem Statement

Agencies are process-driven, and it’s important to their brand identity that they can work to their own processes. Property Managers are always busy, and have any number of tasks on the go simultaneously. They need to be able to pick up a task and understand clearly where it is at and what needs to be done next.

The Goal

Design a new task process architecture that:

  • Supports users in managing and progressing their day-to-day tasks
  • Gives a unified experience across all types of tasks
  • Allows small–medium agencies to tweak default processes to suit their unique requirements
  • Allows large–enterprise agencies to implement their own complex processes and business logic

Some History & Learnings

This isn’t the first time we have built a tool like this. In our sales and lettings CRM, I designed an “if-this-then-that” workflow engine that was highly configurable and deeply integrated into the system (it could even execute Javascript in an isolated environment). However, creating a workflow in this tool was overly complex — it was designed as a service for enterprise customers with their own developers, allowing them to implement workflows and essentially create their own bespoke features within our platform.

This time around, I intended to take a different approach and unlock the tool for a broader audience, so I planned upfront to trade off some of the complex features for a more accessible tool that could be used by small and large agencies alike.

An impressionist painting showing a close up of a person typing on a laptop

Design Approach

Understanding the System

I mapped out the existing system to make sure I properly understood the points of interaction between different records and what areas this project would impact. This diagram shows how the existing tasks configuration as well as the tasks themselves will be enhanced by the new process engine.

There are two key points of interface:

  1. The tasks configuration where users (mostly high level administrators, managers, or directors) could create a series of subtasks and other actions to define the process for completing each type of task
  2. The task itself where users (mostly agents or administrators) would be completing subtasks that are defined by the process engine
A system map showing the relationship of tasks with the rest of the system and how different types of users interact with tasks
The process engine upgrades task configuration, which in turn enhances tasks

Requirements Definition

From the process maps created during the research phase, I was able to define a set of functional requirements that our process engine would need in order to meet user expectations. These were prioritised by how often each requirement came up.

Some examples of requirements were:

  • Assigning a subtask to a particular user or role
  • Setting a relative due date on a subtask based on record fields or task creation
  • Collecting input from the user of the outcome of a subtask
  • Branching to different process paths based on outcomes
  • Sending templated messages from subtasks
  • Automations allowing templated messages to send automatically, or updating task status or other record information
  • Uploading documents as part of subtask completion
  • Creating related tasks off a subtask (eg a maintenance task after completing an inspection task)

Process Configuration Design

I started by gathering examples of existing workflow configuration tools to learn from (e.g. Zapier). In general there are two main types of workflow editors; a visual path editor or a flattened nested path editor. I applied both of these approaches to our task model and our functional requirements:

Two different workflow diagrams showing different layout approaches
Two early approaches to configuration — ultimately the workflow-style editor didn’t align with the mental model of a checklist

After some exploration I found that the step-by-step workflow configuration didn’t really align with the mental model of a checklist. For example — subtasks in a checklist can be completed in any order (or left incomplete), but the workflow configuration presents every subtask as if it is a required step in the process. The visual presentation of a workflow also doesn’t align well with the output — a flat checklist.

I took a different approach and instead tried to present each subtask in a way that more closely aligned with the model of a checklist:

A workflow layout that resembles a checklist rather than a set of actions
A process configuration that is closer to the mental model of a checklist

The subtasks had further configuration options based on the functional requirements, allowing them to cater for simple to-do items through to complex automated actions:

Subtasks can be due on dates relative to the task, and have predefined outcomes allowing the process to continue down different paths. Automated actions allow for streamlined communications with templated emails, or can update the task status or related data.

I then tested this framework by using it to build the mapped out processes from earlier in the project. At this stage I sought technical input from the engineering team to gather their feedback and ensure it was feasible to build. It was iterated on until it met the functional requirements as well as the project goals.

A screenshot from a property management application showing the configuration settings for a set of subtasks forming a process
The process configuration tool

Task Interface

On the front end is the task interface where agents and administrators will complete the subtasks defined by the process engine. The approach for this was relatively straightforward — the task record already existed in the system and so this only required the checklist functionality to be upgraded to support the process engine working behind the scenes.

I focused on keeping the experience simple and close to checking off a to-do list—while also making sure information and actions were displayed clearly so the user had contextual cues on when automated actions would happen or when the process might branch down a different path.

A screenshot from a property management application showing a move in task with a checklist of subtasks to be completed
On a task record, processes are presented as a checklist of subtasks
A to do list item being checked off, and a popup appearing to collect further input about the outcome of the task
Subtasks can collect an outcome which determines the branch the process engine will take next
Tasks can be completed on desktop or mobile

Design Validation

These designs went through several rounds of prototype feedback and testing. I built several high-fidelity interactive prototypes focusing on the configuration and completion of several key processes. These were tested across different user groups—for example a typical agent completing a maintenance task vs an administrator configuring a move-out process for their office.

Some gaps were identified (such as different use cases for automated messaging that weren’t anticipated) and the designs were iterated on to address these.

Scoping it Down for an Incremental Release

This is a large project, and it was important that we could ship it in stages to make sure we were on the right track. Based on feedback and the prioritisation of the functional requirements, I hypothesised that we could get a lot of value by starting with a smaller scope that supported automated messaging.

Good communication in an agency is business-critical, and by supporting automated and scheduled messaging in our tasks we would solve for a huge pain point in our system. This would also significantly reduce the scope of the process engine, while still allowing us to build it out in the future.

I reduced the scope of the designs to the minimum requirements to allow for automated messaging, and validated these against a few key processes that were communication heavy (such as rent arrears followup).

This project is currently undergoing a technical spike aimed at releasing automated messaging and a framework for building towards the fully fledged process engine.



Cody Lindsay Gordon

Australian product designer & coder with over a decade of experience in user‑centered design practices →