Looker Studio
Analytics & DataManage Looker Studio assets and their sharing permissions through the Looker Studio API. Agents provision report access as people join or leave a team, so dashboard permissions follow the org chart instead of drifting from it.
What This Integration Enables
Read the action list before reading the marketing. There are four operations and none of them build anything. You cannot create a report through this API, you cannot read a chart, you cannot change a filter, and you cannot pull the numbers a dashboard displays. What you can do is find out which reports and data sources exist, and control exactly who can open them. That narrowness is not a gap in the connector. It is what the Looker Studio API is, and it is the reason this connector is worth having.
Treat Looker Studio as an access surface rather than a BI tool and the whole integration snaps into focus. Reporting permissions are the part of a company's access posture that nobody owns. A finance dashboard gets shared with a contractor for one project. An analyst leaves and their reports keep running, owned by a person who no longer has a badge. A revenue report gets opened to allAuthenticatedUsers during a board prep scramble and is never closed again. None of that shows up in an identity provider review, because Looker Studio sharing lives outside it. Search Assets and Get Asset Permissions turn that invisible drift into something an agent can read on a schedule, and Add Asset Permissions and Revoke Asset Permissions let it be corrected without a person clicking through share dialogs one report at a time.
The member model is worth understanding because it is where the exposure hides. Every permission entry is a prefixed identifier, and the connector applies the prefix for you based on a member type: a user becomes userByEmail, a group becomes groupByEmail, a whole domain becomes domain, and a service account becomes serviceAccount. Two tokens are different in kind. allUsers means anyone at all, and allAuthenticatedUsers means anyone with a Google account. Those two are not permissions granted to a person, they are the absence of a permission model, and an agent that reads them out of Get Asset Permissions is the cheapest data-exposure check a reporting stack can have.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Offboarding that actually reaches the reports
An employee's last day is recorded in the HR system. Suspending their identity closes the front door, but their Looker Studio reports do not disappear, they just become reports owned by a suspended account. The agent calls Search Assets with Owner set to that person's address, then walks the results with Get Asset Permissions to establish what they hold on each one. Viewer and editor grants come off immediately through Revoke Asset Permissions, because removing someone's ability to read a report they no longer work on requires no judgment. Ownership is a different matter, and the agent does not touch it. It assembles the list of owned assets, with titles and last-modified dates, and hands it to a manager who names a successor.
A standing link-sharing audit
Once a week the agent runs Search Assets across the workspace and calls Get Asset Permissions on every result, looking for exactly two strings in the returned member lists: allUsers and allAuthenticatedUsers. Any asset carrying either one is a report that anybody who finds the URL can open. The agent posts the list with the asset title and owner attached, and the owner decides whether the openness was deliberate. This is the check that is trivially easy to describe and almost never actually performed, because doing it by hand means opening every dashboard in the workspace and reading a dialog.
Provisioning that follows the org chart instead of trailing it
A new analyst joins the revenue team. Rather than waiting for them to ask for access one dashboard at a time over their first fortnight, the agent reads the team's standing report list, calls Add Asset Permissions once per asset with the Viewer role and the new hire's address, and confirms the result. Because Add Asset Permissions grants without disturbing what is already there, running the same provisioning flow twice is harmless. The better version of this uses a group rather than a person: grant groupByEmail once, and membership changes in the group carry the access without any Looker Studio call at all.
Human-in-Loop Highlight
The gate on this connector sits on Revoke Asset Permissions, and specifically on revoking an owner. The action does exactly what its description says: it removes a member from an asset entirely, whatever role they held. That is unremarkable for a viewer and mildly inconvenient for an editor. For an owner it is a different class of event, because the only route back is Add Asset Permissions granting ownership to somebody else, and that route has to be taken before the revoke, not after. Take it in the wrong order on an asset with a single owner and you have a report the team depends on with nobody able to administer it. There is no create action in this API and no ownership-transfer action either, so an agent that gets this wrong cannot repair it, and neither can the next agent you point at the problem.
That is a clean division of labour rather than a limitation, and FlowRunner is built around drawing it. The agent does the tedious and unambiguous work: it enumerates the workspace with Search Assets, resolves the real role on every hit with Get Asset Permissions, strips the viewer and editor grants a departing person no longer needs, and produces a short list of the assets where the answer is genuinely a decision. Then it stops. Through the channel the team already uses, it asks the named manager: "Priya leaves Friday. She is the sole owner of four reports, including Q3 Revenue by Segment, last edited two days ago. Who inherits each one? I will grant the new owner first and revoke Priya second." Nothing is revoked until that answer arrives, the successor is granted before the predecessor is removed, and both calls are recorded against the person who authorised them.
This is what Orchestration as a Service means in practice on a four-action connector. The agent is not being supervised because it might misbehave. It is being stopped at the one point where the platform it is calling offers no way back, so that a human-in-the-loop makes the only decision on the page that carries consequences. Everything either side of that moment runs unattended.
Agent Capabilities
4 actionsAssets
1- Search Assets Searches the connected user's Looker Studio assets, meaning reports and data sources, and returns a page of matches with resource name, title, asset type, owner, creator, timestamps and trashed state. Filter by asset type, title, owner and creator, and page through results with Page Size and Page Token. Owner and Creator accept an email address or the literal `me` to match the connected account. Note that the API returns metadata only, so report internals such as pages, charts, filters and dimensions are not available here. This is the discovery step for every access workflow: run it with Owner set to a departing employee, or unfiltered to sweep the whole workspace.
Permissions
3- Get Asset Permissions Retrieves the sharing permissions for a single report or data source and returns the members grouped by role as OWNER, EDITOR and VIEWER. Each member is a prefixed identifier such as `userByEmail:[email protected]`, `groupByEmail:[email protected]` or `domain:example.com`, and the special tokens `allUsers` and `allAuthenticatedUsers` indicate link sharing rather than a named grant. Use Search Assets to obtain the asset name first. This is the action that makes a scheduled access review possible, and the one that surfaces open link sharing.
- Add Asset Permissions Grants one or more members a role on an asset without disturbing the permissions already in place. Choose the role to grant as Owner, Editor or Viewer, the member type as User, Group, Domain or Service Account, and the list of members to add. Plain email addresses are enough, because the connector applies the required API prefix automatically, and entries that already carry a prefix or use the link-sharing tokens are passed through unchanged. Returns the updated permissions. Because it is additive, re-running a provisioning flow does not damage existing access.
- Revoke Asset Permissions Removes one or more members from an asset entirely, revoking whatever role they currently hold. Provide the member type and the list of members to remove, with prefixes applied automatically as they are on the add side. This does not delete the asset, and it returns the updated permissions so a flow can confirm the result. Revoking a viewer or an editor is routine. Revoking an owner is the operation that belongs behind an approval, because the connector offers no way to restore ownership after the fact and no way to recreate the asset.
Frequently Asked Questions
What can FlowRunner do with Looker Studio?
FlowRunner agents can run Search Assets, Get Asset Permissions, and Add Asset Permissions in Looker Studio, plus 1 more action.
Does connecting Looker Studio to FlowRunner require OAuth?
Yes. Looker Studio connects to FlowRunner with OAuth 2.0, so agents authenticate without handling raw credentials.
Can Looker Studio trigger a FlowRunner workflow automatically?
Looker Studio doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Looker Studio
$100 in credits. No card required. Connect in minutes.