Go to Subscriptions and click Search Certified Integration Marketplace & Subscribe.

Click the SysTrack integration tile.

Click the Subscribe button.

Enter the name of the subscription and select a version. It can be set to any relevant and unique subscription name within the company where this subscription is created.

Select Create Default Mappings (recommended). If you don't want to create default mappings and want to create all mappings yourself, un-check this box.

Enter the API URL for your SysTrack Cloud region. Use the host of the SysTrack Cloud instance you sign in to, with /api appended.

Enter the CLIENT ID for the same region. See Authentication Configuration below for where to obtain it.

DESTRUCTIVE SETTING — API URL and CLIENT ID. These two 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. Existing links between iPaaS.com records and SysTrack users and messages will no longer resolve, and subsequent synchronization will create duplicate iPaaS.com records rather than updating the originals. Set API URL and CLIENT ID correctly at install and do not change them on an existing subscription. If you are unsure, consult your MiSP (Managed Integration Service Provider) or implementation partner before proceeding — the recovery cost if the change is wrong is significantly higher than the consultation cost.

Enter the USER NAME and PASSWORD of the SysTrack service account. See Authentication Configuration below for where to obtain each value.

Enter the TENANT NAME and the ROPC POLICY, exactly as SysTrack Support supplied them, including case. These two values are structural: iPaaS.com substitutes them directly into the Azure AD B2C sign-in address it calls to obtain a token, so an incorrect value produces an unreachable address rather than a rejected credential.

Enter the API Throttle Limit. This setting prevents any single integration or user from overwhelming the system with too many requests. It protects system performance by controlling the number of API requests that can run in each time window, ensuring fair usage.

Enter the API Throttle Seconds. This defines the time window during which the API Throttle Limit is measured. If an integration makes too many requests within this time window, additional requests are rejected until the window resets.

Enter the API Throttle Limit (To iPaaS) and API Throttle Seconds (To iPaaS). These control the rate at which inbound SysTrack Customer and Message records are pushed into iPaaS.com during polling and transfers, and they are configured independently of the outbound values above.

Enter the number of Concurrent Connections. This specifies the maximum number of simultaneous API connections that the subscription can process for a user or integration. If this limit is exceeded, new requests are queued or rejected until a currently active connection finishes.

Enter the number of Concurrent Batch Executions. This specifies the maximum number of simultaneous batch executions that can be processed for an integration at one time. If this limit is exceeded, new requests are queued or rejected until a currently active batch finishes.

Click Apply to save the settings.

In SysTrack, choose a user whose email address is populated and is not the SysTrack placeholder text "Not collected". Users failing either test are excluded by the collection's mapping filter and produce no Customer record and no error row. Note that user's SysTrack account identifier.

From the iPaaS.com Manual Sync page, initiate a Manual Sync of that user into iPaaS.com as a Customer record, using the account identifier from step 1.

Confirm in iPaaS.com that the expected Customer record was created or updated, with values matching the SysTrack user. The appearance of the Customer record is the success signal. If no record appears, the test has not passed, whether or not any error was logged — re-run with a different user that meets the criteria in step 1.

The Message flow can be checked the same way, with one caveat: only sensor events that are not hidden, whose system has a primary user email address recorded, and for which SysTrack already offers an automation become iPaaS.com Messages. A sensor alert chosen without reference to those conditions may legitimately produce nothing, so a Message test that yields no record is inconclusive rather than a failure. See SysTrack Integration Known Limitations for the full filter behavior.

Review Dashboard / Integration Monitoring / Error Logs. An authentication or connectivity failure produces an explicit error row identifying the failed call and the response received. An empty Error Log is not by itself confirmation of a successful transfer — pair it with the record check in the Data Sync Test above.

Validate field mappings against the imported records, and confirm the values landed in the fields you expect.

Create and configure a polling event for each entity under Integration Monitoring and Diagnostics / Events, setting the cadence there. SysTrack sends nothing to iPaaS.com on its own, so this polling event is what starts inbound transfers; no users or sensor alerts arrive automatically until it is configured and running.

Before enabling the outbound Update SysTrack Autofix Run FROM iPaaS.com collection broadly, validate it against a small, low-risk group of systems. A dispatch runs a real remediation automation on a real endpoint machine.