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
              }
            }
          }
        }
      }
    }

Work Order / Service Request Properties

The table below describes some notable properties and indicates whether they're available for Work Orders, Service Requests or both. Dates and statuses marked as external come from the source system (your CMMS). For extensive documentation, review our API Reference for Work Orders and Service Requests.

Property	Work Order	Service Request	Description
dateClosed	✅	❌	When the work order was closed.
dateCompleted	✅	❌	When the work itself was finished. This can differ from dateClosed, because a work order may be closed after the work is done.
dateCreated	✅	✅	When Mapped first created the record, which is when it was first synced. For when the work order was actually raised, use externalDateCreated.
dateUpdated	✅	✅	When Mapped last updated the record, which can be later than the change in the source system.
description	✅	✅	The longer free-text description of the work or request, as entered in the source system.
dueDate	✅	❌	When the work is due to be completed.
externalDateCreated	✅	❌	When the record was created in the source system (your CMMS). This is usually the date you want for reporting, because dateCreated reflects the sync, not the original work.
externalDateUpdated	✅	❌	When the record was last changed in the source system (your CMMS).
hasAssignedGroup.PeopleGroup.name	✅	❌	The name of the group or team the work order is assigned to.
hasAssignee.Person.email	✅	✅	The email address of the person the work or request is assigned to.
hasAssignee.Person.name	✅	✅	The name of the person the work or request is assigned to.
isClosedBy.Person.name	✅	❌	The name of the person who closed the work order.
isCreatedBy.Person.name	✅	❌	The name of the person who created the work order in the source system.
isReportedBy.Person.email	✅	✅	The email address of the person who reported the issue or raised the request.
isReportedBy.Person.name	✅	✅	The name of the person who reported the issue or raised the request.
isResponsibilityOf	❌	✅	The person, team or other agent responsible for resolving the service request.
jobPriority	✅	✅	How urgent the work is, as defined by the source system (for example 3, 5, Normal or high).
jobStatus	✅	❌	Where the work order is in its lifecycle, for example Draft, Ready for Work or Closed Complete. Values come from the source system and are not normalized.
jobType	✅	❌	The kind of work, for example Corrective Maintenance, Planned Maintenance or Rounds.
name	✅	✅	The identifier or title of the record in the source system, such as a work order number (for example FWKD0035862). Use it to find records with the contains filter.
problemDescription	✅	❌	The problem or fault that the work order was raised to address.
referenceUrl	✅	✅	A link back to the record in the source system, so you can open the original.
requestStatus	❌	✅	Where the service request is in its lifecycle, for example scheduled. The service request equivalent of jobStatus.
resolutionDescription	✅	❌	What was done to resolve the work, as recorded by the technician when closing it out.
sector	✅	✅	The trade, discipline or area of operations the work belongs to, for example HVAC.
subject	✅	❌	The subject or title line of the work order in the source system.
summary	✅	✅	A short one-line description of the work or request, such as "HVAC Alert".