The following are the known limitations of the iPaaS.com SysTrack integration. They are inherent to the current design of the integration and to the capabilities of the SysTrack platform, and they apply to all subscribers at the time this documentation was written.

This integration is built for SysTrack, the endpoint monitoring and remediation platform from Lakeside Software. Subscribers connect it to their SysTrack cloud tenant at https://cloud.lakesidesoftware.com/api, authenticating with a SysTrack service account issued by SysTrack Support and linked to the tenant. See the SysTrack Installation Instructions and SysTrack Connections and Settings articles for the full list of subscription settings and where to obtain each value.

SysTrack does not publish a versioned public API namespace for this interface.

Built and reviewed against the documented production endpoints on the SysTrack cloud host as of 2026-07-20. Because SysTrack offers no sandbox or test tenant (see Limitation 9), this review was performed against the endpoints the integration calls and the integration's own configuration rather than end-to-end against a live tenant.

Not built for:

SysTrack does not expose any relationship between a triggered sensor's name and an automation's name. Only the identifiers required to run an autofix are available. When a sensor event is imported, the integration attaches whatever automation identifiers SysTrack returns for the affected machine, and the outbound path dispatches those identifiers when the message is transferred back.

Because the names cannot be correlated, a message raised for one sensor may carry an automation intended to resolve a different sensor's issue. The value carried in SysTrack Sensor Automation 1 Sensor Id therefore cannot be assumed to remediate the condition described in that message's alert text.

What this means for you: If you present these messages to end users as one-click remediation, do not present the transfer as a guaranteed fix for the alert the reader is looking at. Before enabling automatic outbound transfers, confirm in SysTrack that the automations available for your estate address the conditions your sensors actually report, and validate a small set of sensor-and-machine pairs. Where the risk of running the wrong remediation is unacceptable, route the message through a human review step, or restrict the outbound collection to a curated set of sensors using a mapping filter. This is a SysTrack platform capability rather than a configuration you can change in iPaaS.com; if the correlation matters to your workflow, raise it with your iPaaS.com partner channel so the requirement can inform future enhancement releases as SysTrack's capabilities evolve.

The only outbound operation this integration performs is a remediation request. Update SysTrack Autofix Run FROM iPaaS.com asks SysTrack to run an automation for a sensor that has already fired; it does not write field values onto a SysTrack sensor result, system record, or any other SysTrack object. On success, the integration updates exactly two values on the originating iPaaS.com Message: SysTrack Sensor Automation Batch Id and SysTrack Sensor Automation Initiated.

What this means for you: Editing a SysTrack-originated Message in iPaaS.com does not change anything in SysTrack. If you need a field in SysTrack to reflect an iPaaS.com value, that is not something this integration does. The upside is that there is no unmapped-field overwrite risk on the SysTrack side — because no SysTrack record is replaced, no SysTrack field is cleared by a transfer. Note also that the batch identifier SysTrack returns confirms the remediation was accepted and queued; it does not confirm the automation finished or that it resolved the underlying condition. Check the outcome of each run in SysTrack.

SysTrack users are imported into iPaaS.com as Customer records, and there is no return path. Creating, updating, and deleting SysTrack users from iPaaS.com are not part of this integration, and there is no FROM iPaaS.com counterpart to the Add/Update SysTrack User TO iPaaS.com collection.

What this means for you: SysTrack is the system of record for user data. Changes you make to a Customer record in iPaaS.com stay in iPaaS.com, and will be overwritten by the SysTrack values on the next inbound transfer of that user. Corrections to a person's name, email address, or account number must be made in SysTrack.

Deletion is not implemented for either SysTrack users or SysTrack sensor events. Deleting a user or a record in SysTrack does not remove the corresponding iPaaS.com Customer or Message, and deleting a Customer or Message in iPaaS.com does not remove anything in SysTrack. The Customer Deletion and Message Deletion events registered on the subscription have no effect.

What this means for you: Records removed on either side must be reconciled by hand. If a person leaves your organization and their SysTrack user is removed, the iPaaS.com Customer remains until someone deletes it. Plan a periodic reconciliation if the accuracy of the iPaaS.com roster matters to a downstream process.

