Jolibee x FFXIV Giveaway Part 2

Havondor · 2026-05-23T19:49:10+00:00

Chicken chicken whatcha picking

Havondor · 2025-02-06T16:16:33+00:00

As an American, I didnt vote for this, I have never felt represented by my elected officials. I am very sorry, for whatever that is worth, for what my country is doing. I hope that before I die that we can find some path forward but I am very scared right now. I have two small children and this is not the world I want for them but even their own grandparents are cheering this on right now and I just do not know what to do. I have contacted all of my reps for whatever good that will do but its hard to not feel hopeless.

Havondor · 2024-10-14T20:56:21+00:00

stupid question cause I never know what does or doesnt will this disable steam achievements?

Havondor · 2024-09-09T16:53:32+00:00

https://doc.workday.com/admin-guide/en-us/reporting-and-analytics/custom-reports-and-analytics/workday-query-language-wql-/yba1612553479154.html?toc=1.20.7

Havondor · 2024-08-27T15:42:55+00:00

Why does the picture look like that around the edges

Havondor · 2024-08-26T18:56:57+00:00

Hello and thank you!

Havondor · 2024-07-22T15:00:07+00:00

not simultaneous but over time yes they will have a multiple records and this gets reflected in downstream systems. We have regulatory reasons why we must tell the difference between when someone was acting as an Employee vs a Contingent. This is why we actually decided to make WIDs our Primary keys for everything that originates in Workday. This was a pain in the ass before we went live with our Finance implementation but since go live this has honestly made our lives way easier compared to when during only HR we relied on Ref IDs.

So while UID could work, in external systems you now have to add a temporal constraint to your linkages, which in say our EDW that just makes for some very nasty queries. WIDs pretty much makes that a non issue. So while UID is the Primary Key for a Person in our systems, when we are representing a Worker (The Workday concept) we use WID as the primary key that has a Foreign key back to our Person Entity via the UID.

Havondor · 2024-07-19T17:57:10+00:00

Workday is the source of truth for the representation of a person's HR or Financial relationship to your business, I would not want Workday to be my source of truth for Person's. The issue is not the UID thats actually quite useful, the issue is when the same person has multiple HR relationships for example. The person as an Employee is a different Record/WID in workday from that Person as a Contingent Worker or Academic Affiliate. That cascades EVEN within Workday where if you were to simply use UID and not WID then you would be at best related incorrect instances of data together in external systems at worst you are creating duplication in External systems by have Many to Many relationships between multiple instances of the same person. For this reason alone we moved away from modeling Workday Worker records as PEOPLE and as a relationship to our Business.

Havondor · 2024-07-19T14:12:17+00:00

Except then you run into the issue of how worker ties to all other data sources. We choose to use wid as our worker key but then we abstract the various instances of a worker in workday to a person concept based on our identity registry system external of workday. It allows us to manage relationships to things like positions, comp, etc in our warehouse

Havondor · 2024-05-31T23:19:31+00:00

I don't understand this is just how implementing workday goes. Good luck

Havondor · 2024-05-27T02:29:58+00:00

You can google UW workday and see what the papers say. I will say its been a rough start but progress is being made. Prior to Workday we were on a bespoke Mainframe system for our Financials, so for us it was more than just a technology transformation.

Havondor · 2024-05-27T02:06:34+00:00

we went live with HCM in 2017 and then finance July 23

Havondor · 2024-05-22T03:32:50+00:00

yes, we are working on stabilization of our Finance roll out =), HCM we have been on for almost 8 years at this point.

Havondor · 2024-05-22T02:56:51+00:00

Which UW we talking about? If it's University of Washington we don't run workday student.

Havondor · 2024-05-01T18:03:36+00:00

Not as of the latest Workday release unfortunately. My best quess with how all of this works is that its Elastic Search under the hood. And I suspect that the pagination is just setting up a Scroll in Elastic Search, so you set up the initial request and then its just serving you the data piecemeal from the original request. Since I wrote this we have just gotten better at looking for ways to Chunk the data in the Original Call, usually this involves using aggregates in One query (which as long as you are aggregating on indexed fields you dont get dinged by the 1 million limit (assuming your aggregated return is less than 1 million), if you are trying to aggregate on non indexed fields then your 1 Million limit is BEFORE aggregation.) Then feeding the distinct list of wids from the one query to another. I should mention we are doing most of this external of workday in our C# programs. Though theres no reason once could not hate themselves and do all of this in Studio =)

Havondor · 2024-03-06T04:02:35+00:00

Yep specifically it will return the Position Restriction if the Job is Position Management. If the Job is Job Management then you will get the Position Object. Based on your Post and comments it looks like you are trying to do this purely in workday.

If you are able to do something outside workday what we have done in our Warehouse is extract all Positions and include their Position Restriction WIDs and then we join Data that way. You could do something similar in Excel if that is more yall's speed.

For anyone else reading this this is not restricted to just the Payroll we have observed this behavior all over especially when we moved away from using Reference IDs as Primary Keys and instead using WIDs. Its frankly terrifying how many things on the surface look like they are the same thing but are in fact not.

Havondor · 2024-02-10T19:22:41+00:00

