Skip to main content

Nuvolo Destination

Nuvolo logo

The Nuvolo Destination connector sends Work Orders, and optionally assets, from your Mapped graph into Nuvolo, the facilities and asset management system that runs on ServiceNow.

A typical setup looks like this: Work Orders come into Mapped from another system, such as Willow tickets. This connector notices them and creates matching Work Orders in Nuvolo, so your facilities team can work on them in the tool they already use. When the connector is set to update, later changes in Mapped are sent on to Nuvolo as well.

The connector writes into Nuvolo. It does not read Work Orders out of Nuvolo; that's the job of the separate Nuvolo Source connector.

Use Cases​

  • One queue for technicians. Tickets raised in another system (for example Willow) show up in Nuvolo automatically, with the right type, request type, service and location.
  • Keep asset records in step. Assets known to Mapped can be pushed into Nuvolo's asset table, with their models and manufacturers, whenever you choose to run it.
  • Avoid duplicates and echoes. Every Nuvolo record the connector creates is linked back to its Mapped record, so the same Work Order is never created twice. You can also exclude Work Orders that came from Nuvolo in the first place.

How it works​

Setup happens in the connector's configuration screens. Once you save, the connector runs by itself: it checks for new and changed Work Orders every two minutes. Three jobs can also be started by hand from the connector's Jobs panel.


Config​

Step 1: Connect to Nuvolo (Auth)​

Enter the details of the Nuvolo account the connector should use. Ask your Nuvolo or ServiceNow administrator for these.

FieldRequiredWhere to find it
Base URLAlwaysThe web address of your Nuvolo instance, e.g. https://your-instance.service-now.com.
Auth methodAlwaysOAuth2 (recommended) or Basic.
Username / PasswordAlwaysA Nuvolo user that may read and write Work Orders, and assets if you sync them.
Client ID / Client SecretOAuth2 onlyFrom your ServiceNow administrator, who creates them in ServiceNow's Application Registry.

When you save, the connector tests the credentials straight away. A banner also tells you if the account can't read Nuvolo's table definitions. Setup still works in that case, but some lists further on will offer fewer suggestions.

The Settings section stays locked until credentials have been saved.

Step 2: Settings tab​

The Settings section has three tabs along the top: Settings, Assets and Work Orders. A single Save button next to the tabs saves all three at once. It is only enabled once something has changed.

Connector capabilities​

OptionWhat it does
Publish Work OrdersMain on/off switch for sending Work Orders to Nuvolo. When off, the two-minute sync does nothing.
Publish mode (required)Create only: new Work Orders are created in Nuvolo, but a Work Order Nuvolo already has is never touched again. Create & Update: later changes in Mapped are also sent to the matching Nuvolo Work Order. If both sides changed, Mapped's version wins.
Sync assetsAllows the on-demand Publish Assets job to run. Assets are never synced automatically.
Only update assets created by MappedOff by default. When on, Publish Assets only updates Nuvolo assets this connector created, and never overwrites assets that came from Nuvolo. See below.

Only update assets created by Mapped. Turn this on if you also import Nuvolo assets into Mapped with the Nuvolo Source connector. Otherwise an imported asset could be written back over Nuvolo's own record, changing its name, type or location. With the setting on, an asset is updated only when its Nuvolo record carries the matching Mapped ID in its Correlation ID field. Skipped assets are reported as one warning per publish batch, with a count and a few example IDs, not as one warning per asset.

Assets created before correlation tagging. Assets this connector created before it started filling in the Correlation ID have no tag, so they look like Nuvolo's own assets. With the setting on they are skipped, and they would never get tagged, because only an update tags them. To turn the setting on safely: (1) leave it off, (2) run Publish Assets for the assets this connector created earlier, which tags them, then (3) turn it on. Any asset still untagged after that is treated as Nuvolo's own and skipped. If you do not import assets with Nuvolo Source, you do not need this setting.

Selected Buildings (optional)​

Choose which buildings Work Orders may be sent for. The list shows buildings Mapped already knows from Nuvolo, usually because the Nuvolo Source connector brought them in.

  • Nothing selected (the default): Work Orders for every Nuvolo building in Mapped are sent. A building added to Mapped later is included automatically.
  • Some selected: only Work Orders located in those buildings are sent. The rest are quietly left out.

Source connectors​

