Skip to main content
Custom actions are automations your organization defines in the Glean admin console when built-in actions and action packs do not cover your workflow. Custom actions let you:
  • Call internal APIs or services that Glean does not support out of the box
  • Extend existing systems, for example, a legacy ticketing tool or in-house CRM
  • Run your own business logic before data is written to a system
In Glean they behave like any other action, admins and developers manage and define them in the Admin Console,, builders add them as agent steps, and end users trigger them through Assistant or agents.

​
When to use custom actions

Use custom actions when you need to go beyond built-in actions and action packs. Custom actions are a good fit when:
  • A system is not natively supported: You need to read from or write to an internal tool that has no Glean connector or action pack.
  • You need custom business logic: You want to transform or validate data, enforce rules or approvals, or orchestrate multiple back-end calls behind a single action.
  • You want a tailored Assistant experience: You want Assistant to recognize specific intents, for example, “file an IT onboarding request” and route them to your own workflows with clear trigger conditions and examples.
If a By Glean or By datasource action already does what you need, use it first. Custom actions are for filling gaps, not duplicating standard behavior.

​
Roles and responsibilities

​
Admins

Admins control where and how custom actions run:
  • Enable and manage: In Admin Console → Platform → Actions, decide which custom actions are available in Assistant, agents, or both.
  • Control access: Limit visibility by group or environment, for example, test vs production; choose when to roll out widely or keep limited for pilots.
  • Governance: Ensure actions meet data, security, and compliance policies; coordinate with security and app owners before enabling write operations.
For creation and configuration steps, see Creating Actions in the Developer Portal.

​
Developers

Developers design and implement custom actions in the Glean admin console:
  • Action definition: Display name, description, unique identifier, and type (Action vs Retrieval; Execution vs Redirect).
  • Triggers: Trigger conditions and example queries so Assistant knows when to call the action.
  • API spec: Upload a YAML or JSON spec with a single endpoint, for example, /execute, request parameters (inputs), and required vs optional fields.
  • Authentication: Configure how Glean calls your back-end service securely.
  • Testing: Use the built-in testing tools to test and refine the action.

​
Agent builders

Builders add custom actions as steps in agents:
  • Add the custom action as a step in Agent Builder.
  • Set parameters: fixed values, inputs from the user, or AI-predicted values when appropriate.
  • Combine custom actions with By Glean and By datasource actions in the same workflow.
No code is required for the action itself; builders need to understand what the action does and what its inputs and outputs mean.

​
End users

End users do not manage custom actions directly. They use natural language with Assistant or workflow agents, see confirmations or results when an action runs, and follow the same guardrails, for example, Allow/Cancel dialogs as with other write actions. Custom actions appear as “one more thing the agent can do.”

​
Example: internal IT onboarding action

Goal: Automate creation of IT onboarding requests in your internal IT system. Flow:
  1. Developer:Creates a custom action Create IT onboarding request, uploads an OpenAPI spec for /create-onboarding-request, and defines fields such as employee_name, start_date, manager_email, and equipment_type (enum). Sets trigger examples (e.g., “Create an IT onboarding request for a new engineer”).
  2. Admin: Enables the action for IT agents (and Assistant after testing), scoped to HR and IT groups.
  3. Builder: Builds an “IT onboarding agent” that uses Wait for user input, calls the custom action, and returns the request ID and a link to the internal system.
  4. End user: Asks the agent to “Set up IT onboarding for Alex Chen starting March 1, engineer in the data team.” The agent confirms details, runs the action, and replies with a confirmation, ticket ID, and link.
This pattern applies to compliance approvals, in-house inventory or ticketing, and other back-office workflows that combine several services.

​
Limitations and considerations

  • You need a back-end endpoint: Glean dose not host your logic; you expose an API or URL for redirect that the action calls.
  • Simple, flat input schema: One endpoint with flat parameters; no deeply nested JSON. Supported types: string, number, integer, boolean, and arrays. Use enums and required fields to control values.
  • You own reliability: Slow or failing services affect the action. Use your own monitoring, logs, and debugging.
  • Trigger design matters: Weak trigger conditions or examples can cause Assistant to miss the action or invoke it when it is not relevant. Test and refine with real user queries.
  • Security and compliance :You are responsible for authentication, avoiding inappropriate data exposure, and aligning with internal policies.
For step-by-step setup, see Creating Actions in the Developer Portal.