Integration Guide: Yardi Voyager
This guide explains how NetVendor Maintenance (NVM) integrates with Yardi Voyager via API.
A note from the NetVendor Maintenance Team:
As of late-August 2023, ServusConnect was re-branded as NetVendor Maintenance. You may still see "ServusConnect" referenced within Yardi Voyager documentation and interface, which translates to NetVendor Maintenance.
Tables of Contents
Service Requests Sync
Key Information
- Table 1: Service Request Sync Rules
Service Request Imports
- Table 2: Service Request Import Field Mappings
- Table 3: Service Request Import State Updates
- Yardi <> NVM Sync Example
Service Request Exports
- Table 4: Service Request Export Field Mappings
- Table 5: Service Request Export State Updates
Units & Residents Sync
Key Information
- Table 6: Unit and Resident Sync Rules
- Table 7: Unit Import Field Mappings
- Table 8: Resident Import Field Mappings
Service Requests Sync
Key Information
- Service Requests are imported from Yardi Voyager to NetVendor Maintenance (NVM) periodically, currently around every 10 minutes (subject to change, either more or less frequent)
- Service Requests that have been updated in NVM are exported in real-time
- On the first sync, only open requests in Yardi that have been modified “recently” are imported. The size of the window for “recent” requests is configurable.
Table 1: Service Request Sync Rules
| Direction | Complete in Yardi? | Exists in Target? | Action |
| Import to NVM | No | No | Create in NVM. |
| Import to NVM | Yes | No | Ignore. Historically completed requests are not imported into NVM. |
| Export to Yardi | N/A | No | Create in Yardi |
| Export to Yardi | N/A | Yes | Update in Yardi |
Service Request Imports
Service Requests are imported from Yardi to NVM periodically, when they are detected to be new or updated.
Note: the “two-way sync” feature was enabled on March 30, 2022. This means that many changes made to Yardi after initial import would result in an update to NVM.
Table 2: Service Request Import Field Mappings
| NVM Field | Yardi Field | Notes | When Updated[1] |
| External ID | Service Request ID | Used to link a service request in Yardi to one in NVM. | C |
| Title | Brief Description OR Problem Description OR Full Description | Brief Description will be used if it is present. Otherwise, we use Problem Description or Full Description, whichever is longer. | C/U |
| Description | Problem Description OR Full Description | Problem Description or Full Description, whichever is longer. | C/U |
| State | Status | New SRs are only created in NVM when the status is not “Work Completed” or “Canceled” in Yardi (i.e. NVM does not import completed work). The state in NVM tracks the status in Yardi according to Table 3: Service Request State Updates. |
C/U |
| Severity | Priority | We use configurable priority mappings. These are configured for you by the NVM customer success team. | C/U |
| Comments | Access Notes Technician Notes |
Yardi Access Notes and Techniciation Notes are entered as comments when importing the new NVM Request. Further updates to Access Notes and Technician Notes in Yardi are not currently added to NVM. |
C |
| Building | LOOKUP(Unit Code) > Building | Lookup the Unit in NVM from the Yardi Unit Code, and take its “Building” value in NVM. Otherwise “N/A”. | C/U |
| Target Date | Due Date | C/U | |
| Service Provider | - | Property primary SP, property’s first SP, or the account default SP | C |
| Property Manager | - | Property primary PM, property’s first PM, or the account default PM | C |
| Tenant Name | Requestor Name | C/U | |
| Tenant Phone | Requestor Phone | C/U | |
| Tenant Email | Requestor Email | C/U | |
| Unit | LOOKUP(Unit Code) | Lookup the local unit from where External ID is Unit Code | C/U |
| Authorized to Enter | Ok to Enter | “Anytime” if Ok to Enter is “Y”. “No permission given” otherwise. |
C/U |
| Has Pet | Full Description includes “Has Pets: Yes”? | C/U | |
| External Source | Origin | C/U | |
| Due By Date (Target Date) | Due Date | C | |
| Tag List | Category and Subcategory | Category and Subcategory are converted to tags | C |
| Requested At | Service Request Date | Setting this timestamp allows the “age” of the request to be calculated correctly. There is also a “requested” activity displayed in the request’s activity stream. This activity will be time stamped with the date of the import, not the date the request was created in Yardi, since we cannot set the activity date to the past. |
[1] Legend: C = On Creation, C/U = On Creation or Update
Table 3: Service Request Import State Updates
NVM “state transitions” are utilized to achieve the following ending states in NVM. These state transitions ensure the rich history information in NVM is maintained.
| Yardi Status | NVM State |
| Call | requested |
| In Progress | accepted |
| On Hold | requested_on_hold or accepted_on_hold |
| Canceled | archived |
| Work Completed | completed |
Yardi <> NVM Sync Example
Service Request Exports
Service Requests are exported from NVM to Yardi in nearly real-time, as the changes happen.
Table 4: Service Request Export Field Mappings
| Yardi Field | NVM Field | Notes |
| Status | State | See Table 5: Service Request Export State Mappings |
| Has Pet | Has Pet | |
| Has Permission To Enter | Authorized To Enter | Set to “true” when NVM “Authorized to Enter” is “Anytime”, false otherwise. |
| Due Date | Target Date | |
| Priority | Severity | We use configurable priority mappings. These are configured for you by the NVM customer success team. |
| Brief Description | Title | |
| Full Description | Description | |
| Problem Description Notes | Description | |
| Requestor Name | Tenant Name | |
| Requestor Phone | Tenant Phone | |
| Requestor Email | Tenant Email | |
| Unit Code | Unit > External ID | |
| Technician Notes | Comments | NVM tags the technician notes with “Managed by NVM”, a URL to view the request in NVM, and all of the comments made in NVM (up to 1500 characters total). |
| Access Notes | Authorized to Enter, Authorized to Enter At | A helpful description of the full entry authorization from NVM. |
Table 5: Service Request Export State Updates
NVM state updates are utilized to end in the following ending states in NVM.
| NVM State | Yardi Status |
| requested | Call |
| archived | Work Completed (if request was completed) Canceled (if request never completed) |
| completed | Work Completed |
Units & Residents Sync
Key Information:
- Unit and Resident information are imported from Yardi to NVM every night.
- Unit and Resident data are not managed in NVM, so these records are never exported to Yardi.
- Unit and Resident records in NVM that are no longer “active” in Yardi (i.e. a resident who has moved out) are purged from NVM nightly.
Table 6: Unit and Resident Sync Rules
| Direction | Action | Notes |
| Import | Create in NVM | Records in Yardi that are not in NVM are created. |
| Import | Update in NVM | Records in Yardi that already exist in in NVM are updated. |
Export |
None | Unit and Resident data are not managed in NVM. |
Table 7: Unit Import Field Mappings
| NVM Field | Yardi Field | Notes |
| External ID | Unit ID | Used to match a unit from Yardi with a unit in NVM. |
| Address | Address > Line 1 | |
| City | Address > City | |
| State | Address > State | |
| Zip | Address > Zip | |
| Building | Building Name | Or “N/A” if no Building Name. |
| Status | Unit Economic Status Description | |
| Amenities | Unit Type, Bedrooms, Bathrooms | Format: “<Unit Type> - <Bedrooms>BR / <Bathrooms>BA”. |
| Configuration | Floorplan Name | |
| Description | Floorplan Name | |
| Size | Size | Represented in square feet. |
Table 8: Resident Import Field Mappings
| NVM Field | Yardi Field | Notes |
| External ID | Resident ID | Used to match a resident from Yardi with a resident in NVM. When no matching External ID exists, we create a record. Otherwise, the existing record is updated. |
| Status | Status | ● Yardi “Current” = NVM “current” ● Yardi “Notice” = NVM “current” ● All others = End up being purged from NVM |
| Name | First Name + Last Name | |
| Phone | Phone Number | Residents in Yardi can have multiple phones. So, we attempt to import the phone marked as phone type “cell”. If there is none marked as “cell”, we sync the first phone number on the resident record. In all cases, we normalize the phone number upon import. |
| Unit | LOOKUP(Unit Code) | The Unit Code for the Yardi record is used to lookup a NVM unit that was already synced. |