Work Orders
Mapped can integrate with your CMMS (Computerized Maintenance Management System), bringing together Work Orders, Service Requests, assets and locations.
Work Orders are the record of work being tracked and carried out in your facilities. They capture the job itself, along with operational details like status, priority, dates, and the asset or place it relates to. Service Requests are the initial ask for work to be done, representing a reported need, issue, or task, like a maintenance concern or problem report from a user. These can work together in a CMMS to initiate intake and execute the job required.
The Work Order and Service Request models include fields like jobType, jobStatus, jobPriority, dateCreated, and dateUpdated, and can relate that work back to Buildings, Spaces, Things, or Zones. The entire data model is available in our GraphQL API.
With Mapped, you can sync asset and Work Order data across systems:
- Automatically sync assets, locations, and work orders between platforms
- Maintain data consistency across systems with real-time updates
- Enable smarter insights by linking maintenance data to spatial and asset hierarchies
Whether you’re integrating a CMMS like AiM Asset Management or streamlining operations with Willow, we’ve mapped out how to connect the dots.
Use Case: AiM & Willow Ticket
Key Components
- AiM Asset Management Source: Pulls asset, location, and work order data via API
- Mapped: Normalizes data and maintains relationships (e.g., assets ↔ spaces)
- Willow Ticket Destination: Delivers enriched work orders as Tickets in Willow for unified tracking
How it works
- Assets & Locations: Synced on-demand or scheduled, preserving hierarchies (campus → building → floor → room)
- Work Orders: Automatically polled from AiM and pushed to Willow as Tickets with full context (asset, location, priority)
- Reporting & Analytics: Unified data for maintenance trends, asset health, and operational efficiency
Outcomes
- Single source of truth: AiM remains the system of record while Willow gains full visibility
- Reduced manual work: No duplicate data entry; changes propagate automatically
- Actionable insights: Correlate work orders with IoT data, space usage, and asset performance
Example Queries
View Work Orders by Name
You can query Work Orders in GraphQL if you know part of the name of the Work Order using the contains filter.
{
workOrders(filter: {name: {contains: "Smith 6789 VAV"}}) {
id
name
exactType
dateCreated
description
jobType
jobPriority
jobStatus
summary
sector
mappingKey
identities {
... on Identity {
__typename
value
}
}
}
}
Related Entities
The relatesTo GraphQL endpoint ties entities enriched by multiple sources to Work Orders. A Work Order can be related to a Building, SubBuilding, Floor, Space, Zone or Thing.
The below query filters by the Work Order Mapped Id. Note that each related entity in this example has ExternalIdentity values from both Nuvolo and Willow Ticket.
{
workOrders(filter:{id:{eq:"CLSAb3GmR1QkWfZx8YuN2cTj4"}}) {
id
name
exactType
mappingKey
summary
identities {
...on ExternalIdentity {
__typename
value
}
}
relatesTo {
__typename
...on Building {
id
name
exactType
identities {
...on ExternalIdentity {
__typename
value
}
}
}
...on SubBuilding {
id
name
exactType
identities {
...on ExternalIdentity {
__typename
value
}
}
}
...on Zone {
id
name
exactType
identities {
...on ExternalIdentity {
__typename
value
}
}
}
...on Floor {
id
name
exactType
identities {
...on ExternalIdentity {
__typename
value
}
}
}
...on Space {
id
name
exactType
identities {
...on ExternalIdentity {
__typename
value
}
}
}
...on Thing {
id
name
exactType
identities {
...on ExternalIdentity {
__typename
value
}
}
}
}
}
}
As a shortcut, use _typename to quickly check which entity types are included in the relatesTo clause.
{
workOrders(filter:{id:{eq:"CLSAb3GmR1QkWfZx8YuN2cTj4"}}) {
id
name
exactType
relatesTo {
__typename
}
}
}
View Work Orders by date
You can use the operators eq (equals), gt (greater than), gte (greater than or equal to), lt (less than), and lte (less than or equal to) to filter Work Orders by the date they were created or updated.
{
workOrders(filter: {dateUpdated: {gte: "2025-07-30"}}) {
id
name
exactType
jobType
jobStatus
jobPriority
dateCreated
dateUpdated
relatesTo {
__typename
... on Building {
id
name
}
... on Space {
id
name
}
... on Thing {
id
name
exactType
}
... on Zone {
id
name
}
}
}
}
Combine time filter operators to find work orders within a date range:
{
workOrders(filter: {dateUpdated: {gte: "2025-07-28"}, and: {dateUpdated: {lt: "2025-07-30"}}}) {
id
name
exactType
jobType
jobStatus
jobPriority
dateCreated
dateUpdated
relatesTo {
__typename
... on Building {
id
name
}
... on Space {
id
name
}
... on Thing {
id
name
exactType
}
... on Zone {
id
name
}
}
}
}
You could even combine name and date filters:
(filter: {name: {contains: "Smith 6789 VAV"}, and:{dateCreated:{gte:"2026-05-29T04:10"}}})
View Work Orders external identities
Mapped links Buildings, Spaces, Things and Zones across CMMS and asset management systems through the use of External Identities. The mappingKey tells you which CMMS source originated the Work Order, while the External Identities confirm which CMMS the Work Order has synced with.
{
workOrders(filter: {id: {eq: "CLSBO8n9MwTaKwQ6Cusj9Gw5X"}}) {
id
name
exactType
mappingKey
jobType
jobStatus
jobPriority
dateCreated
dateUpdated
identities {
... on External Identity {
value
}
relatesTo {
... on Building {
id
name
exactType
identities {
... on External Identity {
value
}
}
}
... on Space {
id
name
exactType
identities {
... on External Identity {
value
}
}
}
... on Thing {
id
name
exactType
identities {
... on External Identity {
value
}
}
}
... on Zone {
id
name
exactType
identities {
... on External Identity {
value
}
}
}
}
}
}
The example Work Order above originated in AiM Asset Management Source, given its mappingKey:
"mappingKey": "msrc://CONDKzB2cDFx4s8AE68LPDruQ@aim-asset-management-source/workorders/zz22435502"
The identities reveal the Work Order has synced with Willow Ticket Destination:
"identities":[
{
"value": "urn:aim-asset-management-source:workorder:id:zz22435502""
},
{
"value": "urn:willowinc:ticket:id:374e37ee-e352-4944-adad-c494a2821867"
}
]
Service Requests
Service Requests are a separate entity from Work Orders, so they require a different GraphQL query. The example query below captures the properties and related entities of a specific Service Request.
Note: The same optional filters we've seen for Work Orders above can also be used for Service Requests.
{
serviceRequests(filter: {id: {eq: "CLSRq7Xw2ZkLmN8p9T4sV6bH3"}}) {
id
name
exactType
summary
description
requestStatus
jobPriority
sector
isReportedBy {
name
}
isResponsibilityOf {
... on PeopleGroup {
name
}
}
identities {
... on ExternalIdentity {
__typename
value
}
}
relatesTo {
...on Building {
id
name
exactType
identities {
...on ExternalIdentity {
__typename
value
}
}
}
...on Space {
id
name
exactType
identities {
...on ExternalIdentity {
__typename
value
}
}
}
}
}
}
The table below includes some notable properties and indicates whether they're available for Work Orders or Service Requests or both. For extensive documentation, review our API Reference for Work Orders and Service Requests.
| Mapped Entity Property | Work Order | Service Request |
|---|---|---|
| name | ✅ | ✅ |
| summary | ✅ | ✅ |
| description | ✅ | ✅ |
| resolutionDescription | ✅ | ❌ |
| problemDescription | ✅ | ❌ |
| subject | ✅ | ❌ |
| referenceUrl | ✅ | ✅ |
| jobStatus | ✅ | ❌ |
| jobPriority | ✅ | ✅ |
| jobType | ✅ | ❌ |
| requestStatus | ❌ | ✅ |
| sector | ✅ | ✅ |
| dateCreated | ✅ | ✅ |
| externalDateCreated | ✅ | ❌ |
| dateUpdated | ✅ | ✅ |
| externalDateUpdated | ✅ | ❌ |
| dueDate | ✅ | ❌ |
| dateClosed | ✅ | ❌ |
| dateCompleted | ✅ | ❌ |
| hasAssignee | ✅ | ✅ |
| isResponsibilityOf | ❌ | ✅ |