Summary
SysTrack users can be transferred into iPaaS.com as Customer records through scheduled polling and on-demand Manual Sync. Each SysTrack user becomes an iPaaS.com Customer carrying the user's account number, derived first and last name, and email address, together with a description of the user's primary system and up to three of the sensor actions SysTrack makes available for machines running that system's operating system. This is an inbound-only collection: SysTrack is the system of record for user data, and the integration does not create, update, or delete users in SysTrack.
ID Format
Manual Sync ID Format
On the iPaaS.com Manual Sync page, enter the SysTrack user's account number to import that single user.
Pattern: the SysTrack account number.
Example:
3956.
External ID Format
After a successful transfer, the same SysTrack account number is recorded as the external-id link on the iPaaS.com Customer, so a later transfer of the same user updates the existing Customer instead of creating a duplicate. The account number therefore serves two roles: it is written into the iPaaS.com CustomerNumber field as visible data, and it is the value the integration matches on to find the existing record.
Deleted Record Support
Deleted Record Support is not supported for this entity. The integration does not implement a delete operation for SysTrack users, and delete mappings are not included in the default template. Deleting a user in SysTrack does not remove or deactivate the corresponding iPaaS.com Customer, and deleting a Customer in iPaaS.com does not affect SysTrack. Records removed on either side must be reconciled manually.
Mapping Collection Status
Status: Enabled.
Trigger Events: the scheduled Customer Poll event drives the automatic import, and Manual Sync runs a single user on demand. Customer Creation and Customer Updation events are also registered for this entity. A Customer Deletion event is registered as well, but it has no effect in this integration, because deletes are not implemented (see Deleted Record Support).
Duplicate or Conflicting Mappings
Add SysTrack Sensor Event TO iPaaS.com also transfers data inbound from SysTrack, but it creates iPaaS.com Message records rather than Customer records. It is a separate entity and does not conflict with this collection; the primary user email it captures on a sensor alert is the natural value for relating that alert back to the Customer this collection imports.
Unmapped Field Overwrite Risk
The iPaaS.com API replaces the whole Customer record on update. This collection maps CustomerNumber, FirstName, LastName, EmailAddress, and the SysTrack primary-system custom fields only, so any other value held on the iPaaS.com Customer — for example the comment, categories, or address fields — is overwritten with an empty value on each inbound transfer unless a preserving mapping is added. To retain such a value during an inbound update, add a mapping that sources the field from the existing iPaaS.com record. This matters most where the same Customer records are also maintained by another integration or by hand.
There is no collision-handling configuration on this collection. Duplicates are prevented by the external-id link described under ID Format: the SysTrack account number recorded on the Customer is matched on every transfer, so repeat transfers of the same user update the existing record. Removing or re-pointing the CustomerNumber mapping breaks that link and produces duplicate Customer records.
Supported Child Collections
None. This is a standalone collection with no dependent child collections; the primary-system and sensor-action details are written onto the same iPaaS.com Customer record rather than into dependent child records.
System Caveats
SysTrack Caveats
No sandbox environment: SysTrack does not offer a separate sandbox or test tenant. All validation is performed against a live SysTrack tenant, so subscribers or their MiSP should validate this collection with Manual Sync on a small, deliberately chosen set of users before enabling scheduled polling across the estate, and should run the first scheduled poll during a quiet period.
Name data is a single display field: SysTrack holds one full display name per user and falls back to the account username when no display name has been collected. The first and last names written to iPaaS.com are therefore derived values, and for some users may be a domain-qualified username rather than a person's name.
Email address is not guaranteed: SysTrack does not require an email address on every user record. How much of the directory reaches iPaaS.com therefore depends on the tenant's own data quality, which subscribers or their MiSP should measure against their own SysTrack tenant before relying on this collection.
The sensor-actions catalogue is tenant-wide: SysTrack publishes one catalogue of sensor actions for the whole tenant, and each entry declares which operating systems it supports. The actions reported against a user's primary system are that catalogue narrowed by operating system alone, in the order SysTrack returns them. The first, second, and third actions imported are positional, not the most relevant or most frequently used ones, and they are not selected for the user or the machine.
Request volume: SysTrack does not publish a documented request quota for this API. Importing a single user issues several requests against the SysTrack tenant, so subscribers or their MiSP should avoid running a large import concurrently with other intensive SysTrack processes, and should stagger scheduled polling rather than running it at the shortest available interval.
iPaaS.com Caveats
External-id link required: the SysTrack account number is saved as the external id so that later transfers update the same iPaaS.com Customer. Removing or re-pointing the CustomerNumber mapping breaks that link and produces duplicate Customer records.
Missing custom fields fail silently: a value mapped to an iPaaS.com custom field that has not been created on the Customer record is discarded without an error, and the rest of the record transfers normally. See Setup Requirements.
Sensor-action and profile values are not user-specific: the action and profile custom fields reflect the primary system's operating system, not the individual user. Two users whose primary systems run the same operating system will normally carry identical values in every action and profile field. Subscribers or their MiSP should not build segmentation, reporting, or routing logic that assumes these values differ between users.
Setup Requirements
The full step-by-step is in the SysTrack Installation Instructions article; this section covers what this collection specifically depends on.
SysTrack Configuration
The SysTrack connection must be authorized to read the user directory, the systems associated with a user, and the tenant sensor-actions catalogue. All three are retrieved for every user imported. Authentication is by a SysTrack service account; see the SysTrack Installation Instructions and SysTrack Connections and Settings articles for the values to gather.
iPaaS.com Configuration
Configure the Customer Poll event. Automatic transfers are driven by a Customer Poll event created under Integration Monitoring and Diagnostics / Events, where its cadence is also set. No automatic transfers occur until that event has been configured and is running. Manual Sync is available regardless.
Create the primary-system and sensor-action custom fields on the iPaaS.com Customer record before the first transfer. The fifteen custom fields listed below must exist, or the corresponding mappings must be removed from this collection. A value mapped to a custom field that does not exist is silently dropped — the Customer still transfers, so nothing is reported in the Error Logs and the loss is only visible as an empty field. One of these two actions must be done at install time:
SysTrack Primary System Id, SysTrack Primary System Name, SysTrack Primary System OS
SysTrack Primary System Action 1 Id, SysTrack Primary System Action 1 Name, SysTrack Primary System Action 1 Profile 1 Id, SysTrack Primary System Action 1 Profile 1 Name
SysTrack Primary System Action 2 Id, SysTrack Primary System Action 2 Name, SysTrack Primary System Action 2 Profile 1 Id, SysTrack Primary System Action 2 Profile 1 Name
SysTrack Primary System Action 3 Id, SysTrack Primary System Action 3 Name, SysTrack Primary System Action 3 Profile 1 Id, SysTrack Primary System Action 3 Profile 1 Name
Integration Flow
A scheduled Customer Poll run enumerates the SysTrack user directory and queues every user for transfer. Each polling cycle queues the full list rather than only users changed since the previous cycle, so subscribers or their MiSP with large tenants should account for this when choosing a polling interval. A single user can also be queued on demand from the Manual Sync page by entering the account number.
For the user being transferred, the integration retrieves the SysTrack user directory and selects the user whose account number matches the record. If the account number is not found, the transfer fails with an error stating that the provided ID is incorrect.
The systems associated with that user are retrieved. The first system returned is treated as the primary system and supplies the system identifier, machine name, and operating system. If the user has no associated systems, the Customer still transfers and every primary-system value is left empty.
The tenant sensor-actions catalogue is retrieved and narrowed to the actions that support the primary system's operating system, in the order SysTrack returns them. Up to three actions, and the first profile of each, are captured.
The mapping filter is applied. A user with no email address, or whose email address is exactly the text Not collected, is skipped silently; no iPaaS.com Customer is created and no error is raised.
The iPaaS.com Customer is created or updated. The SysTrack account number is written to CustomerNumber and recorded as the external-id link, so a repeat transfer updates the existing Customer rather than creating a duplicate.
Mappings
This collection maps one SysTrack user to one iPaaS.com Customer record. The subsection below lists every field mapping; the mapping filter that governs which users are transferred is described first.
Add/Update SysTrack User TO iPaaS.com
iPaaS.com data type: Customer
Mapping Filter
The collection applies the following mapping filter:
!String.IsNullOrEmpty(Email) && Email != "Not collected"
Filter Description. A SysTrack user is transferred only when both conditions are satisfied: the user has an email address recorded (Email is not empty), and that email address is not exactly the text Not collected. A user who fails either condition is skipped rather than transferred and failed — no error is raised and nothing appears in the iPaaS.com Error Logs on that user's account. The effect is that the iPaaS.com-side roster covers only the subset of the SysTrack directory that has a usable email address on file. A user expected in iPaaS.com but absent should be checked in SysTrack first for an empty email address, or for one recorded as Not collected.
Mapping Type | Source Field (SysTrack) | Destination Field (iPaaS.com) | Description |
Field | Account | CustomerNumber | Required. The account number SysTrack holds for the user. It is written into CustomerNumber as visible data and is also recorded as the external-id link, so a later transfer of the same user updates the existing Customer rather than creating a second one. It is the value entered on the Manual Sync page. Removing this mapping, or re-pointing it at a different SysTrack value, breaks the link and produces duplicate Customer records. |
Field | EmailAddress | Required. The SysTrack user's email address. The mapping filter admits only users who have a usable email address, so this value is present on every Customer this collection creates. It is required in the sense that the iPaaS.com Customer record cannot be created without it. | |
Dynamic Formula | Dynamic Formula | FirstName | Recommended. Derives a first name by taking the text before the first space of the SysTrack full display name, so a display name of "Jane Smith" produces "Jane". SysTrack stores one display name rather than separate name parts, so the split is positional. When the user has no display name recorded, the formula writes the literal text FirstName. Placeholder value — replace during implementation: the fallback literal FirstName is scaffold text, not a real name. Subscribers or their MiSP should edit this mapping to return an empty value, or to substitute a fallback suited to their own data quality, before the first production transfer. SysTrack falls back to the account username when no display name has been collected, so the value written may be a domain-qualified username rather than a given name. |
Dynamic Formula | Dynamic Formula | LastName | Recommended. Derives a last name by taking the second space-separated part of the SysTrack full display name only, so "Jane Smith" produces "Smith" but "Mary Anne Smith" produces "Anne"; any part after the second is discarded. When the user has no display name, or the display name is a single word, the formula writes the literal text LastName. Placeholder value — replace during implementation: the fallback literal LastName is scaffold text, not a real name. Subscribers or their MiSP should edit this mapping to return an empty value, or to substitute a fallback suited to their own data quality, before the first production transfer. |
Field | Supportedos | SysTrack Primary System OS | Optional. The operating system type reported for the primary system — the first system SysTrack associates with the user. This value is the sole determinant of which sensor actions are reported: the tenant-wide catalogue is narrowed by this operating system and nothing else, so a change of operating system changes the whole action set on the next transfer, and users sharing an operating system share their action values. Left empty when the user has no associated systems. |
Dynamic Formula | Dynamic Formula | SysTrack Primary System Id | Optional. Returns the SysTrack identifier of the first system associated with the user — the primary system. The order SysTrack returns systems in is not a ranking, so this is the first system listed, not the most-used device. A user with several systems is described by one system only. This is the practical way to trace an imported Customer back to a specific device in SysTrack. Left empty when the user has no associated systems. |
Dynamic Formula | Dynamic Formula | SysTrack Primary System Name | Optional. The machine name of the primary system — the same device as SysTrack Primary System Id. The value is the system name as SysTrack records it, typically the host name rather than the fully qualified domain name. Left empty when the user has no associated systems. |
Dynamic Formula | Dynamic Formula | SysTrack Primary System Action 1 Id | Optional. Returns the identifier of the first sensor action available for the primary system. The formula selects the first system, then the first action SysTrack lists as compatible with that system's operating system. "Action 1" means first in catalogue order, not the most relevant. This value is not selected for the user or the machine, so two users on the same operating system will normally carry an identical value. Left empty when the user has no associated systems or the primary system has no compatible actions. |
Dynamic Formula | Dynamic Formula | SysTrack Primary System Action 1 Name | Optional. The display name of the first sensor action available for the primary system — the human-readable counterpart to SysTrack Primary System Action 1 Id, selected by the same first-system, first-action rule. It indicates which remediations exist for a machine of that operating system, not a per-user recommendation. Left empty when there are no associated systems or no compatible actions. |
Dynamic Formula | Dynamic Formula | SysTrack Primary System Action 1 Profile 1 Id | Optional. The identifier of the first profile defined on the first sensor action for the primary system. A profile is a preconfigured variant of a sensor action. The formula narrows to first system, then first action, then first profile, taking the first entry at each step. Not user-specific. Left empty when any step has nothing to return — no systems, no compatible actions, or an action with no profiles. |
Dynamic Formula | Dynamic Formula | SysTrack Primary System Action 1 Profile 1 Name | Optional. The display name of the first profile on the first sensor action — the human-readable counterpart to SysTrack Primary System Action 1 Profile 1 Id, following the same first-system, first-action, first-profile selection. It is the label a technician would recognise in SysTrack. Not user-specific. Left empty when there are no systems, no compatible actions, or no profiles on the first action. |
Dynamic Formula | Dynamic Formula | SysTrack Primary System Action 2 Id | Optional. The identifier of the second sensor action available for the primary system, selected by the same rule as the first action but taking the second entry in SysTrack's order. A primary system with only one compatible action leaves this empty, as does a user with no associated systems. Not user-specific. |
Dynamic Formula | Dynamic Formula | SysTrack Primary System Action 2 Name | Optional. The display name of the second sensor action — the human-readable counterpart to SysTrack Primary System Action 2 Id. A primary system with fewer than two compatible actions leaves this empty, as does a user with no associated systems. Not user-specific. |
Dynamic Formula | Dynamic Formula | SysTrack Primary System Action 2 Profile 1 Id | Optional. The identifier of the first profile on the second sensor action for the primary system, narrowing first system, then second action, then first profile. Left empty when there are no systems, fewer than two compatible actions, or the second action defines no profiles. Not user-specific. |
Dynamic Formula | Dynamic Formula | SysTrack Primary System Action 2 Profile 1 Name | Optional. The display name of the first profile on the second sensor action — the human-readable counterpart to SysTrack Primary System Action 2 Profile 1 Id, following the same first-system, second-action, first-profile selection. Left empty under the same conditions. Not user-specific. |
Dynamic Formula | Dynamic Formula | SysTrack Primary System Action 3 Id | Optional. The identifier of the third sensor action available for the primary system, taking the third entry in SysTrack's order. A primary system with fewer than three compatible actions leaves this empty. Three action slots are mapped by default, so a system with more than three compatible actions has the remainder omitted rather than truncated with a warning. Not user-specific. |
Dynamic Formula | Dynamic Formula | SysTrack Primary System Action 3 Name | Optional. The display name of the third sensor action — the human-readable counterpart to SysTrack Primary System Action 3 Id. Left empty when the primary system has fewer than three compatible actions or the user has no associated systems. Not user-specific. |
Dynamic Formula | Dynamic Formula | SysTrack Primary System Action 3 Profile 1 Id | Optional. The identifier of the first profile on the third sensor action for the primary system, narrowing first system, then third action, then first profile. Left empty when there are no systems, fewer than three compatible actions, or the third action defines no profiles. Not user-specific. |
Dynamic Formula | Dynamic Formula | SysTrack Primary System Action 3 Profile 1 Name | Optional. The display name of the first profile on the third sensor action — the human-readable counterpart to SysTrack Primary System Action 3 Profile 1 Id. Only the first profile of each mapped action is imported, so an action defining several profiles is represented by one of them. Left empty under the same conditions. Not user-specific. |
The four Dynamic Formula entries above whose destination is a name-part field (FirstName, LastName) walk the SysTrack full display name; the remaining Dynamic Formula entries walk the systems associated with the user, the sensor actions available for each system, and the profiles defined on each action, selecting positionally as described in each row. Each writes an empty value and lets the rest of the record transfer when its chain has nothing to return.
Error Handling
Error messages this collection can raise — including the incorrect-ID error when an account number is not found in the SysTrack directory, and the connection and authentication errors common to every flow — are cataloged in the SysTrack Error Messages article, under the Add/Update SysTrack User TO iPaaS.com flow. Errors appear on the iPaaS.com Dashboard under Integration Monitoring, in the Error Logs. Note that a user skipped by the mapping filter for a missing or Not collected email address does not raise an error; it is a silent skip, not a failure.
Testing & Validation
Test Scenarios
Import a user with a usable email address. Run Manual Sync with the account number of a SysTrack user who has a real email address on file. Expected outcome: an iPaaS.com Customer is created with CustomerNumber set to the account number and EmailAddress set to the SysTrack email, and the account number is recorded as the external-id link.
Re-import the same user. Change a mapped value in SysTrack (for example the display name) and run Manual Sync again with the same account number. Expected outcome: the existing iPaaS.com Customer is updated in place — no duplicate Customer is created — because the account number matches the external-id link.
Attempt to import a user with no usable email. Run Manual Sync with the account number of a user whose email address is empty or is exactly the text Not collected. Expected outcome: no iPaaS.com Customer is created and no error is raised — the mapping filter skips the user silently.
Attempt an unknown account number. Run Manual Sync with an account number that does not exist in the SysTrack directory. Expected outcome: the transfer fails with an error stating that the provided ID is incorrect, visible under Dashboard / Integration Monitoring / Error Logs.
Confirm custom-field population. Import a user whose primary system has compatible sensor actions, with the primary-system and sensor-action custom fields created on the Customer record beforehand. Expected outcome: the primary-system and action fields are populated positionally; a user with no associated systems imports with those fields empty and the rest of the record intact.
Validation Checklist
The Customer is created with CustomerNumber and EmailAddress populated from SysTrack.
The SysTrack account number is recorded as the external-id link, and a repeat transfer updates rather than duplicates.
Users without a usable email address are absent from iPaaS.com and produce no Error Logs entry.
The primary-system and sensor-action custom fields exist on the Customer record before the first transfer, or their mappings have been removed.
Where the display name has no space, or no display name exists, the placeholder text in FirstName and LastName has been addressed before production use.
Additional Notes
Writing user data back to SysTrack is out of scope. Creating, updating, and deleting SysTrack users are not implemented, and there is no FROM iPaaS.com counterpart to this collection. Changes made to a Customer record in iPaaS.com stay in iPaaS.com. For the platform boundaries this collection inherits from SysTrack, see the SysTrack Integration Known Limitations article.