Reporting, BI & AI

How it works together

There are four ways to get an answer out of Nama, and they are deliberately different sizes.

1. Look. List views with quick filters are the everyday answer — a filtered, sorted list of real records, one click from wherever you were.
2. Design. The report designer builds a defined report from the system’s own entities, without SQL. That report becomes an object with its own permissions.
3. Schedule. A scheduled task runs a report on a timetable and emails it, prints it, or fires notifications when a query returns rows — so the report arrives before somebody thinks to ask for it.
4. Analyse. Business intelligence turns the same live data into dashboards and analysis, without an extract, a warehouse or an overnight load.
5. Ask. The AI assistant answers in language, using tools an administrator defined, executing as a real user under that user’s permissions.

The last point is the one that matters most and is easiest to get wrong elsewhere: the assistant is not given a database connection. It is given a set of tools, each of which runs as somebody with a specific set of rights. What a salesperson can ask it is bounded by what that salesperson could have opened themselves.

Governed, not bolted on

The interesting part of Nama’s AI is the constraint, not the capability. Every answer comes from a tool an administrator defined — a query, a report, an entity flow or a ready-made system tool — and every tool executes inside the same security model as the screens. There is no separate AI permission layer to keep in step with the real one, which is where governed-AI projects usually fail.

The built-in MCP server extends the same arrangement outward: an external AI client connects to the system and gets exactly those tools, under exactly those controls. That is deployed and running at customer sites, not a roadmap item.