The ease-of-use award skips the real question
HR Executive gave Sana from Workday a 2026 Top HR Product of the Year award earlier this week, and Workday's own announcement credits the win to innovation, functionality, ease of use, and value to HR organizations. Those are fine reasons to hand out a trophy. None of them tell a Workday security lead what actually changed this year, and something did.
The detail that matters sits lower in the release. Sana now runs more than 300 self-service skills across areas such as pay, time, and absence, and it connects to systems including Gmail, Slack, and Salesforce. Read that twice. A skill built to answer a pay question can now act somewhere that is not Workday at all.
Three hundred skills is a lot to audit
A skill count that high did not exist a couple of product cycles ago, and each one carries its own scope of what an employee, or an agent acting on that employee's behalf, is allowed to see and touch. Pay and absence data sound routine until you remember that absence requests run through manager approvals and pay questions touch bank details and garnishments. Multiply that by 300 and the question stops being whether the assistant works and becomes who signed off on each of those scopes, and who checks that list every quarter.
Workday's own Extend platform already taught this lesson. Anyone who has sat through governance work before the first custom Workday app ships knows how fast a permission model grows once builders start shipping fast. Three hundred vendor-built skills is the same growth, just built by Workday instead of your own admin team. Workday's own adoption numbers suggest customers are turning these features on quickly, which is exactly when a scope review gets skipped.
Reading a manager's Gmail carries different risk than reading a Workday field
A skill that reads a field inside Workday answers to Workday's own security groups, its own audit trail, its own data residency commitments. A skill that reads a manager's Gmail inbox to answer an HR question answers to whatever OAuth scope Google granted it, logged wherever Google Workspace logs it, retained on whatever schedule Workday and Google separately agreed to. Those are not the same control, and an ease-of-use award does not say which one a customer is getting.
The same question runs the other direction. A skill that writes into a Salesforce record, say a note on a rep's comp plan or a change to a manager's reporting line, is now an actor inside Salesforce that Salesforce's own validation rules, sharing rules, and audit history have to account for. If that write collides with a flow your revenue operations team built, whose log gets checked first, and does anyone outside HR even know the skill exists.
What Workday calls governed only covers what Workday controls
Hellermark's quote in the release is worth sitting with. Workday's Chief AI Officer said, "For AI to transform HR, it has to understand the context, rules, and workflows that keep businesses running... Sana brings that intelligence into one simple experience, helping employees find answers and take action while enabling organizations to automate HR work in a trusted, governed way." That is a real claim about the workflows inside HR. It says nothing about what happens once a skill's action lands in a system Workday does not operate.
That is the practical line a security lead has to draw for their own leadership. Inside Workday, governed means Workday's audit log, Workday's role model, one vendor's breach notification obligations. Reaching into Gmail, Slack, or Salesforce means three more admin consoles, three more sets of OAuth scopes, three more places a departing employee's access has to get pulled. The pattern shows up in the real difference between a connector and an integration: a connection that reads as one clean feature in a demo is actually several separate trust relationships stacked underneath it.
What to confirm before you turn on a Gmail or Slack skill
Before any of these 300 skills goes live for a population bigger than a pilot group, ask Workday for the exact OAuth scope each connected skill requests, not the marketing description of what it does. Ask whether the skill functions as a distinct service account inside Gmail and Slack or under the employee's own identity, because those two produce very different logs when someone asks whether the assistant sent that message or a person did. Ask who owns revocation when an employee changes roles or leaves, and whether that revocation runs instantly or on the next scheduled sync.
Then find your Slack and Google Workspace admins before HR schedules the rollout meeting, not after. The same discipline that keeps Workday's own agents running on deterministic rails needs to reach whoever owns the Slack app directory and the Google Workspace marketplace approvals, and right now that is probably not the person who signed off on the Sana skill list. Give agents a real way to get switched off fast too, because a skill writing into three outside systems needs a way to get shut off across all four platforms at once, not just Workday's own admin console. An award for ease of use makes a nice headline. The sign-off meeting for 300 skills touching three outside systems is the one that actually needs to happen this month.