Choose which other connectors' Work Orders may be sent to Nuvolo. Unlike the rest of the panel, this list saves as soon as you click a toggle.

  • If you never set it, Work Orders from every source are sent.
  • Recommended: if you also run the Nuvolo Source connector, switch it off here. Otherwise a Work Order that started in Nuvolo can be written back over itself, which can undo a technician's latest edit.

Step 3: Work Orders tab​

This is where you tell the connector where Work Orders go in Nuvolo and how Mapped's information becomes Nuvolo's fields. The connector writes to one Nuvolo Work Order table. The usual one is Corrective Maintenance (x_nuvo_eam_facilities_work_orders).

At the top, the connector reads the table's layout from Nuvolo. The steps below unlock once that finishes. An Import button can also copy a table setup from another Nuvolo connector in your organization, which saves you entering it twice.

The steps, in order:

  1. Field mappings. For each piece of Work Order information in Mapped (name, description, dates, requester, location, related asset and so on), pick the Nuvolo field it goes into. Suggested defaults are filled in where the connector can work them out. Fields that Nuvolo fills in itself, such as the Work Order number, are never offered, because the connector must not overwrite them.

    • The Work Order type must be mapped. Without it no Work Order can be sent.
  2. Enum mappings. Some Nuvolo fields only accept values from a fixed list, such as Status, Work Order Type, Request Type, Service Needed and Sub-status. You only see a tab for each list your field mappings actually use. On each tab, match Mapped's values to Nuvolo's. For each one you can also:

    • turn the mapping off, which leaves the field blank or uses a matching Nuvolo value with the same name,
    • set a default that always applies, or
    • set a fallback that applies only when nothing else matched.

    Status today: the connector currently creates every Work Order in Nuvolo with the status Draft, and it never changes the status afterwards. Your Status mapping is saved, but it does not yet change the status in Nuvolo.

  3. Required fields. Choose which Nuvolo fields must have a value before a Work Order is created. Also choose which location fields count: at least one of them (for example Space or Related Asset) must be filled in. A Work Order missing any of these is held back and reported, rather than created incomplete.

  4. State transitions (read only). Shows Nuvolo's allowed status changes for this table, such as Open → In Progress, and which fields each change needs. This is for reference only and changes nothing.

Passing values through without mapping​

To avoid mapping each value, go to Settings, then the Enum mappings step, and switch each tab (Status, Sub-status, Type, Request Type, Service) to Mapping Disabled. Then save once. The setup is not complete until every tab the table uses has been saved.

The destination then resolves the value in this order: a default value that always applies, then an exact match of the Mapped text against the values in Nuvolo's own choice list (ignoring case, with spaces treated as underscores; approximate names are not matched), then a fallback default (the undefined only option), then nothing. A value that finds no match leaves the field blank and logs an info message.

On the default table, three Nuvolo fields are required to create a Work Order: Work Order Type, Request Type and Service Needed. If mapping is off for one of these and nothing matches, set a default, or the Work Order is held back and reported. Other tables use whatever you choose on the Required fields step.

Status pass-through has no effect today, because the connector creates every Work Order as Draft (see the note above).

Work Order types. By default the connector only sends Corrective Maintenance Work Orders. Work Orders of other types are left out, unless your setup lists those types as allowed for the table.

Step 4: Assets tab (only if Sync assets is on)​

  • Asset Type: match Mapped's asset types to Nuvolo's asset types.
  • Owning Department: choose the Nuvolo department new assets belong to.
  • The Nuvolo tables used for assets, models and manufacturers are fixed and shown for reference.

If Sync assets is off, this tab is hidden and nothing on it is required.

Step 5: Save​

Click Save. If something important is still missing, such as a required field nobody has mapped, a confirmation box lists the problems before saving.

The connector only starts once the setup is complete. The checks are:

  • the credentials are entered,
  • a publish mode is chosen,
  • every enum mapping the table uses is filled in,
  • the Work Order type is mapped,
  • if asset syncing is on, Asset Type and Owning Department are mapped.

Buildings do not have to be selected.


Actions​

The automatic Work Order sync (every 2 minutes)​

