Willow Ticket Destination

The Willow Ticket Destination connector synchronizes work order and service request data from the Mapped graph to Willow's ticket management system. This connector enables bidirectional ticket management by pushing work orders created in other systems through Mapped into Willow, maintaining consistent ticket data across your facility management ecosystem.

Use Cases

• Centralized Ticket Management: Synchronize work orders from multiple source systems into Willow as the centralized ticketing platform
• Cross-System Integration: Enable work orders created in systems like Nuvolo or WFS to flow into Willow while preserving relationships to assets and locations
• Unified Workflow Orchestration: Maintain consistent ticket status, assignments, and metadata across integrated facility management systems

Configuration

Auth Requirements

To configure authentication, you'll need:

• Base URL: Your Willow instance URL (e.g., https://your-instance.willowinc.com)
• Client ID: OAuth client identifier for API access
• Client Secret: OAuth client secret for API access

The connector uses OAuth2 client credentials flow to authenticate with Willow's API. Access tokens are automatically managed and refreshed as needed.

Place Mappings

Required Mappings

• Selected Sites: Choose which Willow sites to synchronize tickets to. Work orders must relate to buildings/spaces that exist within the selected sites.

The connector maps work orders to Willow tickets based on their relatesTo relationships in the Mapped graph. Work orders can relate to:

• Buildings (mapped to Willow site twins)
• Floors (mapped to Willow space twins)
• Spaces (mapped to Willow space twins)
• Assets/Things (mapped to Willow asset twins)

Enumerations

Enumeration mapping translates work order field values between Mapped and Willow's terminology. If a value is not mapped, it may not sync to Willow Ticket:

• Job Status: Maps work order status values (e.g., "Open", "In Progress", "Closed")
• Job Sub Status: Maps sub-status values for tickets on hold or requiring additional context
• Job Priority: Maps priority levels between systems (e.g., "Low", "Medium", "High", "Urgent")
• Job Type: Maps work order type classifications
• Sector: Maps request type or service area categories
• Services Needed: Maps problem description or service categories

Sync enums

On the Mapping tab, turn on Sync Enums (Category, Job Type, Service Needed, Sub-status) to have the connector create and map these values for you, instead of mapping them by hand: Sector (category), Job Type, Job Sub Status and Services Needed. It reads the values from your work orders and service requests, creates any that Willow does not have, and keeps their Willow IDs. The mapping tables for these four are hidden once it is on.

Job Status and Job Priority are not covered. Willow's lists are fixed and the connector cannot add to them, so map each CMMS status and priority to a Willow value. A work order with an empty status keeps its current status in Willow. A status that is not empty but has no mapping stops the whole create or update for that ticket.

Enum Mapping Toggle: You can disable enumeration mapping to pass values through directly without translation. When disabled, Status is converted to Willow's format (for example In Progress becomes InProgress) and is rejected unless it is a valid Willow status ID. Priority and the other enums that do not match are sent as empty instead.

Mapped Concepts

This connector reads existing work order entities from the Mapped graph and synchronizes them to Willow. It does not create new entities in the graph but does maintain identity relationships:

Mapped Concept	Purpose	Description
WorkOrder	Work orders synchronized to Willow	Entity Type WORK_ORDER
ExternalIdentity	Links Mapped work orders to Willow ticket IDs	Endpoint for storing identity values from external sources

Identity Management: When a work order is successfully created in Willow, the connector adds an ExternalIdentity to the work order in Mapped with the format urn:willowinc:ticket:id:{ticketId}. This identity enables the connector to update existing Willow tickets rather than creating duplicates. Read more about Identities.

Syncing

Work Order Requirements: For a work order to be synced from the Mapped Graph to Willow Ticket, the following is required:

• The work order must have a jobStatus field value. A null value will fail to sync.
• It must relate to a Building, SubBuilding, Floor, Space, Zone, or Thing via relatesTo - with a Willow twin Id as an ExternalIdentity value
• It must have a location that resolves to one of the configured Buildings under Selected Sites. One of the selected Buildings or one of its child places must be included in relatesTo.
• At least one of the related entities must have as an ExternalIdentity value either a Willow twinId or spaceTwinId.
• It must have both the CMMS work order ID and work order number as ExternalIdentity values (urn:<vendor>:workorder:id: and urn:<vendor>:workorder:number:). A service request needs urn:<vendor>:request:id: and urn:<vendor>:request:number:. Without both, the ticket is not written to Willow. The ID becomes the ticket's externalId and the number is stored in its workOrderNumber custom property. Some CMMS destinations write only the ID when they create the record, and the number arrives on the next poll of the CMMS Source. Review CMMS Pass-through Enum Guide for which connectors write which.

Sample Code

List Work Orders with ExternalIdentity values

{
  workOrders(filter: { connectedDataSourceId: { eq: "your-connector-Id" } }) {
    id
    mappingKey
    summary
    description
    jobStatus
    jobPriority
    jobType
    sector
    referenceUrl
    problemDescription
    resolutionDescription
    isReportedBy {
      name
      emails { address }
    }
    isCreatedBy {
      name
    }
    hasAssignee {
      name
      emails { address }
    }
    hasAssignedGroup {
      name
      hasMember { name }
    }
    relatesTo {
      ... on Building { id name }
      ... on Space { id name exactType }
      ... on Thing { id name exactType }
    }
    identities {
      ...on ExternalIdentity { value scope scopeId }
    }
  }
}