Data sources

A data source defines which table or dataset from a database connection is exposed for reporting. Data sources are required before reports and analyses can be created.

1. Open Data sources

• You can access data sources in two ways:
• From the main menu, open the settings menu (gear), go to Admin, and select Data sources
• From a database connection, open the relevant connection and switch to the Data sources tab

2. Create a new data source

• Click Data source in the top right corner
• Select New data source
• In the dialog, fill in the required fields:
• Table name: select a table from the dropdown

Tip

Selecting the table first will automatically populate Name and Key

• Name: a human readable name for the data source
• Key: a unique identifier for the data source
• Data connection: select the database connection to use

3. Save and continue

• Click Save and open
• You are redirected to the data source page, where you can start building reports and analyses based on this data source

Choosing the dimensions

The Dimension card on the data source page lists the dimensions built on the table. The pencil opens a window with one line per dimension, plus one line per table column that is not a dimension yet. The green plus turns a column into a dimension, the red minus deletes one after the usual confirmation, and Name, Expression and Visual group are edited in the window itself.

Save keeps the window open, so going through many rows is one window and several saves. Closing with unsaved changes asks whether to save, discard or keep editing.

A dimension whose key no longer matches a column — because the column was renamed or removed in the database — keeps its own line at the bottom, without a type. It still works in the reports that use it, but it is a sign that either the dimension or the table needs attention.

Names in more than one language

The grid has two name columns: Name (standard) and one for a single language, chosen in the picker above the grid. Standard is the name a report falls back to when the language has none of its own, so an empty cell means no translation — not an empty name. Set the filter to Missing translation to list the dimensions that lack one.

The name belongs to the dimension, not to the report. Change it, and every report using that dimension shows the new name, in each language you filled in.

Tip

Run the language picker once per language you maintain. An administrator who works in English can still go through the Norwegian names — the picker does not follow the menu language.

Describing the columns

The data source page has a Column card listing every physical column of the table. Most columns need nothing: the type comes from the database, and the column is visible to everyone who may read the source. Switch a column on to say something more about it. Three settings matter:

Setting	What it does
Publish as	How the Data feed delivers the column. From database type is the default. Date turns a timestamp that only ever carries a day into a plain date; Date and time keeps the time of day for a column the database stores as a date
Personal data	Marks the column as personal data and which kind: name, e-mail, phone, address, birth date, person id, id, org number or free text. This drives what an AI assistant is allowed to see, see below. It does not change what your own users see
Access level	Hides the column from users below that level. It is gone from the Data feed and from assistants, and asking for it by name is an error, as if the column did not exist

Switching a column off deletes its settings again. Only the columns you changed are stored.

Tip

Mark personal data before opening a data source to an assistant. A column with no mark is treated as ordinary data, however sensitive its content.

Opening a data source for writing

A published data source is read-only until you open it. Opening it lets a dashboard app save what its users change — planning figures, overrides, comments, a lock on a finished period. Only a data source feed can be written; a report’s own Data feed is a projection of the data and stays read-only whatever you set here.

Four settings on the data source page:

Setting	What it does
Write access	Which actions the Data feed opens, one step at a time: No writes (the default), Update existing rows, Update and add rows, Update, add and delete rows. Deleting sits at the top on its own — it is the one change no later data load can undo
Write filter	An optional guard, written in the same [field] syntax as the filter above it. [budget_locked]=0 is a locked budget period. Rows it hides stay readable but cannot be written, and its column becomes the lock the dashboard sets and lifts. An AI assistant sees the column’s name, never the filter or the values that lock
Access grant comment	Required before writing can be turned on. Write down who asked for it and why; the change is recorded in the field log
Filter	The ordinary row filter. It also applies to every write, so it decides who may edit which rows — a department manager editing only their own department is one filter here, not a role per department

Under the write access setting Insight shows the key it would use, with Re-check and Details. Changing one row needs a key the database itself confirms: a primary key, or a unique index where no column may be empty. Without one, only whole-selection changes work. Add the key in the database and press Re-check — it takes effect at once.

Note

The two fields are labelled OData write access and OData write filter in the current UI.

Caution

While writing is open, the write target is frozen: the source’s key, connection, table, filter and write filter cannot change, nor the connection’s address, user or startup SQL. Otherwise a permission already granted would end up pointing at a different table or a different set of rows. Set write access back to No writes to move any of them. The connection password can still be rotated.

A user also needs a permission per action, granted on a role and scoped to this data source. The actions and the exact strings are listed in Writing data from a dashboard app.

Tip

Turning write access on says “this is an input table”. It is not a claim that the table tolerates a write: an ETL-loaded table technically does, but the next load silently drops the change.

Checking what an AI assistant can read

A data source can be opened up to AI assistants, so they can help build reports and dashboard apps against real data. How far that goes is set per data source, and you can see the result before you rely on it.

Open the data source and choose Preview. The dialog has a mode selector at the top:

Mode	What you see
General	The raw source under your own access. Always available, published or not — this is the one for building reports
Data feed	The published feed, and its access settings
MCP	Exactly what an AI assistant receives

The last two only appear once the data source is published.

In MCP mode the dialog asks the same service the assistant does, so what you see is what it gets — including refusals.

The Data tab lists one row per field, with its statistics — smallest and largest value, and how many distinct values it has — and the sample rows as columns beside them. A wide data source therefore makes the list longer, not wider.

The Access tab lists the settings in force: the feed address, the exposure level, and the limits on sample size and row count.

The exposure level decides how much leaves the data source:

Level	Effect
None	Nothing. Structure only — no sample rows, no statistics
Masked sample	Sample rows and statistics, with every value masked
Sample	Sample rows and statistics as they are, except columns marked as personal data, which are still masked
Query (personal data as tokens)	The assistant may run its own queries, but every column marked as personal data is replaced by a short random token such as ⟦pii:k3v9x2qa⟧
Query	The assistant may run its own queries and sees everything as it is

Masking replaces a value with a made-up one of the same kind: a name becomes another name, an e-mail another e-mail. A token is different: it stands for one real value, so the assistant can send it back in a filter or a change (“update the customer ⟦pii:k3v9x2qa⟧”) and Insight looks up the real value on its side. The same value gets the same token for as long as it is in use, in every data source. A token that has not been used for 30 minutes is forgotten, and the assistant is told to read the row again. The real values never leave the server. Free-text columns marked as personal data are left out entirely at every level below Query, since there is no token or mask for a note.

If the level is too low for sample rows or statistics, the dialog refuses them the same way the assistant is refused.

Letting an AI assistant change Insight’s own records

Insight’s own records — issues, projects, milestones and the like — can be opened to an assistant the same way, one entity per data source row on the default connection. Reading is governed by the exposure level above. Changing is a separate switch on the same row, MCP write access: No writes (the default), Create, Update or Create + update. Turning it on requires the Access grant comment, like the Data feed, and the change is recorded in the field log. The assistant also needs the api-mcp:create / api-mcp:update permission and the user’s ordinary right to change that entity.

Personal data is protected per column, not per entity. A column marked as personal data is never written through an assistant: a change that names such a column is refused before anything is saved, and the preview (dryRun) is refused the same way. The other columns of the record can be changed. An issue, for example, can be moved to another milestone or product version, while its description and closing description — free text that may hold personal data — stay closed. A token such as ⟦pii:k3v9x2qa⟧ is never accepted as a value either: the assistant can filter on it, but not write it back.

Note

Rows are read under your own access. A colleague with different row access would see different rows, and so would an assistant acting for them.

Tip

Worth doing before opening a data source to an assistant for the first time. The sample columns are the quickest way to spot a field holding something you did not intend to share.