Auto-code rules define how the platform automatically generates human-readable reference codes for entities. Instead of exposing raw UUIDs to users, entities like customers, orders, and applications get codes like CUS-00042 or ORD-A7K3M.
The database metadata registry is a self-documenting layer built into the platform. It stores human-readable descriptions, comments, and tags for the platform's data structures, giving administrators and developers a consistent place to document what each area of the platform contains and what its fields mean.
A direct permission is an explicit grant that says "this specific user or group has this specific level of access to this specific entity". Where the broader authorization system answers access questions through rules and relationships, direct permissions answer them by being recorded against the entity itself. They are the simplest, most targeted form of access control in the platform and are typically used when a team or individual needs hand-curated access to a particular record.
The document system separates the document definition from its attachment links. A single document can be attached to multiple entities without duplication, and each document maintains its own version history.
Domains let a tenant advertise one or more custom addresses through which users reach their branded experience. Rather than navigating to a generic platform URL, users can access their tenant through a domain that the organisation controls — for example, a subdomain of their own website or a purpose-built portal address.
ETL templates define how external data files are parsed and loaded into the platform. Report templates define how data is extracted and formatted for export. Together they provide the data import/export infrastructure that domain modules use for bulk operations.
The Foundation (FND) module provides the shared platform infrastructure that every other module depends on. It owns no business domain of its own — instead it supplies tenant management, reference data, navigation, job processing, document storage, and other shared services that domain modules consume.
Foundation (FND) is the module that provides shared services consumed by every other module in the platform. It owns no business domain of its own; instead it supplies the infrastructure and starter data that domain modules depend on.
The inbound webhook processor is a generic, multi-tenant system for receiving and acting on HTTP webhook events from external providers. A single receiver endpoint handles all providers and tenants. Each registered webhook carries its own signature validation rules and processing logic, eliminating the need for provider-specific code or configuration files.
The job system provides asynchronous task execution with scheduling, worker management, and notification delivery. Jobs are the primary mechanism for background processing — anything from score recalculation to data imports to webhook delivery.
Labels provide a flexible tagging system that can be applied to any entity in the platform. They complement structured categorisation fields by allowing users to organise and filter records using custom, colour-coded tags.
Reference data provides the controlled vocabularies, enumerations, and master records that domain modules use for dropdown lists, validation, and display formatting. Foundation centralises this data so that every module draws from a single source of truth.
The platform uses a fully data-driven menu system rather than hard-coded navigation. This enables role-based visibility, per-tenant customisation, dynamic schema binding, and hierarchical menu structures that nest to arbitrary depth.
A permission group is a named collection of users that the platform's access control layer can treat as a single subject. Rather than granting capabilities to every user one by one, administrators grant them to a group, and every member of the group inherits the grant. Groups make access policy easier to manage, easier to audit, and easier to change as people join, move between teams, or leave.
Tenant parameters are named configuration settings scoped to a single tenant. They give administrators a controlled way to adjust platform behaviour for their organisation without code changes, and they let the platform deliver tenant-specific defaults, feature toggles, and integration values that modules pick up automatically.
A tenant user is the link between an authenticated account on the platform and the tenant whose data and configuration that account is allowed to act on. Authentication establishes who a person is; the tenant user record establishes which tenant they belong to and what they look like inside that tenant's directory.
The Raytio Platform is multi-tenant: a single deployment hosts many independent organisations side by side. A tenant is the isolation boundary that keeps each organisation's data, users, and configuration separate from every other tenant on the platform.