An email address is required on the iPaaS.com Customer record, and SysTrack does not require an email address on every user. The Add/Update SysTrack User TO iPaaS.com collection therefore carries a mapping filter that admits a user only where the SysTrack email value is populated and is not the literal SysTrack placeholder text "Not collected". Users that fail either test are skipped before any transfer is attempted: no Customer record is created or updated for them, no error is raised, and nothing accumulates in the Error Logs.

What this means for you: Users whose SysTrack email address is missing or unresolved are simply absent from iPaaS.com, and their absence is silent rather than reported. Before relying on the iPaaS.com Customer roster as a complete view of your estate, check how consistently email addresses are populated on the users in your own SysTrack tenant, and compare the SysTrack user count against the imported Customer count after your first full polling cycle. Populating the missing addresses in SysTrack is the durable fix — a user skipped today is imported automatically on a later cycle once the address is present. If a set of users legitimately has no email address and you still need them represented in iPaaS.com, discuss the filter with your MiSP, bearing in mind that iPaaS.com requires an email address on the Customer record.

SysTrack stores one display name per user rather than separate name parts, and falls back to the username where no display name has been collected. The integration derives FirstName and LastName by splitting that display name on spaces and taking the first and second parts positionally.

The split is positional, not semantic. A user recorded as "Mary Anne Smith" is imported with the last name "Anne", not "Smith". The two fields fall back differently. A display name with no space produces the placeholder text LastName in the last-name field, while the first-name field receives the whole display name. Where no display name has been collected at all, both fields receive their respective placeholder text, FirstName and LastName. So a user whose display name is a single word imports with that word as the first name and the literal LastName as the surname. Where SysTrack has fallen back to the username, the name written to iPaaS.com may be a domain-qualified account name rather than a person's name.

What this means for you: Do not rely on these two fields for anything that requires an accurate surname — correspondence, matching against another system, or alphabetical reporting. If accurate name parts matter for your use, ask your MiSP to adjust the FirstName and LastName mappings to a splitting rule that matches your organization's naming conventions, for example taking the last space-separated part as the surname. Consistent display names in SysTrack are the prerequisite for any such rule working reliably.

The SysTrack Primary System OS value written to an iPaaS.com Customer is taken from the first device associated with that user in SysTrack, and SysTrack Primary System Id and SysTrack Primary System Name are taken from the same device. A user associated with several devices is therefore described in iPaaS.com by one device only, and which device that is depends on the order SysTrack returns them.

What this means for you: Treat SysTrack Primary System OS as an indication rather than a complete inventory. If you support users who routinely work across a desktop and a laptop, or across Windows and macOS, the iPaaS.com Customer record will not reflect that. Where a full device inventory is needed on the iPaaS.com side, SysTrack remains the place to look it up. Subscribers whose workflow depends on multi-device coverage should raise it with their iPaaS.com partner channel, so the requirement can inform future enhancement releases.

The SysTrack Primary System Action 1 Id, SysTrack Primary System Action 2 Id, and SysTrack Primary System Action 3 Id fields, their Name counterparts, and the corresponding Profile 1 fields are drawn from the tenant-wide catalogue of sensor actions. The integration narrows that catalogue by one criterion only: the operating system of the user's primary device. It then records the first three entries of the narrowed list on the Customer.

Because the operating system is the only narrowing criterion, two users whose primary devices run the same operating system will normally carry identical values in all of these fields. The values indicate which remediations exist in the tenant for a machine of that operating system. They are not per-user recommendations, and they are not derived from anything that user has experienced.

What this means for you: Do not build segmentation, scoring, or reporting logic that assumes these fields differ between users, and do not read a value here as evidence that a particular remediation is relevant to a particular person. Where you need to know which remediation applies to a specific condition on a specific machine, the automation fields on the imported Message carry that association instead. If you need these fields narrowed by something other than the operating system, discuss it with your MiSP before building a process on top of them.

SysTrack provides a single production environment per tenant. There is no separate sandbox or test tenant available for trialling this integration, so every transfer you make while validating your configuration reads from — and, on the outbound path, acts on — live production data and live endpoint machines.

What this means for you: Plan your validation accordingly. Use Manual Sync against a small, deliberately chosen set of users and sensor-and-machine pairs before enabling scheduled polling across your estate. Run the first scheduled poll during a quiet period. Treat the outbound remediation collection with particular care: a dispatch runs a real automation on a real endpoint, so validate it against a small, low-risk group of systems before enabling automatic outbound transfers broadly.