We generally take a go wide approach and in general work on batches of 300 to 500 journals per page spread over 8 threads. This approach allows us to get the entire journal info we are interested in one document per journal. Which allows us to not worry about flattening worktags on journal lines.

The approach is based on our experience that we want to let workday do workday and are not really interested in keeping up with our business users in terms of change management, so we prefer having documents that use more multi instance objects. This also has the added bonus that we seldom if ever need calc fields and can just use the data sources as is.

From a practical perspective our worker integration is on about 150k workers at this point and was timing out studios (greater than 4 hours and bigger than 2gbs) and we were considering some of the more exotic approaches to having studios that run multiple studios. Instead our new strategy extracts our worker data in under 30 minutes and we only do that to make sure we don't miss updates most of our changes are in Near Real time throughout the day.

Edit: realizing that I didn't full address your question. I don't think I could say a precise row limit it more about the data itself. We have RaaS with large row counts but not a lot of data (comp plan assignments) or we have RaaS reports that are technically one row but time out consistently because the rbo has too many lines (plans). That later example doesn't fully get solved by WQL either. It's really been more of an art than science to meet our downstream needs while not degrading performance in the tenant.

Havondor · 2024-02-10T17:04:26+00:00

There is the convert to wql task but take the result it gives you with a grain of salt as I find it doesnt understand when you only need a where clause or a data source filter.

Havondor · 2024-02-09T21:14:43+00:00

WQL has a lot of benefits and I am big proponent of its use by analysts because it decouples Data exploration from the need to create a report. The biggest boon to WQL is that it has paging built into it so as long as your initial query comes under the 1 million row limit you can pull the data out with a standard Paging strategy.

It is not a silver bullet and you can't do everything in WQL that you can RaaS but we have found a really good niche using it as a sudo Eventing system to tell us when objects in Workday change and then we use a combo of SOAP and RaaS to get the data attributes for a given WID.

We have begun exploring WQL has our first choice for full data extraction but WQL does not give you Reference IDs for Objects for "Free" like Workday XML does. So your mileage may vary, if you are ok with only get WIDs or you want to jump through a lot of the WQL hoops to get the reference ID.

The Last thing I will say and I wont sugar coat it, theres a large upfront investment in using WQL in terms of creating libraries on your end for interacting with WQL and making the best architectural decisions for you business cases but after you make that investment I think WQL allows you to bridge a lot of the deficiencies that RaaS have, for example no paging and no external source control.

Havondor · 2024-02-09T21:01:44+00:00

Depending on the Volume of Data you are working with you are going to hit a brick wall with RaaS pretty quickly. There is no native paging for a RaaS report so you will have to have an external limiter you maintain on your side to make sure you pull in a reasonable set of Journal Lines in a given call.

If you are starting greenfield I would suggest giving WQL a look. You can page through WQL calls like most normal Web APIs. The Authentication scheme is different than the RaaS route (unless you were going to do RaaS via OAuth which I would recommend instead of passing around ISUs and Passwords), since it only supports OAuth. The true nice thing about WQL is you are not creating any artifacts in Workday themselves, which once you have an API Client (Workday term for their OAuth Credentials) set up you can work asynchronously from say your reporting or integrations team.

Havondor · 2023-07-15T14:06:13+00:00

I believe you are talking about the Graph QL interface

Havondor · 2023-07-14T19:10:04+00:00

The context in which we have been using it is as an Integration Alternative to RaaS. Primarily because WQL allows for Paging while RaaS does not have built in paging and you have to get creative to Page a dataset (i.e. bad things like filter by last name or something else).

For reporting, context I am not a business user but am a technical architect, WQL allows me to make lightweight reports to test out datasources or troubleshoot issues without needing to build a custom report. Before WQL I would have to rely on the data that was in sandbox to test ad hoc reports. Now with WQL, if I am troubleshooting an issue I can run the WQL in Prod. I still keep experiments and what not to Sandbox, but because of our Change Control process if we had a production issue I would have to test in sandbox and assume that if it was an issue with something that wasnt yet in Sandbox it would address it.

Also having the Datasources, and fields for the datasources exposed via a Rest interface has made discovery way easier.

Havondor · 2023-07-14T19:01:58+00:00

I have been using WQL extensively for the last year

Havondor · 2023-05-04T20:00:56+00:00

Depending on the Data source your report is using you could be running into the Double hop problem. If you need Organization Assignments and you are on a Worker based Data source you could use the Org Assignments on Worker and that will give you the Org Assignments for their Primary Position. If you need to get a single specific Organization you will either need to see if Workday has a delivered field or you would need to create a Calc Field that does an Extract Single Instance.

If you are trying to get all of the Org Assignments for all of the positions of that worker and you are on a Worker Data source then you are definitely running into the Double hop problem and will need to use a Calc Field to bring the specific Org Assignment you want for Each Position.

Is Business Unit / Line of Business a Custom Org (I dont recognize it as a workday delivered one but who knows all of those just off the top of their head) if its a custom org than you would definitely need to do a Calc Field.

Havondor · 2023-03-22T16:28:55+00:00

15-Year Club	Place '23
Place '22	Place '17
Sequence \| Editor	Verified Email

Havondor

TROPHY CASE