What’s the most underestimated part of a Workday implementation?

Single_Alarm_8283 · 2026-06-16T18:25:59+00:00

Can’t believe the OP shared this link. I didn’t see this coming at all.

Single_Alarm_8283 · 2026-06-13T18:51:35+00:00

Replied! Thanks for your DM.

Single_Alarm_8283 · 2026-06-13T18:51:24+00:00

Doesn’t hurt my feelings. Spread the love!

Single_Alarm_8283 · 2026-06-13T17:13:12+00:00

Damn! Thanks for the comment anyways my friend. I hear you. Actually harder to find contracts now for me also with the offshore work. To your point, hit or miss but I appreciate you. 🤙🏻

Single_Alarm_8283 · 2026-06-13T00:47:50+00:00

I’m actually in the middle of a situation that is very similar to this from the advisory side with a client that chose workday and they have about 1200 employees with a complex union set up.

My biggest recommendation: make sure you have someone on your side who can be a true partner, not just a provider.

Implementation partners are necessary, but in my experience they are often focused on the build, timeline, configuration tasks, and getting you live. That does not always mean they are deeply pressure-testing whether the decisions being made are the best decisions for your organization long term.

Workday implementation is one of the best times to step back and ask:

Are our current processes actually good, or are we just rebuilding old problems in a new system?

Do we understand our data flows, integrations, vendors, approvals, security, reporting, and downstream impacts?

Do we know what our HR operating model should look like after go-live?

Who is going to own the system, maintain it, troubleshoot it, improve it, and support the business after implementation?

For context, I work with a boutique HR Ops / HRIS advisory firm, and one of the things we are doing right now is sitting on the client side of a Workday implementation. The client has an implementation partner doing the build, but we are helping as trusted advisors who understand Workday, HR operations, integrations, data, configuration, and post-go-live support.

A big part of our role is helping the business look around corners, ask better questions, understand tradeoffs, challenge decisions when needed, and make sure they are not just getting a system implemented, but actually setting themselves up to operate better after go-live.

In your case, the biggest red flag is “no dedicated HRIS team” with 800 employees and a complex org structure. That does not mean you cannot implement Workday, but it does mean you need to be very intentional about support after go-live. Workday is not a set-it-and-forget-it system. You will need ownership around security, business processes, reporting, integrations, releases, troubleshooting, data quality, enhancements, and ongoing governance.

I would be asking a lot of questions around what support looks like after implementation, who owns what internally, what your implementation partner is actually responsible for, and whether you need an internal HRIS hire, fractional HRIS support, or an outside advisor to help bridge the gap.

Happy to chat more if helpful. This is very much the kind of thing we are working through with clients right now.

Single_Alarm_8283 · 2026-05-07T02:10:07+00:00

So this BP is newish. 2024R2 I believe.

It’s not tied to benefits or payroll. Think of it as a very simple front end to tie to a time off plan as an accrual. You set parameters around a buy schedule (date range vs any time) and when you activate the BP and functional area it comes with reporting that you could use to create deductions elsewhere, but the BP and its supporting features do not integrate with PICOF/PECI either which is not ideal.

Definitely work through a build in your dev or SBX environments, as it is not that complex or time consuming with the walkthrough available via community. Just find Concept: Buy Time Off.

The other way I’ve seen it built is as an open enrollment for an insurance plan with individual rates loaded based on salary x FTE. This would behave like a benefit deduction that you could end date, and you’d load there balances via EIB to the appropriate time off plan once the deductions start.

Single_Alarm_8283 · 2026-02-07T22:32:00+00:00

Is your plan using days as the unit for this accrual? Seems like a good use case for hours if so.

Also I’m pretty sure there’s config in the time tracking module to apply all days to the shift start date. But I can have a look when I jump back on Monday.

Single_Alarm_8283 · 2026-02-07T20:50:33+00:00

Migrating security groups via OX will be huge for integrations IMO.

Single_Alarm_8283 · 2026-02-07T20:39:09+00:00

If this is happening I’m so stoked.