The Add SysTrack Sensor Event TO iPaaS.com collection carries a mapping filter with three conditions. A sensor event is imported only where it is not marked hidden, where the primary user of the affected system has an email address recorded, and where SysTrack returned at least one automation for that sensor result. A sensor event that fails any of the three is skipped without an error.

The third condition is the one with the broadest effect. Sensor events for which SysTrack has no remediation configured — and sensor events on a machine that was not reporting to SysTrack when the poll ran, so that no automation could be looked up — do not reach iPaaS.com at all.

What this means for you: The messages in iPaaS.com are the subset of your SysTrack sensor activity for which a one-click remediation exists, not a complete alert feed. Do not use the iPaaS.com Message list as a monitoring or reporting view of everything happening in your estate; SysTrack remains the place to see the full picture. Because a machine that is offline at poll time produces no automation, an alert can be absent from iPaaS.com on one cycle and present on a later one. If you need alerts to arrive regardless of whether a remediation is available, ask your MiSP to relax the automation condition on the inbound filter — and be aware that messages imported that way carry nothing for the outbound collection to dispatch.

The Add SysTrack Sensor Event TO iPaaS.com collection sets ExpirationTime on each imported message to ten days after the message is created. iPaaS.com deletes a message automatically once its expiration passes, so SysTrack-originated messages are removed from iPaaS.com ten days after import without any action on your part.

What this means for you: Any downstream process that reads these messages must run within the ten-day window, and any record you need to keep beyond it must be copied somewhere else before it expires. Expiry is not reversible — once a message is removed it cannot be recovered from iPaaS.com, though the underlying sensor result remains in SysTrack for as long as SysTrack retains it. If ten days does not suit your support process, subscribers or their MiSP can change the ExpirationTime mapping to a different window, or remove the mapping altogether so that messages are retained until you delete them. Choose the window with your own operational needs in mind, and note that removing the mapping means SysTrack alerts accumulate in iPaaS.com without bound.

SysTrack does not send outbound notifications or webhooks to iPaaS.com, so there is no inbound event stream for iPaaS.com to subscribe to. New and changed users and sensor events are discovered only when the integration polls SysTrack, on the cadence set by a polling event you configure under Integration Monitoring and Diagnostics / Events. The delay between a sensor firing in SysTrack and its message appearing in iPaaS.com is therefore determined by that interval, and no transfers happen automatically until a polling event has been configured and is running.

What this means for you: Choose the polling interval that matches how quickly your support process needs to see an alert, balanced against the request volume described in Limitation 13. Where you need a specific alert or user immediately, Manual Sync imports a single record on demand without waiting for the next poll. Because SysTrack does not offer notifications, polling is the correct shape for this platform rather than a gap in the integration.

The scheduled user poll retrieves the SysTrack user directory in full on every cycle, rather than only those users changed since the previous cycle. Each user import also performs several follow-up reads against SysTrack for the associated devices and the applicable sensor actions, so the request count grows with the size of your tenant. The email filter described in Limitation 5 reduces how many users are transferred into iPaaS.com; it does not reduce how many are retrieved from SysTrack. SysTrack does not publish a documented request quota for this interface.

What this means for you: On a large SysTrack tenant, allow for this when choosing a polling interval — a short interval multiplies the request volume against the tenant. Review the concurrent connection and concurrent batch execution values on your subscription before your first full run, avoid running large Manual Sync batches at the same time as a scheduled poll, and do not schedule polling to coincide with other intensive SysTrack processes. Confirm the volume on your first cycle before settling on a permanent cadence.

The iPaaS.com Customer record is replaced in full on every update rather than partially patched. The Add/Update SysTrack User TO iPaaS.com collection maps CustomerNumber, FirstName, LastName, and EmailAddress, together with the SysTrack custom fields covering the primary system and its sensor actions. Any other value held on that Customer — a comment, categories, or address fields, for example — is overwritten with an empty value on each inbound transfer unless a mapping is added to preserve it.

What this means for you: This matters most where the same iPaaS.com Customer records are also maintained by another integration or edited by hand. To retain a value through a SysTrack transfer, ask your MiSP to add a Dynamic Formula mapping that reads the existing iPaaS.com value back from the destination record and writes it unchanged. Review the full set of fields your Customer records carry before enabling this collection against an existing iPaaS.com dataset.

