AppFolio to Workforce Scheduling: How We Automated Work Order Assignment with Workato

A resident reports a leaking water heater at eight in the morning. Somewhere across San Diego County there is a plumber rated four out of five, with an open window at eleven, and a van already parked at a property two blocks away.

Finding that person used to be a judgment call. Someone had to know who was skilled in what, who was already booked, who was closest, and how long the job would actually take. Then they had to make the same call again for the next work order, and the one after that, across 31 properties and roughly 60 workers, every working day.

MC Properties has run property management in San Diego County for 30 years. Their portfolio spans 6-unit buildings to 150-unit communities, with floorplans from roughly 300 square foot studios to 1,300 square foot four-bedroom units. They run AppFolio for property and work order management and a separate workforce scheduling platform for maintenance technicians and vendor labor. Both are strong systems. Neither knew the other existed.

Twenty20 Systems connected them.

Short overview:

We built two connected Workato automations that take a work order from the moment it is raised in AppFolio to a scheduled, notified, correctly skilled worker in the scheduling platform, then keep both systems in sync in both directions. A centralized error-handling workflow catches failures across the build and routes them to the appropriate owner. Worker assignment is now consistent and defensible, distance calculation costs dropped after a paid API was replaced, and scheduling conflicts fell.

 

Two automations, one connected maintenance operation

The engagement, delivered as the AppFolio to Workforce Automation project, produced three things that run as one:

Automation 1, work order intake to schedule. A new or updated work order in AppFolio triggers the flow. The system classifies its urgency, estimates how long the job will take, ranks the available workers, picks one, and creates or updates the shift in the scheduling platform.

Automation 2, worker job overrun handling. When a job runs longer than estimated, the system detects it from clock events, decides whether the overrun matters, and reschedules the rest of that worker's day rather than letting the delay cascade.

A dedicated error-handling project, AOF. A Workato project of exactly two recipes. Every recipe in both automations calls it when something fails, so no failure is silent and no failure lands on the wrong desk.

 

The point where 31 properties outgrow manual scheduling

Two best-in-class systems running side by side with nothing between them is a normal starting point, not a failure of planning. The cost of the gap only becomes visible at volume, and it shows up in six specific places.

Assignment had no defined order of operations. Skill, rating, availability, and travel distance all matter, but without a fixed sequence every dispatcher weighs them slightly differently. That makes the outcome hard to explain to an owner and impossible to improve, because there is no baseline to improve against.

Urgency and volume needed different treatment. Emergency work orders cannot queue behind routine ones. Daily assignment limits and rollover of unassigned work needed to be enforced consistently rather than remembered.

Matching people across two systems is harder than it sounds. Worker and vendor names drift, records change on both platforms, and a mismatch means the wrong technician or no technician.

Distance calculation was priced out of the design. Early work used a paid, zip-code-based distance API. At the query volume this portfolio generates, that cost made distance a luxury rather than a routine input.

Failures had nowhere to go. Integration points between two external platforms fail occasionally by nature. Without a central place to catch and classify those failures, they surface later as a missed appointment rather than sooner as an alert.

One long job broke the rest of the day. When a work job ran past its estimate, nothing adjusted the shifts behind it. A single overrun turned into late or missed appointments for every job scheduled after it, and the first person to notice was usually the resident.

Read together, those are not integration problems. They are the reason a maintenance operation runs at the pace of whoever is coordinating it that day.

 

Inside the logic that does the deciding

The build is deliberately unremarkable to operate. The intelligence sits in the sequence, not in the interface.

Deciding who gets the job, in a fixed order

An AppFolio Database API webhook fires on every new or updated work order, with duplicate update events filtered out through a dedicated lookup table so a single change is never processed twice. Each work order is classified as emergency or normal, and emergency requests move ahead of the standard queue.

The work order is then enriched with property, unit, and floorplan detail from AppFolio's Reports API, and given a duration estimate from a reference table keyed by property, floorplan, square footage, and task category. That table is the quiet centrepiece of the build. It carries full unit turns broken down room by room, where a mid-size two-bed, two-bath unit runs roughly two person-days. It carries individual repairs, where a garbage disposal replacement sits well under an hour and a toilet replacement around ninety minutes. It carries multi-phase rehabs split into rough-in and finishing work across many person-days on larger units.