Every two minutes the connector does the following:

  1. Checks the setup. If something essential is missing, the run stops early with a clear message in the connector's logs, before any time is spent on data.
  2. Looks for Work Orders. It finds Work Orders in Mapped that are new or changed since the last successful run. The very first run looks back two hours, not across all history; use the backfill to bring in older Work Orders. Only Work Orders from the source connectors you have switched on are requested.
  3. Loads Nuvolo's reference lists. It reads Nuvolo's current types, request types, services and spaces, so values are always matched against what Nuvolo has now. On the very first run it also saves a copy of these lists to the connector, for other integrations that read them (see the Refresh Nuvolo Reference Data job).
  4. Decides what to send. Each Work Order goes through these checks in turn:
    • Wrong table: it belongs to a different Nuvolo Work Order table. Left out.
    • Excluded source: it came from a source connector you switched off. Left out.
    • Already in Nuvolo, mode is Create only: left out.
    • Building not selected: it is located in a building you didn't pick. Left out.
    • Type not allowed: its type isn't one this table accepts, for example not Corrective Maintenance. Left out.
    • No location, or a required field missing: held back and reported (see below).
    • Everything else is created in Nuvolo, or updated if it is already there and the mode is Create & Update. A Work Order with nothing new to send is left alone.
  5. Links the records. Each new Nuvolo Work Order is tagged with its Mapped ID, and the Mapped Work Order is given the Nuvolo ID. That link is how the connector knows next time that the Work Order already exists, so it never creates a duplicate.
  6. Reports a summary: how many Work Orders were created, updated, skipped and rejected.

About rejected Work Orders. A Work Order held back for a missing location or required field is reported once, not every two minutes. It is retried on each run. As soon as someone fixes it in the source system, it goes through on the next run without you doing anything.

If a run fails (for example Nuvolo is unreachable), the connector does not lose its place. The next run picks up from where the last successful one finished, so nothing is skipped.

On-demand jobs​

Start these from the connector's Jobs panel. Each shows a progress bar and keeps a run history. A job does not change where the two-minute sync is up to.

JobWhen to use itWhat you fill in
Backfill WorkordersRe-send Work Orders the automatic sync didn't send, for example ones from before the two-hour first window, or ones fixed after a setup change. It follows exactly the same rules as the automatic sync.Backfill Type: Date Range (Work Orders that changed in a window, default the past week) or Workorder IDs (paste Mapped Work Order IDs, usually starting CLS). Buildings (optional): leave empty to use your Settings selection.
Publish AssetsPush assets from Mapped into Nuvolo, along with their models and manufacturers. It only runs when Sync assets is on; otherwise it stops and says so.Sync Type: Date Range (assets changed in a window, default the past week) or Asset IDs (paste Mapped asset IDs, usually starting THG). Buildings (optional). There is no "all assets" option on purpose. To load a large estate, use a wide date range, over several runs if needed.
Refresh Nuvolo Reference DataRun this after a Nuvolo administrator adds or renames request types, job types or services. Publishing always uses Nuvolo's current lists, but the saved copy that other integrations read is only taken on the connector's first run. This job updates that copy.Buildings (optional). It sends nothing to Nuvolo and is safe to run at any time.

For the Buildings field, enter Nuvolo building IDs (sys_ids), separated by commas. Leave it empty to use the buildings chosen in Settings, or every Nuvolo building in Mapped if none are chosen.


Troubleshooting​

What you seeLikely causeWhat to do
The connector shows as stopped or won't startThe setup is incomplete (see Step 5)Open Settings. Check that a publish mode is chosen, the Work Order type is mapped and every enum tab is filled in. Then Save.
No Work Orders appear in NuvoloPublish Work Orders is off; the Work Orders aren't Corrective Maintenance; their buildings aren't selected; or their source connector is switched offCheck each of these in Settings. Then run Backfill Workorders for the affected dates.
"Rejected … missing required fields, no location" in the logsThe Mapped Work Order has no space or asset, or no value for a required fieldFix it in the source system; it is picked up on its own. Or loosen the Required fields step if the requirement is too strict.
An edit made in Nuvolo got revertedNuvolo Source is bringing the Work Order into Mapped, and this connector is writing it backSwitch Nuvolo Source off under Source connectors.
Work Orders are always Draft in NuvoloThis is current behaviour: Work Orders are created as Draft and status is not yet sent from MappedExpected. Change the status in Nuvolo itself.
A new Nuvolo service or request type isn't offered in an enum mapping tabThe tab's list was loaded before the changeReload the Settings page. To also update the saved copy other integrations read, run Refresh Nuvolo Reference Data.
"N asset(s) were not updated because their Nuvolo record has no matching correlation_id"Only update assets created by Mapped is on, and those Nuvolo assets were not created by this connector, or were created before correlation taggingExpected for Nuvolo's own assets. For assets this connector created earlier, turn the setting off and follow the steps under Assets created before correlation tagging in Step 2.
"Ignoring field mapping(s) …" warningAn older setup maps a field Nuvolo fills in itselfOpen Settings and click Save. The mapping is removed automatically.