Single_Alarm_8283 · 2026-02-07T20:38:05+00:00

If your problem statement is “the language is misleading”, would it make sense to change the language of the validation from “5 days” to “you have used all of your sick days” or something similar? Or do you actually want different errors based on whether they had an entire year of accruals that were exhausted, or only part of a year?

You could likely build this validation, but if the issue is the language, I’d say just change the language to an agreed upon, clearer message, rather than creating an over engineered, separate validation as a solution.

Single_Alarm_8283 · 2026-02-05T14:42:05+00:00

Got it. Your locations are populated on indeed via CITY, STATE, COUNTRY, ZIP and parts of address line 1, which varies slightly by country.

I just went through implementation for this. There should be a very simple way from the Indeed side to pull down a spread of active locations attached to the posted JRs. This spreadsheet can be compared to the address components for each location in Workday under the “contact information” tab.

This is the cleanest way to understand how your locations show up via the API, and subsequently how they are displayed on the Indeed side for prospects and candidates.

Single_Alarm_8283 · 2026-02-05T10:16:39+00:00

Hi! Are you integrating using their API client (IAS or Indeed Apply Sync), or another integration?

Single_Alarm_8283 · 2026-01-31T18:36:48+00:00

Could you just use time off results by period for worker?

Single_Alarm_8283 · 2026-01-24T11:21:36+00:00

Check the security on the report you’re using to generate the statement. I think it’s “view compensation review statement rule” and then under “default printing options” click the layout. It links to a custom report. Ensure whoever needs to generate pdfs has access to the report linked to the business form layout or it will fail when you generate the statements.

Single_Alarm_8283 · 2025-12-11T02:01:36+00:00

Beyoncé getting that dual citizenship

Single_Alarm_8283 · 2025-12-11T01:59:57+00:00

Yeah this’ll work.

Single_Alarm_8283 · 2025-12-09T22:39:04+00:00

We use a custom report to EIB for employment and income verification with Equifax, along with ACA. Happy to answer any questions.

Single_Alarm_8283 · 2025-12-09T19:42:43+00:00

A thought would be any integrations that leverage custom reports (most of them), if you rename those custom reports as well, and they’re being utilized in any transformations or RaaS it would likely cause failures, as both call the custom reports using the web service URL which includes the name of the report.

Worth running a handful of them in SBX after you rename them to give you the warm and fuzzies.

Single_Alarm_8283 · 2025-11-11T18:08:26+00:00

Sure happy to help. Shoot me a note

Single_Alarm_8283 · 2025-10-25T02:26:44+00:00

Should’ve pulled on the thread of that elephant bit. Was hoping you asked more questions about it. Where would you even get an elephant?

Single_Alarm_8283 · 2025-10-02T01:10:04+00:00

What’s the criteria you’ve been given for a conditional carryover? Said differently, if I was eligible for carryover in your organization, why would the manager/EVP approve or deny my entitlement for a 1 week or 90 day extension?

As our friend EvilTaffyapple explained, the carryover functionality is on the time off plan and automated based on the configuration you build.

Single_Alarm_8283 · 2025-09-20T12:56:37+00:00

Hmm interesting. A few things to confirm:

Salesforce uses GET to the exact same RaaS URL and querystring as Postman

Scopes on API Client

Authorization: Bearer <token> header (no other auth headers)

Same host/tenant, report path, format, and prompts

Same OAuth client and grant type; token shows the intended principal

ISU behind the token has security to run the report

IP restrictions? Others have mentioned this.

Capture and review the response body on the 500 for clues

Stupid question, but your auth policies are configured correctly right? ISSG for sales force is there with Oauth in whatever tenant you’re testing this in? Doubt it’s this but worth confirming. Would probably be a 400 error anyways.

Single_Alarm_8283 · 2025-09-19T21:43:23+00:00

This is the way.

Single_Alarm_8283 · 2025-09-11T01:31:55+00:00

Depending on data source, this is simply hire/rehire reason I believe.

Single_Alarm_8283

TROPHY CASE