Workday's Developer Guide does not mention Glean anywhere, and Glean is not in Orchestrate's connector catalog. So "using Glean with Workday Extend" is not a feature you switch on. It is one of two integrations you build from parts Workday does document, and which one you need depends on which side is asking the question.

If people work in Glean and want it to look things up or act in Workday, Glean is an external agent and your Extend app supplies tools it can call. If people work in your Extend app and want an answer from content Glean has indexed, the Extend app is the caller and Glean is an external API. The two have very different security models, so it is worth being clear which one you are building before anyone opens App Builder.

Glean calling Workday: register it as an external agent

Workday documents a general path for any agent that runs outside Workday. You register the agent in Agent System of Record (ASOR), configure its skills and security, and the agent calls Workday's MCP server at the Agent Gateway. Workday lists Google Agentspace, Amazon Bedrock AgentCore and Microsoft Copilot Studio as examples of platforms that connect to that one endpoint with the same OAuth credentials. Glean is not on that list. Whether Glean's agents can act as an MCP client to a server you point them at is a question for Glean's documentation, and it decides whether this path is open to you at all.

If it is, the Workday side runs like this:

  1. Set up ASOR in the tenant. Workday notes that external-agent connectivity may need Innovation Services opt-in depending on whether your organization is on the MSA or UMSA subscription agreement.
  2. Register the agent. Today the only way is a POST to the ASOR API (/asor/v1/agentDefinition on the agent gateway), with a definition that names the tools by WID. Workday's page shows how to find SOAP and REST operation WIDs with an Advanced custom report on the Public Web Services and All Public Service Operations data sources.
  3. In the Agent Management Hub, open the agent, enable each skill, choose the security groups in Available To, give the redirect URI for delegate skills, and confirm. Workday shows the OAuth client ID and secret once, on first configuration only.
  4. Activate the agent. Workday creates an Agent System User and an agent security group for it.
  5. Call tools/list on the MCP endpoint with a bearer token. Workday treats a 200 with your registered tools as proof the connection is wired.

Where Extend comes in: Custom Agent Action orchestrations

Delivered agent-ready tools cover Workday's own operations. Anything specific to your Extend app, such as "create an Equipment Request for this worker" or "look up the status of my request", becomes a Custom Agent Action orchestration. You create it from the Custom Agent Action template (name up to 30 characters), write an action description that says what the tool does and when to use it, describe every request property with its format and a sample value, and set an annotation: Read-Only, Destructive, Idempotent or Open World. Once the action is added to the agent in ASOR, the agent can discover and call it through the Agent Gateway.

The descriptions are not decoration. An external agent such as Glean's picks a tool from its description and fills its inputs from the property descriptions, so a vague description is how you get the wrong tool called with a plausible-looking argument. Workday also says its own agents ask the user to approve every call to an action that is not Read-Only; an external platform may or may not do the same, so do not rely on the annotation as your only guard on a write.

Security: whose permissions does Glean act with?

For a delegate skill, the agent uses the OAuth authorization code flow. The user signs in to Workday and allows the agent access, and at runtime Workday checks both the user's access to the agent and the user's access to the APIs the agent calls as tools. The security groups you choose in Available To must also have permission on the domain or business process policies that secure those tools; the View Security for Agent Skill report shows which policies those are.

That is the property you want when Glean answers "what is my remaining time off": the answer is limited to what that user can see in Workday, not what Glean's service account can see.

Two operational details from Workday's pages are worth building for. Workday gives different access-token lifetimes on different pages (60 minutes on the MCP connection page, 14,400 seconds on the ASU considerations page), so have the client refresh on the expires_in it actually receives. And Workday warns that expires_in can arrive as a string or an integer depending on the environment, so the client must accept both.

The A2A alternative

Workday also documents connecting outside assistants to its Self-Service Agent with the Agent2Agent (A2A) protocol, so the outside assistant hands a request to Workday's agent instead of calling tools itself. Workday's worked example is Gemini Enterprise. If Glean supports A2A, this is the lighter option when you want Workday's own agent to do the Workday work rather than exposing your Extend logic as tools.

An Extend app calling Glean

The other direction needs no agent registration. An Extend orchestration can call any external URL it can authenticate to with the Send HTTP Request step, so an Extend page can launch an orchestration that sends the user's question to Glean's search or chat API and returns the result to the page.

Put Glean's token in an orchestration credential rather than in the page: on the orchestration's Settings, Credentials tab, choose API Key and send it in a header, or OAuth with a Cred Store Reference, which Workday recommends for Production. Do not use Send HTTP Request for Workday's own APIs; Workday's reference says those go through Send Workday API Request.

What this direction does not give you is per-user permissions in Glean. The orchestration calls Glean as whatever identity the credential represents, so unless Glean's API lets you act on behalf of the signed-in Workday user, every user of your page sees what that one identity sees. Decide that with whoever owns Glean before you ship it, because a page that searches the whole company's documents as one account is a data-exposure problem, not an integration detail.

Orchestrate's connector catalog does not help here either. Connectors exist only for Extend AI customers, only inside Custom Agent Action orchestrations, and Glean is not one of the listed services.

Which to build

Build the external-agent path when the people are in Glean and you want Workday's security to decide what each of them gets. Build the outbound path when the people are in your Extend app and Glean is a content source, and accept that Glean's side decides what comes back. For the in-app version, the page and orchestration pattern is the same one described in building a chatbot in Workday Extend, with Glean as the endpoint instead of a model provider. For the ASOR side, connecting a custom agent to the Workday system of record and Agent System of Record security go deeper on registration and permissions.

Whichever you build, test it as two different users with different Workday access and compare the answers. If they match where they should differ, the integration is using one identity for everyone.