Creating Tasks Manually
Most work orders in a mature fleet are created by the rule engine, but manual creation is still the right answer for ad-hoc work: a customer call about a parked-and-leaking moped, a planned modification, a one-time inspection. This article covers the three manual paths.
From the Kanban board
This is the fastest path and the one your ops team will use 90% of the time.
Click New Task
Top right of /dashboard/tasks.
Pick a vehicle
Type a vehicle number into the autocomplete. The form pre-fills the vehicle's subaccount, its last known GPS location, and its current battery level for context.
Pick a type
The 14 task types are: scheduled_maintenance, repair, deploy, retrieve, charge_swap, battery_swap, rebalance, lost_and_found, inspection, cleaning, parts_replacement, software_update, inspection_failed_followup, vendor_dispatch. Pick the closest match.
Pick a priority
low, medium, high, or critical. SLA due time is computed from your subaccount's SLA config — see SLA and Performance.
Write a title and description
Title should fit on a card (under 60 chars). Description is for the tech — include part numbers, observations, and any photos that should be referenced.
Assign (optional)
Skip this to let a nearby tech claim the task from the operator-app. Pick a name if you want to push it directly.
Create
The task lands on the board. If priority is high or critical, the vehicle auto-flips to maintenance and disappears from the rider app within seconds.
From a vehicle detail page
If you're already looking at a vehicle's history, it's faster to create the task in context:
- Open the vehicle at
/dashboard/vehicles/[id] - Scroll to the Open Tasks card on the right
- Click + New Task
- The dialog opens with vehicle pre-selected — fill in type, priority, title, description, and create
The vehicle detail page also surfaces every closed task against the machine in the Maintenance History section, so you can confirm a particular fault is recurring before opening another work order.
From the API
For integrations and scripts, post to /api/tasks:
POST /api/tasks
Content-Type: application/json
{
"vehicle_uuid": "uuid-here",
"task_type": "repair",
"priority": "high",
"title": "Front brake cable replacement",
"description": "Reported by rider — cable slipping. Replace cable + housing.",
"assignee_id": "team-member-uuid-or-null"
}
The route enforces the one open task of the same type per vehicle rule. If a repair task is already open against the vehicle, the response is 200 with skipped_duplicate: true rather than 201. This prevents rule-loop and integration-bug duplicates.
What happens after create
Three things fire immediately:
- SLA clock starts.
sla_due_atis written based on your priority config. - Vehicle status check. If priority is
highorcritical, a DB trigger flipsvehicles.statustomaintenance— unless the vehicle isin_use(a ride is active), in which case the flip waits for the ride to end. - Notification fan-out. If the task is assigned, the assignee gets an Expo push. If the priority is
critical, theops_managerfor the subaccount also gets a push and a Slack message.
What you cannot do manually
A few rules to keep the data clean:
- You cannot create a task without a
vehicle_uuid. Non-vehicle assets (charging cabinets, batteries on the shelf) are out of scope until the CMMS expansion ships. - You cannot create a duplicate task of the same
task_typeagainst the same vehicle. Close the first one or pick a different type. - You cannot create a task for a vehicle in another subaccount. RLS blocks it server-side.
Don't create maintenance tasks against deleted vehicles
If a vehicle is soft-deleted, the API will return 404. If you need to track a retired vehicle's final repair, do it before deletion.