Case study

Designing a Configurable Process Engine

This is a case study of the Process Engine project for Rex Property Management (Rex PM). The Process Engine is a workflow configuration tool that enables agencies to implement their own processes into the platform — and supporting users to efficiently manage and progress their day-to-day tasks.

Team: Product Designer (myself), Product Manager, CTO as technical advisor.

A screenshot from a property management application showing a move in task with a checklist of subtasks to be completed

A process checklist on a move out task


The Rex PM platform enables Property Managers to a simple experience to manage their entire property portfolio. At it’s 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

Tasks help agents to keep track of jobs to be done, and surface what they need to do today — 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 that request is at and what needs to be done next to progress the task. Agencies are process-driven, and our system is lacking in a method to support these processes.

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 goal of this was not to come up with a one-size-fits-all process, but to get a full 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 many user journeys 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 using 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 individual requirements.

The Goal

Design a new task process architecture that:

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 for an enterprise customer that was highly configurable and deeply integrated into the CRM (it could even execute Javascript in an isolated environment). Building a workflow in this tool was extremely complex — it was built for the sole use of an enterprise customer with their own IT team who could write and implement workflows to essentially create their own bespoke features in our platform.

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

Requirements Definition

From the set of process maps, I was able to define an initial set of functional requirements that our process engine would need in order to meet the market requirements. This set could also be prioritised based on how often each requirement came up.

The framework of a task is the task object itself, with a checklist of subtasks which define the process for completion of the task (as well as other related data). The functional requirements for the process engine fit around the subtasks and the configuration of the process defining those subtasks. For example:

Design Approach

This project had two key points of interface:

  1. The task itself where users (mostly agents or administrators) would be working through the defined process by completing subtasks
  2. The configuration of the process where users (mostly high level administrators, managers, or directors) could modify or create the series of subtasks and behaviours

There are plenty of workflow configuration tools out there, and so I spent some time gathering examples to learn from. This gave me some different approaches to try out, but ultimately the solution would also need to fit into the existing patterns and design system of the Rex PM platform.

My approach was to wireframe out both sides, building out the framework and testing it by applying it to different process maps. Technical input was also gathered from developers to ensure feasibility. This iteration continued until I had a solution that could achieve the identified requirements as well as the project goals.

Testing and Validation

A high-fidelity interactive prototype was built focusing on the configuration and completion of several key processes. Through further calls with agencies the new process engine was tested — both the interface as well as the core functionality was validated. Feedback was synthesised during this process and further iterations were made to the prototype.

Implementation and Next Steps

At time of writing, this project is at the early implementation stage. With a validated design for the Process Engine, the next step is to work with the technical team to plan an approach for incremental release.

A screenshot from a property management application showing a move in task with a checklist of subtasks to be completed

Processes are presented as a checklist of subtasks on a task

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

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

Processes can be a simple checklist, or include complex configurations involving branching paths and triggered actions

A dialog showing the configuration of a subtaskA dialog showing the configuration of a triggered action

Subtasks can be due on dates relative to the task, and have predefined action shortcuts that the user can execute quickly. Or triggered actions can be used to completely automate the subtask.