Concepts
Short definitions of the terms STRAX uses, from data systems and mappings to portals, workflows and environments.
How to read this page
STRAX uses a small vocabulary consistently. The terms below are grouped by theme, with one short definition each. They appear throughout these docs and in the product itself.
Connecting
Data system. A database or API registered with STRAX, such as a Splynx installation or a HubSpot account. Each connected system has one record holding its details.
Connector. The support STRAX provides for a family of systems, covering SQL databases and REST APIs. The marketplace lists ready-made connector profiles for popular platforms.
Hub. The central system through which all data flows. The hub holds the canonical copy of the data your systems share.
Canonical model. The hub's single definition of each shared business entity, such as a customer or an invoice. Every source maps onto it, so there is one authoritative version of each fact.
Table and field metadata. STRAX's recorded description of a system's structure, its tables and their fields, discovered from the live source. All integration is driven from this description.
Mapping and movement
Mapping. The alignment between a source system and the hub. It pairs source tables with hub tables, and source fields with hub fields, with a direction for each field.
Ingress. Data movement from a source system into the hub.
Egress. Data movement from the hub back out to a source system. A field can move in either direction, or both, in which case the most recent change wins.
Take-on. The initial bulk load that establishes the baseline. After take-on, only changes travel.
Building
Portal (site). A web application built and hosted by STRAX, composed of pages and modules bound to hub data, with its own users, roles and permissions. Builders call it a site; its users see a portal.
Workflow. An automated sequence of steps that can branch and run in parallel, started by a schedule, an incoming call, a webhook or a data change. Workflows automate processes that span systems.
Query. A saved, parameterised question asked of the hub, usable on its own or as the data behind reports and portal modules.
Report. A formatted PDF built from query-backed sections, produced on demand or on a schedule, optionally emailed.
Copilot. The AI assistant built into STRAX. It understands your estate from its metadata, answers questions about it, and proposes changes, such as suggested mappings, for human approval.
Sharing and governing
Marketplace. The in-product catalogue of importable features: connectors, sample applications and modules published for reuse.
Package. A portable export of selected configuration, moved directly between two STRAX installations.
Environment (staging and production). Portals, queries and reports can exist as an editable staging copy and a locked production copy. Work is tested on staging, then pushed to production, and configuration can be promoted between paired installations the same way.
Where next
What is STRAX? puts these terms together into one picture, and How STRAX works shows the order in which they matter. For real-world settings, see Use cases.
