Conversation Agent accessing Hidden Explore

Looker Q&A Looker
1

Hello,

Is there a way to make a hidden explore available to Conversational Agent hidden (for Explores)  |  Looker  |  Google Cloud Documentation ?

I am facing challenges when it comes to managing a quite wide explore. I want to be able to run a dedicated agent on top of a more streamlined agent. The idea would be for us to receive a very wide table (~ 500 dimensions) in BQ and then build refinements / extends in different Looker models. This is to handle permission management.

Anybody as manage to crack this challenge (permission management), Not even talking about Agent yet

2

Here is the process we follow:

  1. Build a base Explore that contains all the fields that are needed by data analysts to build Looks & dashboards (our largest Explore contains 800 fields!!!)
  2. Create a new Explore that extends the base Explore, and use the fields parameter to restrict the number of fields to 50-75.

The potential problem with this approach is that you now have 2 versions of the Explore for users to select in the Explore menu. You cannot hide the base Explore. Here is the approach I have taken:

  1. To differentiate the extended Explore from the base Explore in the Explore menu, the extended Explore has a group label “Self-Service - <business unit>” so that it is grouped under a different section, and appears towards the bottom of the Explore menu.
  2. The Explore label is “<base Explore label> (Simplified)” to signify that it’s a simplified version.
  3. The extended Explore has an access grant so that only people with the chat_with_agent permission can see it.

Currently, permissions for agents are not very granular. I would say that permission management and observability have been de-prioritised, as the product team seem to be prioritising new features and improvements (fair enough).

3

Thank you very much for your feedback. This is also the answer I have got from the support.

I beleive this is something they need to sort out…

May I pick you brain the permission on a more horizontal way. How would you manage metrics that should be use by different teams?

4

I believe that you can use the tag parameter in your LookML field definitions to classify fields into functional domains (see post by Google staff in this thread Writing LookML for Agents and Conversational Analytics).

Tags can be used to pass custom metadata to the LLM. Tags can then be targeted in the agent instructions by pairing a specific tag to an explicit instruction. They are primarily used to improve accuracy by shrinking the LLM’s “semantic search space” (i.e. reducing the number of fields that the LLM has to process when scanning the dataset to map terms from the prompt to exact fields). If you use them for domain-scoping (as per below) this forces the LLM to focus only on the fields relevant to user’s domain.

However, if you need to securely manage your fields (i.e. users from department A must never see measures x, y, and z) then you should apply column-level-security to fields in the LookML by using access grants.

Step 1: add tags to your LookML

  measure: revenue_usd {
    label: "Revenue"
    tags: ["finance"]
    type: sum
    sql: (${TABLE}.revenue_usd} ;;
  }

  measure: order_sold_count {
    label: "label: "Orders Sold Count"
    tags: ["marketing"]
    type: count_distinct
    sql:  ${order_id};;
  }

Step 2: create a domain / department user attribute (Admin required)

  1. Create a Looker group called ‘finance’ and add everyone in the finance department into this group. Do the same for ‘marketing’.
  2. Create a user attribute called ‘domain’
  3. Add the finance group, and assign a value of ‘finance’ to that group. Add the marketing group, and assign a value of ‘marketing’.

Step 3: update your agent instructions

Note: I haven’t thoroughly tested this myself, this is just my best guess as to how you would phrase the instruction. When I tested it just now it didn’t work for me, but I think this was mostly because of instruction collision i.e. the instructions conflicted with the golden queries and other default behaviours that I had already defined in my agent instructions. You’ll have to play around with it / raise a support ticket to ask Google for help.

# DEFAULT BEHAVIOURS
- When choosing measures and dimensions to answer the prompt, prioritize fields that contain the tag "{{ _user_attributes['domain'] }}" . Avoid selecting fields tagged for other specific departments unless explicitly requested.

OR if you need a hard enforcement

# GUARDRAILS & CONSTRAINTS
- Domain Scoping: You must restrict field selection to measures tagged with "{{ _user_attributes['domain'] }}" unless the user explicitly requests fields from another domain.