Skip to main content

What are actions?

Actions are primitives in Glean to help you interact with your applications in real time. Instead of only finding information, Glean can complete tasks end to end such as creating tickets, updating records, sending messages, or running queries directly from a conversational request. At a high level, an action is a reusable operation that runs in an external app or data system. Behind the scenes, each action knows what it needs and what it returns, so Glean can run it safely and reuse the results in a flow. Glean uses actions to:
  • Read data: fetch issues, run queries, or pull live data from an app.
  • Write or update data: create or update records, pages, or documents.
  • Orchestrate across tools: for example, draft an email and post a link in Slack or Teams.

Connectors vs actions

  • Connectors index content so Glean can search it.
  • Actions call apps and APIs directly to read live data or make changes.
You can use both together. For example, search Confluence via Glean’s index, then use a Confluence action to create or update a page.

Where to use actions

Actions show up across several Glean experiences. You ask for an outcome and the assistant or agent decides which actions to run and in what order.

Assistant

In the main Glean app, the Assistant uses actions while you chat. Typical tasks include:
  • Export answers to Google Docs or Sheets.
  • Send summary emails.
  • Create or update Jira tickets.
  • Run Snowflake queries and explain results.
  • Send messages in Slack or Teams.
You stay in a single conversation and the Assistant chooses and runs the actions.

Workflow agents

Workflow agents are structured, reusable flows backed by actions. They are useful for repeatable processes, such as:
  • Creating a follow-up Jira ticket and sharing the link.
  • Drafting a project update in a Google Doc and posting the link in Jira.
  • Pulling metrics from a data warehouse and routing them to the right channel.
End users see the agent as an option they can run. The individual actions remain hidden behind the flow.

Autonomous Agents

Autonomous Agents use actions in the background based on triggers or policies that you configure once. Examples include:
  • Keeping records in sync between systems.
  • Enforcing policies by updating fields or statuses.
  • Running periodic checks and posting summaries.
Users do not call individual actions and auto agent uses actions automatically to keep systems up to date.

Glean in X

With Glean in X, for example, Slack, Teams, or the browser extension, actions are available wherever you work:
  • Ask Glean in Slack or Teams to create a ticket, post a summary, or look up account details.
  • Use the browser extension to update records or create content in place.
The experience is the same, you describe the outcome, and Glean calls the right actions.

Action sources

Actions can come from three main sources:
  • First-party actions (By Glean): Built and maintained by Glean.
  • MCP actions (By datasource): Actions exposed by tools that integrate with Glean through MCP, so you can call their APIs through Glean.
  • Custom actions: Actions your organization defines in the Glean admin console for internal or niche workflows.
Many first-party actions are grouped into action packs, for example, Salesforce Actions, Snowflake Actions. Action packs are bundles of related actions for a given app. Admins enable and authenticate actions from these sources in the Glean admin console.

Action behaviors and execution

This section focuses on how actions run and what they do, independent of where they show up or where they come from.

Read vs write

  • Read (retrieval) actions: Fetch information from external apps, even if Glean has already indexed some of that data.
    Examples: run a SQL query in Snowflake, fetch live metadata from Jira or Salesforce.
  • Write (operational) actions: Create, update, or post data in an external app.
    Examples: create a Jira issue, update a Salesforce record, post a message in Slack or Teams.
Many flows follow a read → reason → write pattern: pull context with a read action, let Glean decide what should happen next, then apply changes with a write action.

Execution vs redirect

  • Execution actions: Run inside Glean. The Assistant or agent calls the external API and returns a result or confirmation in the same conversation.
  • Redirect actions: Open a URL or page in the external app so you can finish the task there, for example, a Jira issue form or a Google Doc in the browser.
Both types respect your existing authentication and permissions.

Actions lifecycle and roles

Every action follows a similar lifecycle, with different roles responsible for different parts:
  1. Admins
    • Enable and authenticate actions in the Glean admin console.
    • Decide which apps expose actions and how each app is authenticated.
    • Choose which write actions can run in-line versus always show a confirmation.
  2. Builders of workflow agents
    • Choose which actions each workflow agent can use.
    • Define step instructions and how parameters are filled (fixed values, user input, or AI-inferred).
    • Decide when to use explicit steps versus Plan and execute for a given flow.
    Builders configure how actions are used inside workflow agents. They do not need to configure individual actions for Assistant, Auto Agents, or Glean in X.
  3. End users
    • Ask the Assistant, a workflow agent, or an Auto Agent to complete tasks in natural language.
    • Provide any missing inputs when prompted, for example, which account, which project, or date range.
    • Review confirmations and results, often with links back to external systems.
End users never manage action definitions directly. They interact with Glean and Glean decides which actions to call.

Security and governance for actions

Actions follow your existing security and connector model, and admins retain fine-grained control.

Permissions and app guarantees

  • Actions use the same permissions and authentication you configure for each app.
  • If your account cannot perform an operation in a tool such as Jira, Salesforce, or Google Workspace, Glean cannot do it via an action.
  • Glean logs action usage and aligns with your connector and security configuration, so actions automate what users already do in those tools, within the same access boundaries.

What admins control

In the Glean admin console and related security settings, admins can control:
  • Which apps expose actions and how they are authenticated.
  • Which first-party action packs are enabled for the organization.
  • Which write actions can run in-line versus always show a confirmation dialog.
  • Which workflow agents can use which actions, often in partnership with builders and security teams.
This lets admins balance productivity and safety while giving users powerful, real-time actions across their tools.

Glean Protect and AI security

Actions work within the same AI safety framework as the rest of Glean:
  • Prompt injection protection helps prevent malicious content from forcing agents to run unexpected or unsafe actions.
  • Agent guardrails keeps actions within the scope admins and builders define like data sources, operations, destinations.
  • Glean Protect policies and controls keep sensitive data within approved boundaries and ensure actions use only the permissions and content you allow.

For admins

For end users