Update SysTrack Autofix Run FROM iPaaS.com carries a run-once mapping filter: a message is eligible for dispatch only while SysTrack Sensor Automation Batch Id is unset. When a remediation is accepted, SysTrack returns a batch identifier, the integration writes it to that field, and sets SysTrack Sensor Automation Initiated to true. The filter then excludes the message, so a repeat dispatch of the same remediation is prevented automatically.

The guard depends entirely on that one field. SysTrack Sensor Automation Batch Id and SysTrack Sensor Automation Initiated are seeded when the message is created — the batch identifier is left unset and the initiated flag is set to false — and clearing or editing the batch identifier afterwards, by hand or by another process, makes the message eligible for dispatch again on the next outbound run.

What this means for you: Treat these two fields as control data rather than as ordinary custom fields. They are how you tell at a glance which alerts have already been actioned, and the batch identifier is also what you quote in SysTrack to trace a run. Do not clear them as part of a bulk edit or a data cleanup, and do not let another integration write to them, or an endpoint may receive the same remediation twice. Both fields must exist as iPaaS.com Message custom fields before the first outbound transfer, because the filter and the write-back both depend on them.

Whether a remediation is offered for a message is determined when that message is imported. If an automation becomes available in SysTrack after the message was imported, the existing message is not updated to reflect it. SysTrack's own sensor severity is carried onto the SysTrack Severity custom field, but the iPaaS.com Message Severity field itself is set to a single fixed value on every import.

The alert text presented to the end user is likewise fixed rather than derived from the sensor: every imported message carries the same Text value, "We have noticed an issue on your machine would you like us to try to fix it?", while the sensor is named in the Details field as "Sensor {Name} has been triggered".

What this means for you: Re-import an alert through Manual Sync to pick up an automation that has since become available. Because the iPaaS.com Severity field does not vary, do not use it to prioritize SysTrack alerts — prioritize on the SysTrack Severity custom field or on the sensor name instead. Where you need the alert text to name the sensor or the machine, subscribers or their MiSP can adjust the Text mapping to build a message from the values already carried on the record.

The SysTrack integration does not offer initialization, the bulk import of all existing records when a subscription is first connected. There is no first-run backfill that loads the SysTrack user directory or the historical sensor events as a one-off operation. Records arrive only through the scheduled polling described in Limitation 12 and through Manual Sync.

What this means for you: Plan the first polling cycles as the mechanism by which your existing SysTrack data reaches iPaaS.com, and expect the first message poll to be materially larger than later ones because it carries no lower time bound. Where a larger historical set needs to be loaded than polling provides, use the documented bulk sync approach described in syncing a large dataset using iPaaS.com and Postman Runner.

DESTRUCTIVE SETTING — API URL and CLIENT ID. These two subscription settings together select which regional SysTrack Cloud tenant the subscription reads from. Each regional host is a separate tenant with its own independent identifiers, so changing either value on a subscription that has already imported records repoints the subscription at a different record namespace. The existing external-id links between iPaaS.com records and SysTrack users and sensor events no longer resolve, and subsequent synchronization creates duplicate iPaaS.com Customer and Message records rather than updating the originals.

Both values are set once during installation. Set API URL and CLIENT ID correctly at install and do not change them on an existing subscription.

What this means for you: If you are investigating duplicate iPaaS.com Customer or Message records that appeared after a settings change, check whether API URL or CLIENT ID was edited on the subscription. If a regional move or a tenant change is genuinely required, consult your MiSP (Managed Integration Service Provider) or implementation partner before changing either value — the recovery cost if the change is wrong is significantly higher than the consultation cost. The two values must always name the same region as each other; the Cloud ID shown on the SysTrack Tenant Information page identifies which region a CLIENT ID belongs to.

Two shipped mappings carry literal fallback text that is scaffold rather than real data. Review both before enabling transfers in production.

The above 18 limitations describe the current scope and behavior boundaries of the iPaaS.com SysTrack integration. For detailed per-collection technical documentation, see the mapping collection descriptions available from each mapping collection in the iPaaS.com portal — Add/Update SysTrack User TO iPaaS.com, Add SysTrack Sensor Event TO iPaaS.com, and Update SysTrack Autofix Run FROM iPaaS.com — together with the SysTrack Installation Instructions and SysTrack Connections and Settings articles in the iPaaS.com Help Center.