Skip to main content
Actions enable assistants and agents to perform operations rather than just generate text. They are reusable, standardized operations—backed by code, APIs, or services—that any assistant, agent, or workflow can invoke in a consistent way. Once an action is configured, Glean can use it in:
  • Glean agents: Workflow agents that orchestrate actions as part of multi-step flows. For more details, see Introduction to Glean Actions.
  • Glean Assistant: The conversational assistant that can call actions to perform tasks on behalf of users, not just retrieve information.

​
Before you begin

To configure and manage actions, you need:
  • Admin Console access
    You must be able to open the Glean Admin Console. From Glean, go to Admin Console (for an overview, see About the Admin Console).
  • The right admin role
    You typically need an Admin or Setup Admin role to configure platforms and actions. For role capabilities, see Administrator Roles.
  • Connected data sources (for datasource-specific action packs)
    For actions that depend on external tools (such as Jira, Salesforce, or Snowflake), make sure those data sources are already connected and working in Glean.

​
What is an Action?

An Action is a well-defined operation that an AI system invokes to interact with data, applications, or external systems. Instead of hard-coding logic into individual agents, you define an Action once as a shared tool for use across the entire platform. Each Action includes:
  • A unique name: Identifies the capability (e.g., search_documents, create_ticket, send_email).
  • A typed input schema: Defines the parameters the Action accepts.
  • A typed output schema: Defines the structure of the data the Action returns.
  • A technical contract: Explicitly states what the Action does, its side effects, and the errors it produces.

​
Benefits of shared Actions

Using Actions as modular building blocks provides several strategic advantages:

​
Consistency

Actions behave identically regardless of which assistant or agent calls them. For example, create_ticket always generates a ticket using your organization’s standard fields and routing logic.

​
Reusability

You define the Action once and deploy it across various interfaces, including:
  • Customer-facing assistants
  • Internal productivity tools
  • Scheduled background agents
  • Orchestration workflows

​
Safety and control

Actions enforce structured input and output validation. Centralizing permissions and guardrails at the Action layer ensures security remains consistent across all implementations.

​
Simplified maintenance

When you update a process—such as switching a ticketing provider or updating an API—you modify the Action implementation once. Every assistant and agent using that Action receives the update automatically.

​
Action definition and usage

Actions consist of five core components that define how assistants and agents interact with them:
  • Human-readable description: Specifies what the Action does and when to use it.
  • Inputs: Defines parameters, types, and constraints.
  • Outputs: Specifies return types and example payloads.
  • Side effects: Details changes to external systems (e.g., creating a ticket, sending an email, or updating a record).
  • Error behavior: Defines how the Action reports failures.
Platforms may represent these concepts via JSON schema, TypeScript types, or OpenAPI

​
Action examples

The following examples demonstrate Actions shared across various assistants and agents.

​
1. Search documents

Enables assistants to locate relevant documentation.
  • Name: search_documents
  • Example Usage:
    • Support Assistant: Finds troubleshooting articles.
    • Onboarding Assistant: Locates HR and policy documents.
    • Research Agent: Gathers design documents before drafting a summary.
  • Inputs (Conceptual): query (search text), limit (max results), and filters (source or date).
  • Outputs (Conceptual): results[] containing title, url, and snippet.

​
2. Create a ticket

Enables assistants to open tracked issues in a ticketing system.
  • Name: create_ticket
  • Example Usage:
    • Support Assistant: Escalates unresolved user issues.
    • IT Assistant: Requests access or reports bugs.
    • Monitoring Agent: Automatically opens tickets upon system check failures.
  • Inputs (Conceptual): title, description, priority (low, medium, high, urgent), and tags[].
  • Outputs (Conceptual): ticket_id, ticket_url, and status.

​
3. Send an email

Allows assistants to communicate via email on behalf of a user or system.
  • Name: send_email
  • Example Usage:
    • Sales Assistant: Sends follow-up summaries to customers.
    • Workflow Assistant: Emails reviewers with updated document links.
    • Ops Agent: Sends daily error digests to internal groups.
  • Inputs (Conceptual): to[], cc[], subject, and body_markdown.
  • Outputs (Conceptual): message_id and status (e.g., queued, sent).

​
Execution workflow

When an assistant or agent receives a request, it executes the following steps:
  1. Interpret the request: Understands the user’s intent.
  2. Select Actions: Decides which operations are necessary.
  3. Populate inputs: Maps user context into the Action’s input schema.
  4. Execute Actions: Calls the underlying code or API.
  5. Process outputs: Incorporates results into a response or chains them into subsequent Actions.
Because Actions remain shared and stable, you can introduce new assistants or workflows without redefining capabilities. You simply connect them to the existing Action set for orchestration.