[RETIRED] Data Actions

This article has been retired. The information is now in the Looker documentation on this page.

6 Likes

Just started playing around with Data Actions and I have to say this opened up a whole new world of options for the platform… so thank you! Can someone please let us know what you’re thinking about access controls here? Very excited to release this into the wild but obviously can’t allow every user/user group to perform every action available…

also, more robust documentation around this functionality would be super helpful as well.

in case anyone hasn’t seen it, here’s the press release from yesterday with more detail:

and it would be amazing if we could create nested menus for the actions… the list could get very long very fast :slight_smile:

Hi @mplooker - glad you’re excited to check Actions out!

We have some additional documentation in the form of example actions hosted in one of our github repos. There’s one for integrating with Salesforce and one for integrating with GitHub.

As for permissions, the first thing we’re doing there is to introduce a concept called User Attributes, which will be available as of Looker 4.4. User Attributes allow you to associate information with specific users for applications around Looker. For Data Actions, attributes will allow you to store credentials to the tools you’re integrating with (e.g. Salesforce login or GitHub login). That way, you can use the credentialing system that you already have in the tool you’re integrating with to controls how users interact with Actions.

2 Likes

Great. Thanks for the quick response! Does this mean that the actions will be “viewable” by all users but only “executable” by some based on credentials? If so, as a future enhancement, it would be great to limit the available filters by some credentialing scheme as well… so as to minimize the number of inapplicable options a user has to parse through.

It’s possible to make a data action (or drill link) conditionally appear based on any Liquid expression (including referencing other Looker fields).

If the label and/or url returns an empty string after being evaluated by Liquid, the action won’t be available.

  dimension: age {
    type: number
    sql: ${TABLE}.age ;;
    action: {
      label: "
        {% if value > 21 %}
          Order Wine
        {% endif %}
      "
      url: "https://example.com/post"
    }
  }

Whitespace is trimmed from both the label and url so its safe to do multiline if statements or other complex logic.

1 Like

this is awesome. thanks, wil!

Can ya’ll clear up something for me? In the example you provide for the Github action, Looker is able to reference your Sinatra app on localhost. This makes sense if you have access to the machine hosting Looker, but what does this look like if one doesn’t have access to their looker box?

Does one first need to host their application using some service and reference public endpoints in their action dimension? While I’m not a security expert by any stretch, is seems as though sending data across the wire, and even publicly hosting an application of this sort, gets us into potentially risky territory.

Would the suggested architecture, then, be to put the app behind some security layer and have the action first ask the user for credentials and then go about the rest of the action?

Thanks!

Hi @scott.hoover !

The Sinatra application can be hosted anywhere (on-prem, AWS, GCP, etc) as long as the Looker instance has inbound access to it. You can use those system’s tools to wall it off from the rest of the world, if desired, though in order to communicate with Github, it also needs to have outbound access to Github.

One way to do this would be to spin up an EC2 instance in AWS. Close off all inbound access (on port 443) except to the IP address of the hosted Looker instance. Then, you could use user attributes as credentials (and pass those credentials with the action request) so that every action is authenticated with a Looker user’s Github auth token. Here’s a post on how to use User Attributes with Data Actions.

Hope that helps!

1 Like

I like the user-attributes solution. As always, thanks so much for your help, @abbywest !

1 Like

Hi - data actions are cool. One thing that I see time and time again is “list building”, so essentially marketing or communications compiles a list of recipients to send to - based on some data criteria. It’s usually a painful exercise, given the data can be in multiple places, spreadsheets etc.

If you are fortunate to have your data in one place, you can use Looker to build the list of recipients, for your target audience, and Looker makes it easy.

It would be GREAT to be able to click once to perform a “Send to All” type of action using data actions – rather than having to click on each row for each recipient. Has anyone found a way to do this via data actions? Bulk send of a list of addresses/IDs?

Thanks!

2 Likes

Hey Mark, we are actually facing the same issue and it is quite a big problem for us that we are solving through Google Spreadsheets and connecting them to Looker which is really annoying. Were you able to solve you problem in a better way since you’ve originally asked your question?

@Looker_Support do you guys have any good suggestion to Mark’s question?

@Mark_Goodwin @Dimitri_Masin thanks a lot for this suggestion. It’s something that I’ll chat to our product team on. It’d be a super useful feature!

1 Like

@Dimitri_Masin I have not solved this problem. I wonder if the list measure type might help you? It could build a list of emails for you based on any other dimensions/filters that you put in your look. I was actually playing around with this a bit - but you would need to be a separate service that you could send the email addresses to and have that service package up the emails for you.

Another way Looker could do this in their product is perhaps make it a delivery option in a scheduled look or dashboard. Kind of like Webhook, instead it’s an SendGrid email service. Hmmm, now that I’m thinking about it I wonder if you could use the Webhook delivery to SendGrid? Perhaps this might work…would have to research it.

I know Docker is using Webhooks to send data to Marketo to insert as leads so they can be used for marketing campaigns…this could be another option for you as well.