Opkey took part in Workday Rising 2026, held October 12 to 15 in Las Vegas. The event brought the Workday ecosystem together to discuss where enterprise applications are heading, how AI fits into them, and what HR, finance, and IT teams now need from their systems.
Most event coverage focuses on what was announced on stage. The conversations that stayed with me were different. They were about what happens after the keynote, when a new feature reaches a production tenant that has been running, and changing, for years.
The stage sets the direction, but the tenant sets the pace
Workday’s message was about agents that do real work across HR and finance. That is a meaningful shift, and our customers are paying attention. But the people we spoke with were less interested in the vision than in the next release. They know it will arrive on a schedule they don’t control, and they know some of its changes will break something they depend on.
Almost everyone we talked to already accepted that testing matters. Nobody needed convincing that a release or a new agent should be validated. The real questions were about speed and ownership: how to validate changes without holding up the business, and who on the team should be doing the work.
Testing is accepted. The question is pace.
Nearly every team we spoke with already understood that changes need validating. Their concern was not whether to test but how quickly testing could begin and how much effort it would take from their own people. Teams know changes arrive every quarter, and they want to validate them without business teams waiting on IT or a services queue. In many organizations, a release that takes two weeks to test leaves decisions stalled, and a test library maintained by one person becomes a single point of failure.
Leaders should treat this as an operating model question. Start-up time, the effort needed to understand the tenant, the completeness of coverage, and who can act on results all determine how quickly validation can keep pace with the business. If that work depends on a few people or an outside team, the organization’s pace is set by that dependency, regardless of how capable the platform is.
Teams are tired of rediscovering their own configuration
This came up more than any other topic. Long-running Workday tenants accumulate configuration, policies, and business rules that the current team didn’t create. When a new person needs to test a process, the first step is often a long round of questions to find out how the process works, which rules apply, and what the data should look like.
Teams want that discovery to be faster. They want the tool to read the tenant and show them what is actually configured, rather than asking them to reconstruct it from memory and old documentation. That is a practical expectation, and it changes how testing should start.
Ownership of testing is the real differentiator
Many of the teams we spoke with wanted to see what their tests cover, change them as the business changes, and run them without waiting on someone outside the organization. Those that depend on a vendor queue for every update tend to find that their test coverage lags behind their configuration.
Validating a change has always been the customer’s responsibility, even when partners help with parts of the work. The organizations moving fastest are the ones where that responsibility sits with a team that has the visibility and the tools to act on it.
What this means before you delegate work to agents
Agent announcements raise the stakes. An agent can only act responsibly within a process that is documented as it actually runs, configured to current business intent, governed by explicit controls, validated end to end, and clear about where human judgment is still required.
A common data model gives agents the context they need, but it does not keep that context current. When a budget owner changes or an integration stops carrying a field, the agent keeps working from an outdated picture of the business. That is why enabling an agent should be managed as a change, with its own testing and training, rather than treated as a switch.
Leaders should be able to answer a simple question before any agent goes live: who owns validating this process from beginning to end, and can that team do it without waiting on anyone else?
What we are building
Over the past two years, Opkey has focused on AI-assisted test generation, configuration analysis, and impact analysis. The goal is to put this capability in the hands of customers’ own teams. Test generation helps teams build and maintain coverage. Configuration analysis compares what is set up against what the business needs. Impact analysis shows which processes and tests a change touches before it reaches production.
Customers are seeing results. One county government grew from roughly 100 test cases to more than 900, while requiring less business-user involvement in each cycle. A global financial administration provider reduced IT effort on patch validation by about 75% and business-team effort by about 65%. A construction and infrastructure firm moved from fully manual testing with no tracking to a six-day release validation cycle covering nine modules.
What leaders should do next
Start with your most important business process, not your newest feature. Document how the work actually moves, including the exceptions people handle informally. Confirm that configuration and integrations still match that process. Test the outcome from start to finish, and keep a record of what changed and what was verified.
Then look at your team’s dependencies. If your next release or agent rollout depends on a queue, that queue will set the pace for everything else.
Frequently Asked Questions
An agent acts on the process, configuration, and data it is given. If those have drifted from how the business actually runs, the agent can complete the wrong steps with confidence. Validating the full process end to end, including approvals, integrations, and exception paths, is how teams catch that problem before it affects customers or finance.
Teams need visibility into what their tests cover, the ability to update those tests as configuration changes, and the capacity to run validation without waiting on a services team. Keeping that capability inside the organization is what determines how quickly the business can adopt new features.
Yes. Enabling an agent changes the process it participates in, so it should be managed as a change. That means confirming the process is documented as it runs, checking that configuration matches current business intent, testing the outcome across systems, and training the people who remain responsible for decisions.
Start with one high-value business process rather than the full portfolio. Document how the work actually moves, confirm the configuration and integrations reflect it, define where human approval is required, and validate the outcome end to end. Then repeat the approach for the next process.
At the Workday Rising 2026 event the conversations centered on three things: how to validate Workday releases and changes faster, how to understand configuration that has built up over years, and how to keep testing ownership inside the customer’s own team rather than waiting on an outside queue.
