The Irony of "Best Practices" in Workday Security

“Best practice” is one of the most comforting phrases in a Workday implementation.

It suggests that there is a proven path. A clean answer. A standard way to configure the system that reduces risk, avoids unnecessary complexity, and sets the organization up for long-term success.

And sometimes, that is true.

Best practices can be useful. They create guardrails. They help project teams avoid obvious mistakes. They give organizations a starting point when they are making hundreds of design decisions under tight timelines. In Workday Security especially, there are plenty of patterns that exist for good reason: avoid unnecessary custom security groups, keep access explainable, document exceptions, minimize over-provisioning, and design with auditability in mind.

But the irony is that the same “best practices” sold during an implementation often fail after go-live.

Not always because the original advice was bad. Not always because the configuration was poorly designed. And not always because someone made a reckless decision.

Often, they fail because they were treated as universal truths instead of contextual design principles.

And in Workday Security, context is everything.

Best Practices Are Starting Points, Not Universal Answers

My general philosophy is that there is no such thing as a universal best practice, outside of some obvious dos and don’ts.

There are better practices. There are common patterns. There are lessons learned. There are design choices that are usually cleaner, safer, and easier to maintain.

But the right answer is almost always: it depends.

That can sound evasive, but in enterprise systems it is usually the only honest answer.

Security configuration depends on the business. It depends on the HR operating model, organizational structure, support model, reporting needs, regional privacy requirements, audit posture, risk tolerance, and leadership culture. It depends on how work actually gets done, not just how the system would ideally like work to get done.

A security model that works beautifully for one organization may be completely unworkable for another.

One company may be able to maintain a highly standardized role-based model with very few exceptions. Another may operate in a matrixed, global, heavily regulated, or unionized environment where the “clean” model breaks almost immediately. Some organizations have business requirements that technology can influence. Others have requirements that are effectively immutable.

And when a rigid system design goes against those requirements, the design usually loses.

The business finds a workaround.

The Go-Live Gap

A Workday Security model can look excellent during implementation.

It may have clean role assignments, consistent naming conventions, limited custom groups, and carefully documented design principles. The implementation team may have agreed to a clear philosophy: use delivered functionality where possible, minimize exceptions, keep access aligned to delivered roles, and avoid unnecessary customization.

On paper everything makes sense, until you go live.

New business units are spun up. Leaders reorganize their teams. HR support models change. Acquisitions happen. Regional requirements surface. Reporting needs become more urgent. Managers ask for access that was not anticipated. Support teams discover edge cases that were not visible during design.

This is where the real test begins.

A best practice is not validated at design sign-off. It is validated by whether it survives real business pressure after go-live.

And this is where many clean designs can unravel.

Business Requirements Are Not Always Negotiable

A common implementation assumption is that technology can help shape the business. Sometimes it can, often it should, but there are limits.

Some business requirements cannot simply be designed away. Certain regions may require different visibility rules. Unionized populations may need different treatment. Matrix organizations may need access that does not follow a clean supervisory hierarchy. HR partners may support populations that shift constantly. Legal, contractual, operational, or privacy constraints may require exceptions that are not ideal from a configuration standpoint.

In those cases, saying “that is not best practice” is not enough.

The more useful question is: what is the trade-off?

If the business requirement is real, then the system design needs to account for it in a way that is controlled, documented, and minimizes the long term burden. Ignoring the requirement does not create discipline. It creates friction.

And friction creates workarounds.

In Workday Security, those workarounds can become custom security groups, duplicated roles, manual report distribution, one-off domain policy changes, over-provisioned access, or shadow processes outside of Workday.

The tenant does not stay clean simply because the original design was clean.

Clean Configuration Requires Leadership Alignment

A clean Workday tenant is not maintained by configuration alone.

It is maintained by leadership behaviour.

If an organization agrees to a security philosophy during implementation, leadership needs to understand what that philosophy means after go-live. Not just when the principle is easy to support, but when it becomes inconvenient.

That means answering questions like:

• What types of security exceptions will be approved?
• Who has authority to approve deviations?
• What is the threshold for creating a new security group?
• Are exceptions temporary or permanent?
• Who owns cleanup?
• What happens when the business wants something that contradicts the model?
• Is leadership willing to say no?

Without that alignment, “best practice” becomes implementation theatre.

Everyone agrees to the principle when it is abstract. Nobody upholds it when it creates friction.

This is where many organizations unintentionally create the mess they were trying to avoid. They design a clean model, but they do not build the governance muscle required to preserve it, and Systems Teams are stuck supporting and maintaining it.

Even Well-Governed Tenants Accumulate Debt

There is another side to this conversation that is just as important.

Even if the original model was well designed, and even if leadership has done a reasonable job upholding the original principles, tenants still accumulate technical debt over time.

That does not necessarily mean anyone failed.

It is the natural byproduct of enterprise technology living inside an evolving business.

Organizations change. Operating models change. HR service delivery changes. Companies acquire, divest, centralize, decentralize, reorganize, expand into new countries, introduce new processes, retire old ones, urgently track vaccine data, urgently purge and stop tracking vaccine data...

The business that made sense at go-live may not be the same business five or ten years later.

Workday is no longer the new kid on the block. Many customers have been live for a decade plus with scars and tenants to match.

