How STRAX Works

The STRAX lifecycle at a glance, from connecting a system through mapping and movement to portals, workflows and monitoring.

Five stages

Every STRAX integration follows the same lifecycle: connect a system, map it to the shared model, let STRAX move the data, build on the result, and observe it running. This page describes each stage at concept level. None of it requires writing integration code.

Connect

You register a system by giving it a name and its connection details. STRAX supports SQL databases and REST APIs, and the marketplace offers pre-built profiles for platforms such as Splynx, NetBox, HubSpot, Shopify and Zendesk.

Once registered, STRAX discovers the system's structure automatically. It reads the tables and fields the source exposes and records them, so you work from an accurate picture of what the system actually contains rather than from its documentation. Discovery can be repeated whenever the source changes.

Map

Mapping aligns the source with the hub's canonical model. Demo ISP, for example, decides that the hub's Customer entity is the single definition of a customer, and then maps the Splynx customer records and the HubSpot contact records onto it.

A mapping pairs source tables with hub tables, and within each pair, source fields with hub fields. Each field is given a direction. The source may own the value, the hub may own it, or both sides may change it, in which case the most recent change wins. The built-in copilot can propose table and field pairings for review, which turns the tedious part of mapping into an approval exercise.

Move

With the mapping described, STRAX generates and maintains everything needed to move the data between the systems. Synchronisation runs continuously in the configured directions, an initial bulk load establishes the baseline, and thereafter only changes travel. You can pace each system's movement so that a busy source is never overwhelmed, and pause or resume an integration without losing data.

The important point is what you do not do. You do not write the synchronisation, schedule it or patch it when a field is added. You change the description, and STRAX regenerates the machinery.

Build

Once the hub holds current, unified data, the delivery features open up:

• Portals are web applications built from pages and modules, bound to hub data, with their own users, roles and permissions. Demo ISP publishes a customer portal showing account, connection and ticket status in one place.
• Workflows automate cross-system processes as a graph of steps, started by schedules, incoming calls, webhooks or data changes.
• Queries and reports answer questions once, correctly, and can deliver a scheduled PDF to an inbox.

Anything built here covers every connected system, including systems added later, because it reads the hub rather than any single source. Portals, queries and reports also support a staging copy, so changes are tested before they are pushed to production.

Observe

Integration you cannot see is integration you cannot trust. The STRAX console shows the health of every connection, the volume of records moving in and out per system, and any errors, on dedicated monitoring pages. An audit trail records who changed what. When something stalls, the console says so plainly, without anyone needing access to a server.

Next steps

The vocabulary used above is defined in Concepts. For worked scenarios, see Use cases, or request a demonstration to walk the lifecycle against your own systems.