A realistic estimate is what makes everything downstream possible. Schedule a two-day turn as a two-hour job and no amount of clever assignment logic saves the day.

Workers are then ranked by skill match and rating first, across trades including electrical, plumbing, painting, landscaping, and waterproofing, each rated on a one to five scale. Availability is validated through a five-step fallback: skill-matched workers at the right location, then skill-matched workers anywhere, then maintenance-team workers at the right location, then maintenance-team workers anywhere, and finally the property's roster of designated onsite maintenance workers. Properties are often clustered and share a pool of onsite workers, so that last tier reflects how the portfolio actually operates rather than an idealised org chart.

Only when several qualified candidates remain does distance enter the decision, calculated through the OSRM Routing API with addresses geocoded through OpenStreetMap Nominatim. That ordering is the point: the best-rated qualified worker wins, and proximity settles a tie. It also solved the cost problem, because open routing services replaced the paid zip-code API and made distance affordable to use at scale.

The shift is then created or updated in the scheduling platform, and updates flow back to AppFolio automatically. Four lookup tables, covering task durations, worker skills and ratings, onsite maintenance workers, and webhook deduplication, act as the lightweight system of record between the two platforms. A custom AppFolio connector and supporting recipes keep worker and vendor matching reliable, including cleaning up source data where skill ratings had occasionally been entered as text or dates instead of numbers.

When a job runs longer than estimated

A webhook on clock events tells the system when a worker job has exceeded its estimated duration. The overrun is measured against a configurable buffer, with different buffer rules for jobs at the same property versus a different one. If the overrun clears the buffer, the worker's remaining shifts for the day are extended or rescheduled automatically and the worker is notified by email.

Updated shift times and job status then flow back into both the scheduling platform and the linked AppFolio work order, so labor hours and job records stay accurate without anyone retyping them.

This is the part of the build that changes a resident's experience most directly. The day repairs itself while it is still in progress, instead of being reconstructed the next morning.

Every failure gets a severity and an owner

AOF is two recipes and does one job well. Any recipe in either automation that catches an error calls the Master Orchestrator asynchronously. It looks up the error code in a global error code table to establish severity and whether recovery is needed, checks a notification routing table to establish who should hear about it, and hands off to a notification recipe that emails that person.

Whenever a schedule is created, updated, extended, or rescheduled, the assigned worker is notified through both the scheduling platform's mobile app and email, so technicians stay current without anyone chasing them.

 

The operation MC Properties runs today

• Consistent, defensible worker assignment. Skill-and-rating-first matching now applies automatically to every new or updated work order, replacing manual technician matching.
• Lower distance-calculation costs. Replacing the paid, zip-code-based distance API with OpenStreetMap and OSRM meaningfully reduced the per-lookup cost at scale.
• Fewer scheduling conflicts. Business day, holiday, time zone, and buffer-time rules apply automatically across both same-property and different-property jobs.
• Better handling of urgent and high-volume work. Daily limits, rollover, and dedicated emergency logic keep urgent requests moving without overloading a single worker.
• Higher system reliability. Every failure across both automations is classified and routed to the right person, which reduces silent failures and shortens escalation.

 

The pattern behind the project

The situation MC Properties started from is not unusual. Property management and field service operations routinely run a strong core platform alongside a separate scheduling or dispatch tool, with a person in the middle acting as the integration layer.

That arrangement works until volume, urgency, or headcount growth makes it the constraint. The fix is rarely a new platform. It is a governed layer between the platforms you already trust, carrying the assignment logic, the business rules, and the error handling that no single application was built to own.

Twenty20 Systems is a Workato Platinum Partner and Workato's North America Partner of the Year. We build automations like this one, integrate the systems already running your business, and support them afterwards under managed service.

If your work orders, dispatch, or field scheduling still depend on someone knowing who is free and who is closest, that is a process worth automating before it becomes a hiring decision.