Explore & Permissions

Using Explore

Explore is where questions get asked. You pick measures and dimensions and it builds the query.

Where to find it

Architect Panel → Dashboards:

• Explore — the query screen

Architect Panel → Data:

• Query Builder — where a question becomes a saved, reusable query

Asking a question

Choose what you are measuring, how you want it broken down, the period and any filters. Because the joins live in the semantic layer, a question spanning several datastores takes no more work than one over a single datastore.

You can select several measures at once, which is how you compare related figures — cases opened against cases closed, for instance — on one axis rather than in two charts nobody lines up correctly.

Drill down

An aggregate is the start of a question, not the end. Drilling into a figure to see what makes it up is usually where the actual answer is.

A total that looks wrong is very often one large item rather than a broad shift, and drill-down tells you which in seconds — whereas a chart alone will have you theorising for an afternoon.

Top-N

Where a dimension has many values, ask for the top few rather than all of them. A chart of every customer is unreadable; a chart of the top ten with the remainder grouped is a chart somebody can act on.

Compare periods

A single number rarely means much. This month against last, or against the same month last year, turns a figure into information.

Prefer year-on-year for anything seasonal. Comparing December with November tells you mostly about Christmas.

Worked example

A manager asks why complaints rose last month. In Explore they chart complaints by month with gap fill on, see the rise, then drill into the month by service. One service accounts for most of it. Drilling again by complaint reason shows a single reason dominating — a billing change made that month. Three clicks, no query written, and a cause rather than a number.

Save what proves useful

A question worth asking twice is worth saving in the Query Builder. It also means the next person asks the same question the same way rather than approximating it and getting a slightly different number.

Performance

Aggregating a long history is real work. Results are cached, so a repeated question is much faster than the first — but the first still has to run.

• Narrow the period first. Most questions are about recent activity.
• Reduce the number of groupings — each one multiplies the result set.
• Check that dates and the columns you filter on are indexed.

Reconcile before circulating

Tie a new figure to something known before sending it anywhere — the trial balance, last month's figure from the old system, a manual count. A number that has never been checked is a hypothesis, and the first check should not happen in front of the board.

Recommendations

• Drill before you conclude.
• Use top-N on any dimension with more than about fifteen values.
• Save and name good questions rather than rebuilding them.
• Reconcile once, then trust it.

Who Sees What

A query tool that ignored permissions would be a way to read everything, so BI does not.

Where to find it

Architect Panel → Dashboards:

• Explore — access granted like any other screen

Architect Panel → Security:

• Permissions — what each group may reach
• Classification & Clearance — sensitivity controls that also apply here

The permission model still applies

Queries run as the user asking. Somebody who cannot see a datastore cannot query it, and row-level restrictions apply to results exactly as they do everywhere else. Classification and clearance apply too.

Aggregates can still disclose

This is the part worth thinking about carefully, because it is not intuitive.

A count of one, broken down finely enough, identifies an individual. "Safeguarding referrals by ward by month" in a small ward with one referral has disclosed that a referral exists and roughly who it concerns — even though no record was shown and every permission was respected.

Where you report on small populations, think about minimum group sizes before publishing a breakdown, and suppress or widen categories below a threshold. This is a well-understood problem in statistical disclosure control, and the fact that the tool enforced permissions correctly is no defence.

Who should get Explore

Explore is powerful and open-ended. Analysts and managers who need to ask their own questions should have it.

Most people are better served by a dashboard or a record pane answering the questions they actually have. Giving everyone an open query tool tends to produce many slightly different versions of the same number, and then arguments about which is right.

Sensitive datastores

Where casework classification and clearance apply, confirm the behaviour with a test account before opening BI more widely. Ten minutes of checking buys real reassurance, and it is the kind of thing an information governance lead will ask whether you did.

Exports leave the building

Anything exported is outside the permission model from that moment. A spreadsheet on a laptop is not governed by anything you configured here.

Where that matters, restrict export rather than relying on query controls alone — and remember that a scheduled report emailed as an attachment is an export.

Worked example

A council publishes complaints volumes by department monthly. Departments with fewer than five complaints in a month are grouped into "other" before publication, because a single complaint in a two-person team identifies both the complainant and the subject to anyone who knows the service.

Recommendations

• Set a minimum group size for anything published and apply it consistently.
• Give Explore to people who need to ask questions, dashboards to everyone else.
• Test sensitive datastores with a restricted account.
• Treat scheduled email reports as exports when deciding who receives them.