Allowing non-developer ( business ) users to create views and use them in models and dashboards

(Pruthviraj Shivanna) #1

Dear Community,
I have the below requirement and I have thought a lot about it from multiple angles and couldn’t come up with a decent solution. Hence I am asking the question here.

Current scenario:
Our Datawarehouse is in BigQuery and we use looker to to expose the data marts via explores and models to business power users who create dashboards based on it.

Only the developer team has the developer access to create views and alter models in the project.

Now we have a requirement where power users are asking for more access, so that they can import smaller reference tables ( Tables based on google sheets etc ) in a view and expose that in model.

So below is my dilemma,

  • How can I let the business users create views in looker without having the privileges to mess up the rest of the setup ?
  • Is providing them with developer access the only option ?
  • I dont want to create a new project and new connection since that would still not solve the issue they face where they want to import and join the reference data with in that project.

Thanks a lot for all your help.


(Ian) #2

a little bit of overhead for your developers but it will ensure nothing is totally screwed up with inexperienced hands in the code

(Pruthviraj Shivanna) #3

Thanks @IanT for the response, yes we have already integrated Git, I was wondering if there was a way to separate and limit what they can change with in the same project.


(Jonathan Palmer) #4

Hi @Pruthviraj_Shivanna,

I think @IanT was probably flagging up using Pull Requests within Looker specifically to ensure quality control on amendments made outside of your dev team, rather than just Git integration itself.

The other suggestion I’d make is using extending to separate out the core dev team only model from satellite tables that can then be joined to the extended model. I don’t think you can guarantee that no one edits the core model (as far as I’m aware you can control query permissions on a per-model basis but not LookML edits) but this architecture can help keep VIP assets clearly and cleanly separated from assets that require more freedom, without code duplication.



(Ian) #5

Cross project extend and then you can separate the core model permissions, will likely have to remake content unless you keep the same model and explore names.

(Izzy) #6

Quick addition to this good advice: I think you’ll definitely have to remake content, as model names have to be unique across the entire instance, even if there are multiple projects in play.

(Ian) #7

If the core code is stripped out and the existing model and explores extend and include code from the new core models/explores project (which has restricted dev access), then you can avoid it but it is a bit of an overhaul and it means repurposing your current project for a free for all project (with pull requests on).
I might do a write up of the setup we have as we extend twice for the very reason the OP talks of and for multi tenancy.

(Izzy) #8

Oh, that makes sense in a complicated sort of way haha.

Would love to read that write up, go for it!