Mapped Concepts​

This connector does not create new things in your graph. It reads existing entities and adds a Nuvolo identity to each one it sends.

Mapped entityRead from the graphWritten back
WorkOrderName, description, status, type, request type, service, dates, requester, and the place or asset it relates toAn external identity holding the Nuvolo Work Order's sys_id
Thing (asset)Name, asset tracking ID, serial number, type, owning department, model, manufacturer, locationAn external identity holding the Nuvolo asset's sys_id
Building / SpaceThe Nuvolo identities Nuvolo Source added, used to work out where each Work Order goes in NuvoloNothing

Asset field mapping​

There is no editable asset field mapping table. Which Mapped field feeds which Nuvolo field is fixed in the connector. The only things you configure are the two value mappings on the Assets tab, Asset Type and Owning Department.

The connector uses three Nuvolo tables. All three table names are fixed and cannot be changed.

PurposeNuvolo tableFields the connector writes
Assetsx_nuvo_eam_facilities_devicesSee the mapping tables below.
Manufacturer reference tablex_nuvo_eam_companyname, description, externalId (the Mapped manufacturer ID), and manufacturer set to true.
Model reference tablex_nuvo_eam_facilities_modelsname, description, external_id (the Mapped model ID), manufacturer (the Nuvolo manufacturer record) and asset_type.

Manufacturers and models are written before the assets that use them. The connector first looks for an existing manufacturer or model with the same name and only creates one if none is found.

Customizable in the connector configuration

Nuvolo fieldMapped fieldWhere you set it
asset_typeexactTypeAsset Type on the Assets tab: match each Mapped asset type to a Nuvolo asset type. Required. Assets whose type is not matched are skipped, and the log names the unmatched types.
departmentName of the first isResponsibilityOf entryOwning Department on the Assets tab: match Mapped department names to Nuvolo departments. Required.

Each of these two mappings can also use a default value for anything unmatched, or be turned off.

Fixed mappings (not customizable)

Nuvolo fieldMapped fieldNotes
sys_idurn:nuvolo:asset:id identityPresent only once the asset is linked to Nuvolo. Without it, the asset is created.
asset_tagassetTrackingID
serial_numberserialNumber
short_descriptionurn:willowinc:twin:name identity if present, otherwise the asset name
nameThe asset's customer ID identity (for example the Willow twin ID)Assets with neither a Nuvolo ID nor a customer ID identity are skipped.
correlation_idThe Mapped asset IDLets the connector find an asset it already created, rather than create a duplicate.
asset_locationThe asset's location: its Nuvolo elocation identity if present, otherwise its Nuvolo space identityOnly assets located in the selected buildings are sent.
model_namehasDeviceModelThe model is found by name, or created.
asset_manufacturermanufacturedByThe manufacturer is found by name, or created. Assets with no model or manufacturer use DEFAULT_MANUFACTURER and DEFAULT_MODEL_<manufacturer>.
install_status, operational_statusFixed value 1Sent on create only. Never changed on update, so Nuvolo keeps control of asset state.

Assets are sent only when the Publish Assets job is run, and only when Sync assets is on.

Graph Diagram​

In Nuvolo, each created Work Order carries its Mapped ID in the standard ServiceNow Correlation ID field.

Sample Code​

Query Work Orders

Read more about how to query Work Orders in the Mapped Graph.

{
workOrders(filter: { connectedDataSourceId:{ eq: "your-connector-Id"}}) {
id
name
mappingKey
summary
description
jobStatus
jobSubStatus
jobPriority
jobType
sector
dueDate
dateClosed
externalDateCreated
externalDateUpdated
problemDescription
resolutionDescription
isReportedBy {
name
emails {
address
}
}
isCreatedBy {
name
emails {
address
}
}
isClosedBy {
name
emails {
address
}
}
hasAssignee {
name
emails {
address
}
}
hasAssignedGroup {
name
hasMember {
name
}
}
relatesTo {
__typename
... on Building {
id
name
}
... on Floor {
id
name
level
}
... on Space {
id
name
exactType
}
... on Thing {
id
name
exactType
}
}
identities {
__typename
... on ExternalIdentity {
value
scope
}
}
}
}