Analyzing data

Everything that processes and forms store in Pantarey lies in tables, one per data schema. Four tools access these tables, with the same data and the same permissions, but for different questions: the quick question in a conversation, the one-off evaluation with export, the permanently visible KPI and the spontaneous question on a dashboard. This page helps with the choice.

One data basis, four ways in

Tool	Typical question	Result	More
AI assistant (Claude, ChatGPT, …)	“How many vacation days are approved for December?”	Answer in the conversation, as a table or chart on request	Working with the assistant
Data analytics	“All orders of the quarter per supplier, as Excel for purchasing”	Table in the browser, export as CSV, Excel or JSON	Data analytics (SQL)
Dashboard	“How many invoices are open today?”, every morning	KPI, table, chart, Kanban, permanently on one page	Dashboards
AI query on a dashboard	“Revenue per customer this year”, once, spontaneously	Number or table, without setting up a widget with SQL	AI query

For individual records, the Database is the shorter way: search, open, edit. For the run of a process, that is who completed which step when, the Process Explorer.

What applies to all tools

Tables are named after the data schemas. The technical name of the data schema is the table name (urlaubsantraege, vacation requests), the technical names of the attributes are the columns (von, bis, status). In addition, every table has the standard columns id, data_schema_id, document_name, created_at, updated_at, created_by and updated_by.
Two tables per data schema. name also contains the records of all subordinate data schemas, name_only only those of the data schema itself. Without sub-schemas, both return the same; see Inheritance and hierarchies.
Permissions apply everywhere. Decisive is the permission Query of the data schema. Whoever may see only certain records gets only those in every evaluation; sums and counts refer to them. Details under Permissions and actions.
One SQL notation. Data analytics, dashboard widgets and the assistant speak the same SQL dialect. What to keep in mind for dates, numbers and empty values is described once under SQL in widgets and applies everywhere.
Read only. Evaluations never change data. Changes are made in the Database, in forms or by processes.

Questions to the AI assistant

A connected assistant knows the tables, writes the SQL query itself, runs it and explains the result. Examples as they work in the docs tenant:

“How many vacation days are requested per status?” → table with status, count and sum of working days.
“Which material orders came in this week, and who created them?”
“Show me the five customers with the highest open invoice amounts, as a chart.”
“How many instances of ‘Rechnung erstellen’ (create invoice) failed this month?” → process statistics instead of SQL.
“Which query did you use for this?” → the assistant shows the SQL, which can be copied into Data analytics or a widget.
“Create a KPI for this on the dashboard ‘Musterfirma’.” → in developer mode it builds the widget.

For this, the assistant uses the tools list_tables, query_records and get_query_result, for individual records search_data_objects and filter_records, for processes process_stats. It sees only what the connected account may see. More under Working with the assistant and in the list of tools.

Evaluations in forms

Forms also access the tables so that the right values are available while filling in:

Reference field with SQL filter: The selection list of a reference field is narrowed down by a query, for example only projects with status “offen” (open) or only customers of the user's own region. See Reference field with SQL filter.
Table field: A form shows the result of a query as a table, for example the previous orders of the selected supplier. Placeholders such as {{lieferant}} are replaced by the values of the form while filling in; export works as in Data analytics.
Load values: An invisible field runs a query when the form is opened and makes the result available to the other fields, for example the remaining vacation and the part-time model of the person for the field Working days. Placeholders such as @currentUserEmail insert the signed-in person.

All three run with the rights of the person filling in the form.

From trial to KPI

A typical path: the question is first put to the assistant or tried out in Data analytics. Once the query is right, it moves into a dashboard widget and is available there every day. For this, Data analytics shows the finished SQL query, which can be copied into a KPI, Table or Chart widget; a connected assistant can also create the widget directly.

Controlling permissions and approvals

Who may evaluate what is set in three places, and all tools adhere to them:

Roles of the user under Users → Manage users → Permissions: Data queries (predefined) or Data queries (ad hoc) open Data analytics; the MCP roles allow the assistant, there ad hoc is the prerequisite for SQL. Dashboards are assigned to individual users or groups in the Dashboard Designer.
Permission “Query” per data schema in the Data Designer: Without it, the table is missing in Data analytics, in the assistant and in widgets. With Only for certain records, each person sees only their part, for example their own requests or customers of their own region, and that in every evaluation, including sums. Denies take individual records out again. See Permissions and actions.
Via AI (MCP) in the same permission: A schema can remain evaluable in the app but be blocked for assistants, for example employee data. The block also applies to SQL queries of the assistant. See Permissions for AI assistants.

In addition, there are the switches of the account under Users → AI assistants → Limits & switches: The main switch can turn assistants off entirely, approvals and limits per hour concern writing and building; pure evaluations need no approval. Every call is recorded in the log prio_mcp_usage_statistics, which administrators query in Data analytics. Only they see system tables with prio_. Whether a person may see something and why is explained by the tool explain_access or by the Data Designer in the Permissions tab.

Example: Employees may evaluate their own vacation requests, the HR department all of them, and the assistant must never see salary data. In the schema “Urlaubsantrag” (vacation request), the group Employees gets the permission Query with the condition Created by equals user's email, the group HR without condition. In the schema “Gehalt” (salary), everything is deselected under Via AI (MCP). Data analytics, dashboards and the assistant then behave the same.

Example

Management wants to know how many vacation days are requested per status. First attempt in Data analytics: SELECT status, COUNT(*), SUM(arbeitstage) FROM urlaubsantraege GROUP BY status. The figures are right, so the same query goes onto the dashboard “Musterfirma” as a chart. Whoever has a different question in between asks the assistant.

Frequently asked questions

Which tool needs which role?

Data analytics needs one of the roles Data queries (predefined) or Data queries (ad hoc), dashboards are shared per dashboard, the assistant needs the MCP role and, for SQL, additionally Data queries (ad hoc). What is shown is in every case decided by the permission Query of the data schema.

Why does the assistant show different figures than the dashboard?

Mostly it is the question, not the data: a different period, status “beantragt” (requested) counted or not. Run the SQL query of the widget and the answer of the assistant side by side in Data analytics, then the difference becomes visible.

Are there evaluations across several data schemas?

Yes, via JOIN over reference fields, for example invoices with their contacts. This works in Data analytics, in widgets and with the assistant alike.

Next step

Data analytics (SQL): find tables, write queries, export results.