Glossary
The terms you'll meet across the academy — roles, apps, connection vocabulary, semantic-layer concepts. One page, alphabetical within each bucket. Linked wherever a term first shows up so you can jump back here for a refresher.
Roles & people
- Admin
- The system role. Manages the whole DashboardFox instance — users, branding, server settings, the Audit App. An instance can have multiple Admins. An Admin can't see app data without also being granted a per-app role on each app — the two grants are independent. See Roles & permissions.
- App Builder
- A per-app role. Shapes the data model: adds tables, builds relationships, configures the report tree, writes formula fields. Usually held by a data lead. Granted at Settings → Security → Apps.
- Composer
- A per-app role. Builds reports and dashboards on top of an App Builder's model. Picks fields, applies filters, makes charts. Most analytics-savvy team members get this on the apps relevant to their work.
- Agent
- A per-app role. Runs reports, opens dashboards, applies prompts, schedules emails, exports. The largest population in most organizations.
- Billing Admin
- A separate flag, not a tier of the role hierarchy. Any user can have it, regardless of their other roles. Manages subscription, plan, invoices, and credit card. Lives in the Billing section of the side panel — not in Settings — so finance staff can manage billing without seeing data.
- Group
- A collection of users used to grant per-app roles or library folder access at scale. Configured at Settings → Security → Groups. Granting a role to a group is equivalent to granting it to every member.
- All Users
- A built-in group every instance ships with. Every existing user and every new user picks up grants assigned to All Users automatically. Useful for company-wide access patterns.
Apps & data sources
- App
- A connected data source in DashboardFox. Each App represents one place data comes from — a database, a spreadsheet, a SaaS API. Apps are the unit users get granted roles on. See How DashboardFox connects to data.
- App display name
- A friendlier user-facing name override for an App. Set in Additional Settings on the data source. Doesn't change the underlying app — just what users see in App Builder, Composer, and the Library. See Additional data source settings.
- Refresh template
- For Excel/CSV-based Apps: the workbook structure (file name, sheet names, column headers) becomes the template the App will refresh against. Re-uploads must match the structure for reports to keep working. See Import Excel and CSV files.
- Append vs Replace
- The two refresh strategies for Excel-based Apps. Replace overwrites all data on each upload — best for keeping the full dataset in the workbook. Append adds new rows to existing data — best for delta uploads. Choice is global to the workbook (applies to every sheet in the same upload). See Update Excel data.
- Active toggle
- On API endpoints: a per-endpoint switch that controls whether the configured schedule fires. ON = schedule runs as set; OFF = schedule paused, configuration preserved. Manual Connect still works either way.
Connections
- Direct database connection
- A live connection to a transactional database (Postgres, MySQL, SQL Server, Azure SQL, Oracle). Queries go to the database every time a report runs, so data is always current. See Connect a direct database.
- ODBC
- Open Database Connectivity. A standard protocol used to connect data warehouses (BigQuery, Snowflake, Redshift, Dremio, MongoDB) to DashboardFox. Each warehouse needs its specific ODBC driver installed first. See Connect a data warehouse.
- DSN (Data Source Name)
- A named ODBC connection profile created during warehouse setup. The DSN captures the warehouse details (project, dataset, credentials) as a single name DashboardFox can reference. Use lowercase letters and digits only — no spaces, underscores, or hyphens.
- API endpoint
- A configured URL DashboardFox fetches data from on a schedule. Used for Google Sheets, SaaS APIs (Salesforce, HubSpot, etc.), or any REST endpoint returning JSON. See Connect an API endpoint.
- response_path
-
The JSON path that tells DashboardFox which array of records to ingest from
an API response. Common values:
values,data,results. If wrong, you'll see metadata tables instead of your data — fix the path and run Purge & Connect. - Purge & Connect
- On API endpoints: a heavy-handed action that deletes existing tables and re-fetches from scratch. Used when the response_path was wrong, or the source's JSON shape has changed. Breaks any reports built on the old table structure. See Manage API fetches.
- Allow Direct SQL
- A data-source-side flag in Additional Settings that authorizes DashboardFox to accept raw SQL against this data source. Half of a two-part switch — the other half is granting users access to the Advanced SQL pre-built app. See Enable advanced features.
- Allow Stored Procedures
- A data-source-side flag that authorizes DashboardFox to execute stored procedures defined in the database. Available only for SQL Server and PostgreSQL. Pairs with the Advanced Reports pre-built app.
Semantic layer & reports
- Semantic layer
- The metadata DashboardFox keeps over your raw data: which fields are visible, what they're called for users, what aggregations they support, how tables join. Built per App in App Builder. See Semantic layer overview.
- App report tree
- The structure of folders, tables, and fields exposed to Composers and Agents when they build reports on an App. Configured by App Builders. See App report tree.
- Advanced SQL (pre-built app)
- A pre-built app that surfaces raw SQL writing for users with the right grants. Composers can write SELECT statements directly against any data source where Allow Direct SQL is enabled. Always exists; access controls who can use it.
- Advanced Reports (pre-built app)
- A pre-built app that surfaces stored procedures as runnable reports. Composers can run SPs on any SQL Server or PostgreSQL data source where Allow Stored Procedures is enabled.
- DashboardFox audit (pre-built app)
- A pre-built semantic layer over the system's own audit data. Useful for understanding usage, security events, and MAU. Admins access by being granted a role on this app, same as any other.
Library & sharing
- Library
- Where saved reports and dashboards live. Organized into folders. Library access is gated by folder permissions, separate from per-app roles — it's possible to be a Composer on an App but only see reports in folders you've been granted access to.
- Folder permissions
- Per-folder access controls in the Library. Folders cascade: if you can see a parent folder, you can see all its subfolders unless explicitly restricted. The third permission layer after system Admin and per-app roles.
- Guest library
- A curated public-facing report space for users who can't log in. Used for customer-facing dashboards, embedded reports on a website, or any "no-login" sharing pattern.
