Key concepts
Short definitions of the entities in Admin as a Service and how they relate to each other.
This page explains the terms used in the interface. A full Vietnamese–English term table is available in the Glossary.
Organization and projects
Section titled “Organization and projects”Organization (tenant)
Section titled “Organization (tenant)”A company’s own space on Admin as a Service. Every account and project belongs to one organization. Each organization is fully separated from other customers’ organizations. The organization is managed by its Owner; only owners can create accounts and projects.
Project
Section titled “Project”The unit of work for a team or a product, for example “Support Tools”. Environments, data sources, actions, views, jobs and the audit log all belong to exactly one project. People only see the projects they are linked to, with an admin, editor or viewer role in each. See Roles.
Environment
Section titled “Environment”A separate copy of the project’s setup, for example dev and prod. Each environment has its own data source connections, variables and secrets, IP allowlist and list of people allowed in. An environment can be marked production; when that environment is selected, the interface shows a red warning. The working environment is selected from the top bar. See Environments.
Inputs
Section titled “Inputs”Data source
Section titled “Data source”A connection to an external system: PostgreSQL, MySQL or an HTTP API. A data source is declared once per project. Its connection details (host, user, password, TLS…) are entered separately for each environment and stored encrypted. See Data sources.
Variables and secrets
Section titled “Variables and secrets”Per-environment values used in actions. A variable ({{$var.KEY}}) is a non-secret value that editors can read back. A secret ({{$secret.KEY}}) is write-only: once saved, nobody can read it back, including admins and the owner. See Variables and secrets.
Operations
Section titled “Operations”Action
Section titled “Action”A predefined operation with a name, slug, parameters, permissions and versions. There are two kinds:
- SQL: one statement run against a PostgreSQL or MySQL data source, in Read-only or Writes data mode.
- JavaScript (JS action): connects to no database and only orchestrates by calling other actions.
There is currently no HTTP action kind. HTTP data sources only store per-environment configuration and support a connection test; actions that call them are not available yet. See Actions and JS actions.
An input of an action, written in SQL as {{paramName}}. Each param has a type (string, number, integer, boolean, date, datetime, enum), a label, a required setting and a default value. The run form is generated from the list of params. Param values are always sent separately from the SQL and are never concatenated into it. See Parameters.
Transformer
Section titled “Transformer”An optional short JavaScript function that transforms an action’s result before it is shown: rename columns, format dates, add links or images. Transformers run on the server in an isolated sandbox with no network access.
Draft, publish and version
Section titled “Draft, publish and version”Every change to an action or view is saved as a draft; drafts cannot run. Publish runs the safety checks and creates a new version. The new version takes effect immediately in the environments the action applies to. Versions can be compared, and you can roll back to an earlier version without creating a new one.
Applies to environments
Section titled “Applies to environments”Actions, views and schedules are created once for the project, then enabled for specific environments. By default, a new action applies to every environment except production. Enabling it for production is a separate step that requires confirmation.
What users see
Section titled “What users see”A custom screen written by an editor in React/TSX that calls the project’s actions. The view editor provides typed autocomplete, live preview and a drag-and-drop builder that generates starter code. Views are also published by version. See Views.
Screen
Section titled “Screen”A published view, seen from the user’s side. A screen appears under Screens when its view is enabled for the selected environment. Screens run with the permissions of the person viewing them. Publishing a view does not grant any additional permission to anyone. See Screens.
Running and tracing
Section titled “Running and tracing”Run (execution)
Section titled “Run (execution)”A single run of an action, started from the Run action page, a screen, a JS action or a job. Run history records the time, who ran it, the environment, duration, row count and any error. The returned data is not stored. See Run actions.
A background run. A job is created when a user selects Add to the queue or starts a Bulk run (many parameter sets in one pass), or when a schedule fires. Adding to the queue and bulk runs are only available for SQL actions in Writes data mode. Jobs show progress and can be cancelled.
Schedule
Section titled “Schedule”Runs a SQL action periodically from a five-field cron expression (in UTC), with fixed parameters. A schedule runs with the permissions of the person who created it or who last re-enabled it. See Jobs and schedules.
Audit log
Section titled “Audit log”An append-only record of every run and every change in the project (actions, permissions, environments, variables, secrets…), including denied attempts. See Audit log.
How the concepts relate
Section titled “How the concepts relate”- An organization has many projects; each project has several environments.
- A data source belongs to the project, but its connection is stored per environment. Variables and secrets are also per environment.
- A SQL action uses one data source and its params, and can read variables and secrets. A JS action calls other actions.
- A view calls actions. Once published and enabled for an environment, the view becomes a screen.
- The Run action page, screens, JS actions and jobs/schedules all go through the same execution path. Each run is permission-checked on the server and written to the audit log.
- Project roles decide who can build which components. Action permissions and environment access decide who can run which action, and where.