What Workday Build and Flowise Agent Builder actually are
Workday Build is the umbrella name Workday now uses for its developer platform — the tools for building agents, Extend apps, and orchestrations on Workday, brought together under one developer experience. It launched in September 2025, alongside a "Workday Flowise Agent Builder": a low-code tool, built on the open-source Flowise project Workday acquired in August 2025, for designing, deploying, and managing custom AI agents directly within Workday, from simple conversational experiences to more complex workflows. Workday's own materials describe Flowise Agent Builder as one of several ways to "build agents" inside Workday Build, alongside building apps with Workday Extend and orchestrations with Workday Orchestrate.
Separately, Workday's Agent System of Record (ASOR) is the platform for registering, configuring, monitoring, and retiring agents — Workday-built or third-party — the same way you'd manage a worker's lifecycle. An agent you build with Flowise Agent Builder is a candidate for registration in ASOR; ASOR itself doesn't build agents.
Who can use it, and when
Workday's launch materials said Flowise Agent Builder would be available to customers on Workday Extend Professional in the first half of 2026. Check with your Workday account team whether it is switched on for your tenants. Extend Professional is the higher of Workday Extend's two tiers — Extend Essentials is the other — and already includes Extend Developer Copilot and access to the Workday AI Gateway; Flowise Agent Builder appears to be delivered as a further capability on top of that tier, not a separate purchase with its own public listing.
As of this writing, Workday has not published developer documentation for Flowise Agent Builder on its own developer site (developer.workday.com) — its documentation index currently has no entries for it, Workday Build, or agent building at all. Workday's public guides page instead links out to the open-source FlowiseAI documentation as the reference for the tool itself, alongside its links for Extend, Orchestrate, and EIB. Treat anything below that isn't attributed to a specific Workday page as general orientation, not a confirmed procedure — confirm current detail with your Workday account team or the Developer Site before you commit build time.
What you need before you start
Three things, based on what's confirmed so far. First, Workday Extend Professional — the eligibility tier Workday has named for Flowise Agent Builder. Second, a working Workday Developer Site account and company, the same account structure Extend and Orchestrate already use — if your organization already builds Extend apps or orchestrations, this exists. Third, a real answer to what data the agent should see: an agent that reads Workday data needs the same kind of tenant-side security setup — a security group with exactly the domains it needs, nothing wider — that any integration or Extend app needs before it can be trusted to touch Production.
Workday's own description of the broader Agent Gateway is useful context here even though it isn't Flowise-specific documentation: the gateway is described as giving Workday "a secure, unified control point to manage and meter all agent interactions," including third-party agents, and Workday has said it is adding support for connecting agents to Workday APIs using the emerging industry standard for agent-to-tool connections, the Model Context Protocol, so that agents "no matter where they were built" can reach Workday data through one consistent, governed path rather than one-off integrations per agent.
A sensible first agent to build
Pick something narrow, read-only, and easy to judge as right or wrong — not a workflow that changes data. A good first candidate answers one question a person currently answers by opening a report or a task: "What's the status of my time-off request," "Who approves this business process step," "What's the balance in my healthcare FSA." The agent's job is to fetch the answer and phrase it in plain language — nothing it does should be able to surprise you, because you have not yet built the judgment or guardrails a write-capable agent needs.
Resist the pull to build something more ambitious first. An agent that changes data — creates a request, updates a record, fires a business process step — needs the same review a person taking that action would get: which security group it acts as, what business process or validation catches its mistakes, and what happens when it's wrong. None of that is specific to Flowise; it's the same discipline that applies to any Extend app or integration that writes to Workday, and it's easier to work out once you've built one small, read-only agent and watched it run.
Test it in a Sandbox before anyone else sees it
Workday hasn't published Flowise-specific testing guidance yet, so fall back on the same rule that governs every other kind of Workday build: prove it in a non-Production tenant first, against Sandbox data that looks like Production but isn't Production. Give the agent a security profile scoped to that Sandbox, run it through the exact questions or actions you expect real users to try — including the ones it should refuse or get wrong safely — and read back what it actually did or said, not just whether it ran without an error.
The same testing discipline that applies to Extend apps applies here: a run that completes isn't proof the agent gave the right answer or performed the right action. If you already have a Sandbox refresh and testing routine for Extend apps, extend it to cover agents rather than inventing a separate one.
How this relates to Extend apps and orchestrations
Workday frames Flowise Agent Builder, Extend, and Orchestrate as three ways to "build" on the same platform, not competing choices: Extend for building apps with pages and data models, Orchestrate for automating and connecting processes and data, and Flowise Agent Builder for building agents that can converse and act. In practice, an agent is likely to call into orchestrations you already have — or ones built specifically for it — the same way an Extend app's presentation layer calls into its own orchestration components today. The agent adds a conversational front end; the underlying data access, security, and business process logic still runs through Workday's existing mechanisms, not around them.
Where this connects
If your organization is already fielding questions from an external AI assistant against Workday data, connecting Claude or ChatGPT to Workday covers the access-and-consent pattern that a Workday-native agent will eventually need to match. And whatever you build here still needs proving in a non-Production tenant first — see testing Workday Extend apps for the testing discipline this guide borrows from.
kiweely already tests apps and orchestrations against a real Sandbox tenant and reads back what Workday's own validation says passed, which is the same posture worth building into your first Flowise agent before it goes anywhere near Production.