Summary
Triggered SysTrack sensor events can be transferred into iPaaS.com as new Message records through scheduled polling and on-demand Manual Sync. Each imported event creates an iPaaS.com Message describing the alert, together with the affected machine, its primary user, and the remediation automations SysTrack has available for it. The collection is deliberately narrow: it creates a Message only when SysTrack offers at least one automation that could resolve the issue, and the Message carries the identifiers the companion collection Update SysTrack Autofix Run FROM iPaaS.com needs to send a one-click remediation back to SysTrack.
ID Format
Manual Sync ID Format
On the iPaaS.com Manual Sync page, enter the sensor identifier and the machine's system identifier joined by a vertical bar.
Pattern: sensor id, a vertical bar, then system id.
Example:
101258|100007.
Both parts are required; a value containing only one part is rejected. Although some parts of the underlying data are typed as globally unique identifiers, the sensor and system identifiers SysTrack returns in practice are short numeric values, as the example shows. Do not assume a fixed identifier length or format when building workflow logic around this value.
External ID Format
The same combined sensor-and-system value is recorded as the external-id link on the iPaaS.com Message. It is how iPaaS.com resolves a message back to its originating SysTrack sensor event on later operations, including the outbound remediation dispatch, and it is the fallback key used to recognize a sensor-and-machine pair that has been seen before. Because the identifier combines the sensor with the machine rather than identifying a single activation, where SysTrack has recorded several entries for that pair one entry is selected for transfer; subscribers or their MiSP should validate which entry is selected in a staging environment before relying on it in production.
Deleted Record Support
Deleted Record Support is not supported for this entity. The integration does not implement a delete operation for SysTrack sensor events, and delete mappings are not included in the default template. Removing an iPaaS.com Message does not remove anything in SysTrack, and a sensor event cleared in SysTrack does not remove the corresponding iPaaS.com Message. Note that messages created by this collection are auto-deleted by iPaaS.com when their expiration time passes; that is retention behavior, described under Message Retention, not delete support.
Mapping Collection Status
Status: Enabled.
Trigger Events: the scheduled Message Poll event drives the automatic import, asking SysTrack for sensors that activated between the end of the previous run and the current time, so no activity is missed between runs. Manual Sync runs a single sensor event on demand. This collection produces nothing until a polling event exists and is enabled.
Duplicate or Conflicting Mappings
Update SysTrack Autofix Run FROM iPaaS.com is the reverse-direction companion to this collection. It reads the automation identifiers this collection stores and asks SysTrack to run the remediation, then writes the outcome back onto the same message. It does not update the original sensor event in SysTrack.
Add/Update SysTrack User TO iPaaS.com imports SysTrack users into iPaaS.com as Customer records in the same inbound direction. It is a separate entity and does not conflict with this collection, but the primary user email captured here is the natural value for relating a sensor alert to the corresponding iPaaS.com Customer.
Duplicate Prevention
There is no collision-handling configuration on this collection. The combined sensor-and-system identifier saved as the external id lets a sensor-and-machine pair already present in iPaaS.com be recognized, and it is what the outbound remediation uses to find its way back to the correct sensor event.
Supported Child Collections
None. This is a leaf collection — the machine, user, and automation details are written onto the same iPaaS.com Message rather than into dependent child records, and no other collection runs as part of this transfer.
System Caveats
SysTrack Caveats
Primary user availability: SysTrack only reports the primary user's email, account name, and full name while that user is currently logged in to the machine. Because the filter requires a primary user email, sensor events raised on machines with nobody signed in are never imported at all.
Automations are only visible for connected machines: the automation lookup depends on SysTrack being able to reach the machine's recent sensor history. If the machine is not connected at the moment of transfer, no automations are collected, and the filter then excludes the event entirely.
Polling load: each sensor event costs several calls to SysTrack, since the sensor, the machine, and the machine's automation history are each retrieved separately. SysTrack does not publish a rate ceiling for this integration. Set the polling interval to the slowest cadence the alerting requirement tolerates, avoid running a broad manual backfill at the same time as a scheduled polling run, and validate the interval against a representative fleet size before relying on it in production.
No sandbox environment: SysTrack does not offer a sandbox or test tenant. All configuration and testing is performed against the live SysTrack environment, so validate mapping changes on a small, deliberately chosen set of machines before enabling broad automatic transfers.
iPaaS.com Caveats
External-id link required: the combined sensor-and-system identifier is saved as the external id so that a sensor-and-machine pair already present in iPaaS.com can be recognized, and so the outbound remediation can find its way back to the right sensor event.
Automatic expiry: messages created by this collection are deleted automatically after their expiration time, as described under Message Retention.
Message severity is not SysTrack severity: the iPaaS.com Message Severity is set to the static value None for every sensor event. SysTrack's own rating, a number from 1 through 9, is carried in the SysTrack Severity custom field. Prioritize on the custom field, not on the message severity.
Origin marker spelling: messages from this collection are tagged in the Systrack Type custom field with the fixed value Systrack Initiated. Both the field name and the value use a lowercase t, unlike the SysTrack brand spelling used elsewhere. Workflow filters that test for this marker must match the stored spelling exactly.
Missing custom fields fail silently: a value mapped to a custom field that does not exist on the iPaaS.com Message is discarded without an error, and the message is still created. The most serious consequence is a message from which no remediation can be dispatched, because the automation identifiers the outbound collection needs were dropped. See Setup Requirements.
Integration-Specific Caveats
Sensor names and automation names cannot be related: the SysTrack API exposes no relationship between the name of the sensor that triggered and the name of an automation — only their identifiers are returned. A message raised for one sensor may therefore carry an automation intended to resolve a different sensor's issue. Subscribers or their MiSP should confirm in SysTrack what a given automation actually does before acting on a one-click remediation, and should not present these alerts as self-service fixes to end users without that confirmation.
Only actionable alerts are imported: by design, sensor events with no available remediation never become iPaaS.com Messages, so the iPaaS.com Message list is not a complete record of SysTrack sensor activity.
Message Retention
Every message this collection creates is stamped with an expiration of 10 days after it is created, and iPaaS.com automatically deletes messages once their expiration time has passed. Sensor-event messages therefore clear themselves out of the iPaaS.com Message list after ten days rather than accumulating.
This retention window is a deliberate default and can be changed. To keep alerts visible for longer, increase the number of days in the ExpirationTime mapping. To retain them indefinitely, remove that mapping entirely — a message with no expiration time set is never auto-deleted. Deletion is silent and permanent from the iPaaS.com side, so subscribers or their MiSP who need a durable audit trail of SysTrack alerts should either extend the window to cover their retention obligation or export the messages before they expire.
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 for sensor, system, and sensor-history data. All three are retrieved for every transfer. If the machine's sensor history cannot be read, no automations are collected and the filter then excludes the event, so an authorization gap presents as an empty message list rather than as a transfer error. 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 Message Poll event. Automatic transfers are driven by a polling event created under Integration Monitoring and Diagnostics / Events. Without it, no sensor events transfer automatically and the collection is exercised only through Manual Sync.
Create the iPaaS.com Message custom fields before the first transfer. This collection writes twenty-one values into custom fields on the Message record — the SysTrack sensor, machine, primary user, and automation fields, plus the two automation-state fields. A custom field that does not exist when the transfer runs is not reported as an error: the transfer succeeds, the Message is created, and the value is silently discarded. Either the required custom fields must be created on the iPaaS.com Message record, or the corresponding mappings must be removed — one of these must be done at install time. In particular, SysTrack Sensor Automation Initiated and SysTrack Sensor Automation Batch Id must be configured before the first transfer; without them the outbound collection's run-once guard cannot function and a remediation can be dispatched repeatedly against the same alert.
Integration Flow
A scheduled Message Poll run asks SysTrack for sensors that activated since the previous run, and the resulting sensor-and-machine pairs are queued for transfer. A single sensor event can also be queued on demand from the Manual Sync page using the ID format above.
For each pair, the triggered sensor's own details are retrieved — its name, severity, activation time, trigger count, and visibility flag.
The affected machine's record is retrieved to add the machine's display name and its primary user's email address, account name, and full name.
The machine's most recent sensor history is retrieved to find which triggered sensors have a remediation automation attached, and those automations are collected onto the record.
The mapping filter is applied. Events that fail it — hidden results, events with no primary user email, or events with no automation attached — are discarded at this point and no iPaaS.com Message is created.
The iPaaS.com Message is created with its body text, detail line, type, severity, creation time, and a ten-day expiration, and the SysTrack sensor, machine, user, and automation values are written to custom fields on that message. The combined sensor-and-system identifier is recorded as the external-id link.
Mappings
This collection maps one triggered SysTrack sensor event to one iPaaS.com Message record. The subsection below lists every field mapping; the mapping filter that governs which events are transferred is described first.
Add SysTrack Sensor Event TO iPaaS.com
iPaaS.com data type: Message
Mapping Filter
The collection applies the following mapping filter. All three conditions must be satisfied before a sensor event is transferred:
IsHidden != 8 && !IsNullOrEmpty(PrimaryUserEmail) && (Automations != null && Automations.Count > 0)
Filter Description. First, the event's visibility flag IsHidden must not be 8; SysTrack uses this flag to control where a sensor result is displayed, and this condition excludes results SysTrack has marked as hidden. Second, PrimaryUserEmail must not be empty; because SysTrack only reports primary user details while that user is logged in, this condition also excludes events raised on machines with nobody signed in. Third, the Automations list must be present and contain more than zero entries — the event must have at least one remediation automation attached. The third condition has the widest consequence: this collection imports only sensor events for which SysTrack has an available remediation, so the iPaaS.com Message list is a list of actionable items rather than a complete record of SysTrack sensor activity. An event that fails any condition is skipped and no Message is created; no rejection error is written to the Error Logs. Subscribers or their MiSP who want visibility of all triggered sensors, including those with no remediation available, must relax the third condition — and should expect a substantially higher message volume if they do.
Mapping Type | Source Field (SysTrack) | Destination Field (iPaaS.com) | Description |
Dynamic Formula | Dynamic Formula | Text | Required in practice. Sets the main body text of the Message — the prompt presented to the person whose machine raised the alert. As shipped, every message carries the same generic sentence, "We have noticed an issue on your machine would you like us to try to fix it?", and does not name the sensor or the machine. A more specific alternative that would name both is present in the mapping but is commented out and has no effect. Subscribers or their MiSP who want the prompt to identify the sensor and machine should replace this mapping; the sensor and machine names are already carried in the SysTrack Sensor Name and SysTrack System Name custom fields and in the Details line. |
Dynamic Formula |
| Details | Recommended. Builds the supporting detail line shown beneath the message text, composing a short sentence from the triggered sensor's common name — for example "Sensor Low Disk Space has been triggered". Unlike Text, this line does name the specific sensor, so it is the field to read to see which SysTrack sensor produced the alert. Populated on every transfer, since the sensor name is always supplied. |
Static |
| Type | Required in practice. Classifies the Message as type Other, because iPaaS.com's built-in message types do not include a category for an endpoint-monitoring alert. Sensor events are distinguished instead by the Systrack Type custom field. Route SysTrack alerts on that custom field, not on this value, which is not unique to this integration. |
Static |
| Severity | Recommended. Sets the severity of the Message itself to None — a designed constant, so SysTrack alerts do not compete with severity levels assigned by other integrations on the same subscription. This is a different value from the SysTrack Severity custom field, which carries SysTrack's own numeric rating. |
Dynamic Formula | Dynamic Formula | MessageCreatedTime | Recommended. Records when the Message was created, as a date-and-time-with-offset value carrying its time-zone offset. This is the time the alert reached iPaaS.com, deliberately not the time the sensor fired in SysTrack; the moment of activation is carried separately by SysTrack Result Time, and the two differ by the polling interval. Computed at transfer time, so always populated. |
Dynamic Formula | Dynamic Formula | ExpirationTime | Recommended. Stamps the Message with an expiration of ten days after it is created; iPaaS.com auto-deletes messages once their expiration passes. See Message Retention for changing or removing the window. Computed from the transfer time, so always populated; if removed, the message is retained until deleted manually. |
Static |
| Systrack Type | Recommended. Tags every message this collection creates with a fixed origin marker, so SysTrack-raised messages can be distinguished from messages created by any other integration or by iPaaS.com itself. A designed constant, not an example value. The stored value and the field name both use a lowercase t — unlike the SysTrack brand spelling — so any workflow filter that tests for this marker must match the stored spelling exactly. |
Field | Name | SysTrack Sensor Name | Recommended. The common name of the sensor that triggered — for example a disk-space, memory, or application-fault sensor. This is the clearest indication of what the alert is about, and the same name Details composes into its sentence. Because SysTrack does not relate sensor names to automation names, read it as the diagnosis, not the fix. Populated for every triggered sensor. |
Field | Severity | SysTrack Severity | Recommended. SysTrack's own severity rating for the event, a number from 1 (least severe) through 9 (most severe). Separate from the iPaaS.com Message Severity, which is set to None. Workflows that prioritize alerts should read this custom field. Populated for every triggered sensor. |
Field | ResultTime | SysTrack Result Time | Recommended. The timestamp at which the sensor actually activated in SysTrack — the true event time, distinct from MessageCreatedTime. Supplied as text and carried through unchanged; confirm the format the tenant returns in a staging environment before parsing it downstream. Populated for every triggered sensor. |
Field | TriggerCount | SysTrack Trigger Count | Recommended. The number of times the sensor has activated — a running count rather than a count for this single event, so a high value indicates a recurring problem. SysTrack determines the period this count covers; confirm the tenant's window in a staging environment before building thresholds on it. Populated for every triggered sensor. |
Field | SystemId | SysTrack System Id | Required. The SysTrack identifier of the machine on which the sensor fired, and the second half of the external-id link. It is one of the three values Update SysTrack Autofix Run FROM iPaaS.com sends back to SysTrack to target a remediation at the correct machine, so a remediation cannot be dispatched without it. Populated for every sensor event. |
Field | SystemName | SysTrack System Name | Recommended. The friendly display name of the affected machine — its PC name — so alerts identify the device in terms a person recognizes. If SysTrack returns no system detail, the field is left empty and the transfer still succeeds. |
Field | PrimaryUserEmail | SysTrack Primary User Email | Required. The email address of the machine's primary user — the routing identity for the alert, used to notify that person or match them to an iPaaS.com Customer. The mapping filter rejects any event without it, so it is present on every message this collection creates. It is required in the sense that the collection depends on it, not because the iPaaS.com API rejects a message that lacks it. |
Field | PrimaryUserFullName | SysTrack Primary User Full Name | Recommended. The display name of the primary user, so alerts can be presented with a human-readable name. Available only while the user is logged in; SysTrack may return a blank full name for accounts with no display name, in which case the field is left empty and the transfer still succeeds. |
Field | PrimaryUserUserName | SysTrack Primary User User Name | Recommended. The account name of the primary user — the sign-in account SysTrack observed on the device, useful where downstream systems key on account name rather than email. Available only while the user is logged in; left empty when SysTrack returns no value. |
Dynamic Formula | Dynamic Formula | SysTrack Sensor Automation 1 Sensor Id | Required. The value identifying which automation a fix should run against — the first automation in the list. Together with the automation's application value and the machine's system identifier, this is what Update SysTrack Autofix Run FROM iPaaS.com sends back to SysTrack to launch the fix. SysTrack does not relate a sensor's name to an automation's name, so this refers to whichever automation SysTrack listed first for the machine, which is not guaranteed to resolve the issue the message describes; confirm the automation in SysTrack before acting on a one-click fix. The filter excludes events with no automations, so this is populated on every message this collection creates. |
Dynamic Formula | Dynamic Formula | SysTrack Sensor Automation 1 Application Id | Required. The application value accompanying the first automation. This is one of the three values the outbound collection sends back to SysTrack. The integration supplies the same fixed application value on every remediation request, so this field carries an identical value on every message. Populated on every message, as the filter excludes events with no automations. |
Dynamic Formula | Dynamic Formula | SysTrack Sensor Automation 1 Version Id | Optional. The version value SysTrack reports on the automation response — a single stamp carried from that response and shared across every automation on the message, so it is not a per-automation revision number. Not sent back to SysTrack; carried for visibility only. Empty when the event carries no automations. |
Dynamic Formula | Dynamic Formula | SysTrack Sensor Automation 1 Parameters | Optional. The parameter payload SysTrack supplies for the first automation, retained as text so its configuration can be inspected before a one-click fix is approved and so custom workflow logic can branch on it. Not sent back to SysTrack. Empty when the event carries no automations. |
Dynamic Formula | Dynamic Formula | SysTrack Sensor Automation 2 Sensor Id | Optional. The identifier of the second automation on the message, held so the outbound collection can be adjusted to dispatch the second remediation instead of the first. As with the first automation, SysTrack does not relate an automation's identifier to the sensor it resolves. Empty when the event carries fewer than two automations. |
Dynamic Formula | Dynamic Formula | SysTrack Sensor Automation 2 Application Id | Optional. The application value for the second automation. This collection captures up to two automations so a second remediation option is available without a further call to SysTrack. The same fixed application value is used on every request. Empty when the event carries fewer than two automations. |
Dynamic Formula | Dynamic Formula | SysTrack Sensor Automation 2 Version Id | Optional. The version value for the second automation. Because the version stamp is carried from the automation response and applied to every automation on the message, this holds the same value as SysTrack Sensor Automation 1 Version Id wherever both are populated. Empty when the event carries fewer than two automations. |
Dynamic Formula | Dynamic Formula | SysTrack Sensor Automation 2 Parameters | Optional. The parameter payload for the second automation, retained as text so its configuration can be inspected before that remediation is chosen over the first. Empty when the event carries fewer than two automations. |
Dynamic Formula | Dynamic Formula | SysTrack Sensor Automations | Recommended. The complete set of remediation automations attached to the event, preserved as text. Where the numbered fields capture only the first two automations individually, this field preserves all of them, including any third or subsequent automation with no dedicated mapping. This is the field to read when an event offers more than two remediations and a workflow needs to choose, or when troubleshooting which automation was selected. Empty when the event carries no automations, which the filter excludes in normal operation. |
Dynamic Formula |
| SysTrack Sensor Automation Initiated | Required. Seeds the remediation-initiated flag as false when the message is first created — the correct and intended initial state, not an unfinished mapping, because no remediation has yet been attempted. The real value is written later: Update SysTrack Autofix Run FROM iPaaS.com sets it to true after a successful dispatch. Do not seed this field as true. The outbound flow depends on this field existing and being seeded false. |
Dynamic Formula |
| SysTrack Sensor Automation Batch Id | Required. Seeds the batch identifier as unset when the message is first created — the correct and intended initial state, because no remediation has been attempted and there is no batch identifier to record yet. The real value is written later: Update SysTrack Autofix Run FROM iPaaS.com writes the batch identifier SysTrack returns back into this field. Its presence is the record that a fix was launched, and it is what the outbound collection's own filter reads to guarantee the same remediation is not dispatched twice. Do not replace this with a static or computed value; doing so would make the message look as though a remediation had already run and would cause the outbound collection to skip it permanently. |
The Dynamic Formula automation entries above walk the list of automations attached to the sensor event and return the requested value from the first automation (Automation 1 fields) or the second automation (Automation 2 fields), returning an empty value when the event has too few automations. The SysTrack Sensor Automations entry returns the whole list as text. The seed formulas for SysTrack Sensor Automation Initiated and SysTrack Sensor Automation Batch Id return their initial values (false and unset) so the outbound remediation flow starts from a known state; the outbound collection writes the real values back after a successful dispatch.
Error Handling
Error messages this collection can raise — including the connection and authentication errors common to every flow — are cataloged in the SysTrack Error Messages article, under the Add SysTrack Sensor Event TO iPaaS.com flow. Errors appear on the iPaaS.com Dashboard under Integration Monitoring, in the Error Logs. Note that an event excluded by the mapping filter (hidden, no primary user email, or no automation attached) is a silent skip, not a failure, and does not appear in the Error Logs.
Testing & Validation
Test Scenarios
Import an actionable sensor event. Run Manual Sync with the sensor-and-system id of an event whose machine has a logged-in primary user and at least one remediation automation attached, with the Message custom fields created beforehand. Expected outcome: an iPaaS.com Message is created with the generic Text prompt, the Details line naming the sensor, Type set to Other, Severity set to None, a ten-day expiration, and the SysTrack sensor, machine, user, and automation custom fields populated.
Confirm the automation control fields are seeded. On the message from scenario 1, verify SysTrack Sensor Automation Initiated is false and SysTrack Sensor Automation Batch Id is empty. Expected outcome: both carry their seeded initial values, ready for the outbound remediation collection.
Attempt an event with no automation attached. Run Manual Sync with the sensor-and-system id of an event that has no remediation automation. Expected outcome: no iPaaS.com Message is created and no error is raised — the mapping filter excludes the event because its automation list is empty.
Attempt an event on a machine with nobody signed in. Run Manual Sync with the sensor-and-system id of an event whose machine has no logged-in primary user. Expected outcome: no Message is created — the filter excludes the event because the primary user email is empty.
Confirm retention. After importing an actionable event, verify the Message carries an expiration ten days out. Expected outcome: the message is present in the iPaaS.com Message list and is scheduled to auto-delete after ten days unless the ExpirationTime mapping is changed or removed.
Validation Checklist
Only sensor events that are not hidden, have a primary user email, and have at least one automation attached become iPaaS.com Messages.
Events excluded by the filter produce no Message and no Error Logs entry.
The combined sensor-and-system identifier is recorded as the external-id link on every message.
The required Message custom fields exist before the first transfer, or their mappings have been removed — in particular the automation identifiers the outbound remediation depends on.
SysTrack Sensor Automation Initiated is seeded false and SysTrack Sensor Automation Batch Id is seeded empty on newly created messages.
Message retention behaves as expected for the tenant's obligations, with the ten-day window extended or removed where a longer audit trail is needed.
Additional Notes
Creating or deleting SysTrack sensor events is out of scope: this integration reads sensor events and dispatches remediations but does not create or delete them, and the reverse direction executes a remediation rather than modifying, acknowledging, or closing the sensor event that raised the alert. The remediation round trip is documented in the SysTrack Autofix Run From iPaaS.com Mapping Documentation article. For the platform boundaries this collection inherits from SysTrack, see the SysTrack Integration Known Limitations article.