A security model designed in year one may have been perfectly logical for the organization at that time. It may have followed the right principles. It may have been governed carefully. It may have avoided unnecessary customization. But after years of business change, even a disciplined tenant can start to show its age.

Security groups accumulate. Exceptions become embedded. Access patterns shift. Old design assumptions become outdated. Roles that once mapped cleanly to the operating model no longer reflect how work actually gets done.

The tenant may still function, but it becomes harder to explain, harder to audit, harder to enhance, and harder to support.

At that point, the question is no longer:

Did we follow best practice?

The better question is:

Is this security model still fit for purpose?

When Incremental Cleanup Is Not Enough

Most Workday teams are familiar with incremental cleanup.

You remove an unused security group. You tighten a domain policy. You rename something. You document something. You consolidate a few roles. You review access. You fix what you can.

That work matters, but sometimes incremental cleanup is not enough.

There comes a point where the current-state architecture has drifted too far from the current-state business. The tenant may have too many layers of historical decisions, legacy assumptions, one-off exceptions, and outdated structures. The issue is no longer a few messy configurations. The issue is that the underlying model needs to be reconsidered.

This is where organizations may need a stepwise change.

For Workday Security, that may mean a formal security re-architecture: essentially a mini re-implementation inside a live tenant.

That kind of project may involve:

• evaluating the current security model
• identifying outdated design assumptions
• mapping current-state access patterns
• defining a future-state security philosophy
• designing new security groups and role structures
• rebuilding access based on today’s business reality
• testing business processes, reports, integrations, dashboards, and user experience
• migrating users or populations to the new model
• sunsetting legacy security groups
• establishing governance so the new model does not immediately decay

This work is difficult because it happens in a live production environment. You are not starting from a blank page. You are replacing the engine while the car is moving.

But for mature Workday tenants, it may be necessary.

And in some cases, the issue may be broader than security. The organization may eventually reach the point where a wider Workday re-implementation needs to be considered. That sounds dramatic, but it is not unreasonable. Enterprise systems are not static. Neither are the businesses they support.

There comes a point where the cost of preserving the old model may be higher than the cost of redesigning it.

The Real Best Practice Is Maintainability

Instead of asking, “What is the best practice?” I think the better question is:

What design can this organization actually maintain?

That changes the conversation.

A maintainable Workday Security model should be understandable to the team that supports it. It should be aligned to real business operations. It should be documented in plain language. It should be testable, auditable, and scalable enough for foreseeable change.

It should be opinionated where the organization needs discipline and flexible where the business genuinely requires flexibility.

Sometimes the right answer is a compromise. But there is a big difference between an accidental compromise and a deliberate one.

Blanket Recommendations Are Usually Unhelpful

This is why blanket recommendations are often less helpful than they sound.

Statements like these may be directionally correct:

• Never create custom security groups.
• Always use delivered functionality.
• Keep manager access minimal.
• Do not customize delivered security.
• Keep security role-based.
• Avoid exceptions.

But none of those statements are complete answers.

A more useful recommendation explains when the principle applies, why it matters, what risk it reduces, when an exception may be justified, and how that exception should be governed.

The value is not in repeating the rule.

The value is in understanding the trade-off.

In Workday Security, the best practitioners are not the ones who blindly apply the cleanest theoretical model. They are the ones who understand the business well enough to know where discipline is required, where flexibility is unavoidable, and where complexity is being introduced without enough thought.

A Better Framework: Principle, Pressure Test, Governance, Lifecycle

For Workday Security, every best practice should be translated into something more practical.

1. Principle

What are we trying to preserve?

For example:

We want security access to be role-based, explainable, auditable, and supportable by the HRIS team.

2. Pressure Test

Where is this likely to break?

For example:

Regional HR teams may need access that does not align cleanly to supervisory organizations or delivered role assignments.

3. Governance

What will we do when it breaks?

For example:

Exceptions require documented business rationale, named ownership, leadership approval, and a review cadence. Temporary access must have an expiry date.

4. Lifecycle

When will we revisit the model?

For example:

Security design should be reviewed periodically against the current operating model, major reorganizations, acquisitions, audit findings, and changes to HR service delivery.

This is how a best practice becomes an operating model instead of a slide in an implementation deck.

Best Practice Is Not a Destination

The irony of Workday best practices is that they are often treated as universal answers when their success depends entirely on context.

A best practice that ignores business reality will not stay clean.

A best practice that leadership will not defend will not survive.

A best practice that the support team cannot maintain is not a best practice at all.

And even a best practice that works beautifully at go-live may eventually age out of relevance as the business evolves around it.

In Workday Security, the goal should not be to build the most theoretically perfect model. The goal should be to build a model that is clear, adaptable, and aligned to how the organization actually works.

The most mature Workday teams are not the ones that avoid complexity forever. That is not realistic. The most mature teams are the ones that understand why complexity exists, govern it deliberately, and recognize when the current model has reached the end of its useful life.

A clean security model is not something you build once during implementation and preserve indefinitely. 

It is something you maintain, challenge, refresh, and sometimes replace.

Because in a live Workday tenant, best practice is not a fixed design.

It is the discipline of continually aligning the system to the business it serves.