A resident request arrives with a unit number and a sentence. Someone has to decide whether the lease makes it the resident's problem or yours, which trade it needs, and whether a vendor or your own technician takes it. Request Routing reads the request as it lands: a resident request or to-do request in Buildium, a service request in Facilio, a work request in MaintainX, a request in UpKeep, or a ticket in Freshdesk or Jira Service Management. It reads the lease and unit behind it, and the vendors and specialties you keep in Corrigo Enterprise or your CMMS.
It then proposes one work order with a trade and a priority, and one assignee. You approve, change the assignee, or send it back. It never dispatches on its own.
This is a reference listing. It documents what Fibric would read from Request Routing and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.
Inputs
Resident requests and to-do requests in Buildium, and work requests in MaintainX and UpKeep, as NEW_WORK_REQUEST and REQUEST_CREATED events arrive
Service requests in Facilio with their urgency picklist and attachments, and requests already open on the same unit or space
Tickets from a resident inbox in Freshdesk or Jira Service Management, with the requester, request type, and any SLA already running
The lease and unit behind each request: Buildium leases, Entrata getLeaseDetails, or AppFolio occupancies, with the responsibility fields the lease record carries
Vendors and their specialties in Corrigo Enterprise, and vendor contacts in MaintainX, Buildium, or Facilio, for the trades you route outside
Open work orders on the same unit, so a second request about the same fault attaches to the first rather than opening another
Proposed actions
Target capability: propose a work order with trade and priority, through Corrigo WoCreateCommand with a Specialty, MaintainX POST /workorders, or Facilio POST /workorder
Target capability: propose an assignee, vendor or in-house technician, through Corrigo Assign and SendWorkOrderCommand, an UpKeep worker or team assignment, or a Limble task update
Target capability: propose approving or declining the request in UpKeep or Limble CMMS, with the lease clause or reason shown
Target capability: propose a responsibility note on the Buildium lease or request, or a comment on the Facilio service request, stating who bears the cost
Target capability: propose a reply to the resident through Freshdesk or Jira Service Management naming the trade, the assignee, and the next step
Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.
What you can build
Route a Buildium request to the right trade
A resident request lands in Buildium. The operator reads the lease and unit, matches the fault to a specialty, and proposes a Corrigo work order assigned to the plumbing vendor, with SendWorkOrderCommand queued for your approval.
A resident writes to the Freshdesk inbox. The operator proposes a MaintainX work order with priority set, and a Freshdesk reply naming the technician and the visit window. Approve both or edit either.
An Entrata lease record makes drain blockages the resident's cost. The operator proposes approving the UpKeep request, assigning your own technician, and a note on the lease recording the charge basis.
A second Facilio service request names a fault already under an open work order. The operator proposes a comment on the existing order and a reply to the resident, instead of a new order.
A property connector holding leases and units: Buildium, Entrata, or AppFolio Property Manager
A source of requests: the property system's own request records, a CMMS request queue, or a support desk such as Freshdesk or Jira Service Management
A CMMS or work order platform for the proposed work order and assignment: Corrigo Enterprise, MaintainX, UpKeep, Limble CMMS, or Facilio
Your routing rules: which trades go to a vendor, which stay in-house, and which request types a person must read first
Authentication
It reads requests, leases, and vendors through the property, support, and maintenance connectors you attach, each with the scopes you grant, and holds no login of its own.
Limits
It reads responsibility from the lease fields and notes your property system stores. A clause that lives only in a signed PDF is not read.
It routes to vendors already on your list. It signs nothing and invites no new vendor.
Habitability, safety, and legal questions go to a person as a request to read, with no trade or assignee proposed.
It closes no request and marks nothing complete. Completion stays with the technician and the CMMS.
Access and pricing
Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.
One proposal per request: the work order text, its trade and priority, the assignee, and any reply to the resident. The proposal shows the request, the lease clause it relied on, and the open orders it checked. You approve, change the assignee, or send it back for a person to read.
What does it leave behind for each request?
A receipt: the request id, the lease and unit matched, the responsibility decision and its basis, the work order id created, who it was assigned to, who approved it, and how to reverse the assignment.
Will it ever send a vendor without asking?
No. Assignment and the SendWorkOrderCommand that notifies a vendor both wait for your approval. If no rule matches, or the request mentions safety or a legal claim, it proposes nothing and asks a person to read it.
Ask about Request Routing
Ask about the capabilities and requirements in this listing.
This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy