Definition

The Google Audit Activity trigger starts a flow when a specified Google Workspace audit log event occurs. It allows organizations to track and respond to various user and system activities across multiple Google services in near real time. By leveraging the Reports API, this trigger monitors events such as file sharing in Drive, logins, calendar access, admin actions, Meet sessions, and more.

Key capabilities include:

• Monitoring over 20 Google Workspace applications (e.g., Drive, Admin, Calendar, Meet, Chrome).
• Filtering events based on user email, customer ID, or specific event parameters (e.g., file ID, IP address).
• Supporting granular conditions using filters like parameter==value for precise activity tracking.
• Providing detailed output such as actor identity, event timestamp, IP address, and custom parameters.

This trigger is essential for automating security workflows, compliance enforcement, user behavior analysis, and auditing in a Google Workspace environment.

Example Use Cases

Monitor Sensitive File Access in Drive

Trigger flows when specific Drive documents (e.g., labeled "confidential") are accessed, edited, or shared. Use filters like doc_id==<document_id> to watch particular assets.

---

Detect Suspicious Login Attempts

Automatically run security checks or alert admins when a login occurs from an unfamiliar IP address or geolocation. Useful with conditional run on output fields like Actor.email or IP Address.

---

Track Admin Role Changes

Detect and log when a user's admin privileges are changed. Use application name Admin and event name like CHANGE_ROLE. Conditional logic can route different alerts depending on the user or action.

---

Two-Step Verification Events

Trigger workflows when users enable or disable 2-Step Verification (2sv_enroll or 2sv_disable) to enforce security training or notify the IT department.

---

Calendar Sharing Policy Enforcement

React when a calendar is shared externally by checking Drive or Calendar audit logs. Use conditional filters to determine sharing target or domain.

---

Investigate High-Risk Token Usage

Trigger on OAuth authorize or revoke events to monitor third-party app connections. Use conditional runs based on event_name or app identifiers in the parameters.

---

Flag External Forwarding Setup

Start a flow when email forwarding to out-of-domain addresses is configured. Monitor email_forwarding_out_of_domain in the User Accounts application with filters like parameter==external.

---

Detect Data Export from Data Studio

Catch when reports are exported or downloaded from Data Studio. Combine the trigger with conditions checking the event_name==data_export or user identity.

---

Log Meet Recording Activity

Start flows when a meeting is recorded (recording_activity) or transcription starts. Helpful for logging compliance or archiving meeting metadata.

Configuration

Setting

1. Connection

**What it is:**This is the Google Audit Reports API connection your trigger will use to access activity data from your Google Workspace environment.

**Purpose:**The connection securely authenticates your system to Google’s Admin SDK Reports API, enabling it to fetch audit logs across various services (Drive, Calendar, Login, etc.).

**How to set it:**You must select or create a connection authorized with appropriate scopes (typically via OAuth 2.0 or a service account with domain-wide delegation).Ensure the connection has access to the Reports API.

---

2. Application Name

**What it is:**This specifies which Google service's audit logs the trigger should monitor. It determines the type of events you'll be notified about.

**Purpose:**Selecting an application filters audit events to only those originating from the chosen service (e.g., Drive file sharing, login attempts, calendar changes).

Supported Application Names & What They Represent:

📌 Tip: You can refer to the official Google Admin SDK documentation on application names for more details or the latest supported applications.

---

3. Event Name

**What it is:**The specific event you want to monitor within the selected application (e.g., file shared, login failed, calendar event created).

**Purpose:**This narrows down the trigger to only respond when a certain kind of activity happens—providing precision and avoiding unnecessary trigger runs.

How to use it:

• If you leave it blank, the trigger will fire for all event types within the selected application.

• If you want to target specific events, enter the corresponding event name. For example:

  • edit for Drive edits
  • login_failure for Login issues
  • event_create for Calendar

**Where to find valid event names:**Each application has its own list of supported event names. You can view them in the "Event Name Reference by Application" subsection of this article:👉 See all supported Event Names (Insert actual link when publishing)

---

4. User Key

**What it is:**This defines which user's activity should be monitored by the trigger.

**Purpose:**It helps filter logs by user, allowing you to monitor activity for a single user, a service account, or the entire domain.

How to use it:

• Use an email address (e.g., [email protected]) to filter by a specific user.
• Use all to include all users in your Google Workspace domain.

**When to use:**This is especially useful when you're:

• Monitoring an executive’s account for security.
• Auditing a compromised user account.
• Tracking system-wide behavior across all users.

---

5. Filters

**What it is:**A powerful way to filter events by specific event parameters using logical conditions. It ensures the trigger fires only when certain conditions are met in the audit event details.

**Purpose:**Helps reduce noise and target only meaningful activities (e.g., sharing a sensitive doc, login failures, external file access, etc.).

✅ How to use it

• Use comma-separated conditions in the format:

  parameter_name==value

  Example:

  doc_id==12345,[email protected]

• Supported operators include:

  • == → equals
  • != → not equal
  • <, >, <=, >= → numerical comparison (when applicable)

• Each condition matches against event parameters returned in audit logs. These are dynamic per event and per application. For example:

  • For Drive, you might use: doc_id==1AbcXYZ, visibility==external
  • For Login, you might use: login_type==SAML, status==FAILURE

How to know which parameters are available?

To create effective filters, you should:

1. Review a sample output from the event (e.g., log one event and inspect its parameters).

2. Use the "Parameters" section in each app's audit activity documentation:

   • For example, Drive parameters:Drive Audit Event Parameters
   • You’ll find parameter names like: doc_id, owner, visibility, ip_address, etc.

Best Practices

• Always use == or != for string values.
• Use >/< only when working with numeric or timestamp-like fields (if supported).
• Test with broad filters first, then narrow down.

Example Filters

---

6. Customer ID

**What it is:**The unique Google Workspace customer ID associated with your domain. Required to retrieve audit activity from your Google organization.

How to use it:

• Typically auto-filled or available in your admin console or Google API setup.
• If unknown, you can retrieve it using the Google Admin SDK Directory API

**Why it's important:**Google requires this to scope API access to the correct Workspace environment.

---

Conditional Run

The Conditional Run feature allows you to define specific conditions that must be met for the Google Audit Activity trigger to start the flow. If the trigger event occurs but the defined conditions are not satisfied, the flow is skipped automatically.

This is especially useful when you want to run flows only for certain users, specific event types, or security-related activities — without needing to build complex logic within the flow.

---

🔁 How Conditional Run Works

When enabled, you can define one or more logic-based conditions using AND / OR operators. Each condition consists of four elements:

Condition Type

• When: The flow runs only if the condition is true.
• Except When: The flow is skipped if the condition is true.

Value to Evaluate

Choose a value to apply the condition to. In the context of this trigger, you can use:

• Trigger Outputs such as event_name, actor_email, application_name, or any parameter value
• Vaults — secure, static values like domain names or admin email addresses

💡

For example, use actor_email equals [email protected] to only run the flow for a specific user.

Operator

Determine how to evaluate the condition. Available options include:

• Equals / Not Equals
• Greater Than / Greater Than or Equal
• Less Than / Less Than or Equal
• Between
• Is Null / Is Not Null

Comparison Value

The value to compare against — this can be:

• Another Trigger Output
• A value stored in Vaults
• A fixed value (e.g., "login_failure" or 12345)

---

🧠 Example Conditions for Google Audit Activity

• Run the flow when event_name equals "permission_change"
• Run the flow when actor_email equals "[email protected]"
• Skip the flow except when application_name equals "drive"
• Run the flow when a parameter like doc_id **is not null`

You can combine multiple conditions for more complex logic using AND/OR rules.

---

🔐 Vaults IntegrationVault values are ideal for securely referencing sensitive data like domain names, admin user IDs, or known suspicious IPs in your conditions.

• Vaults are managed under Settings → Vaults
• Vault values cannot be viewed or modified inside the flow
• They can only be securely referenced at runtime

---

This powerful conditional logic ensures your flow only runs when it’s truly needed, increasing both the relevance and efficiency of your automations.

Outputs

When the Google Audit Activity trigger is activated by a matched event, it provides a structured set of output data. These outputs represent the details of the activity and are available for use throughout your flow, including:

• In any following action via the Token Picker
• In the Conditional Run configuration to make decisions based on event data

Here’s a breakdown of each output field:

---

1. ID (Event Identity Metadata)

---

2. Actor (Who Performed the Activity)

---

3. Event Details

---

4. Parameters

Each audit event may contain a set of parameters—key-value pairs that add more context to the event.

You can use parameters in Filters, Conditional Runs, or directly in following actions.

---

5. Owner Domain

---

6. IP Address

---

🔗 Where Can You Use These Outputs?

You can access all these outputs:

• In any action that follows this trigger using the Token Picker
• In the Conditional Run section to create smart, condition-based branches (e.g., only proceed if event_name == "delete" and actor_email != "[email protected]")

---

Example

Scenario: You want to be alerted whenever a file is deleted from Google Drive by a user in your organization.

How to Set It Up:

1. Connection: Select or create a connection to your Google Audit Reports API.

2. Application Name: Choose drive — this limits the monitoring to Google Drive activities.

3. Event Name: Enter delete — this listens specifically for file deletion events.

4. User Key: Set to all to monitor activities across all users.

5. Filters (Optional): Use filters like doc_id==12345 if you only want to track actions on a specific file. Leave empty to capture all deletions.

6. Customer ID: Provide your Workspace customer ID to ensure the data comes from the correct organization.

7. Conditional Run (Optional): Add a condition such as:

   • actor_email equals [email protected]
   • So the flow only runs when John Doe deletes a file.

Result: Now, every time a user deletes a file in Google Drive, the trigger activates and you can automate actions — such as sending an alert, logging the activity in a database, or taking a security response action.