Excel for Workday®: Why? When?
I started implementing Workday® in 2008 as a reporting and integrations consultant. This was back in the day before calculated fields, dashboards, and matrix reports. Like others on the team, I had my own opportunity to meet Dave Duffield at the Walnut Creek offices. He was carrying two bags of bagels on the elevator ride up to his office, and he generously handed me a bag to take to my Workday Fundamentals training class. I’ll never forget that meeting, or the generosity of a billionaire handing a lowly trainee a bag of bagels.
While I was in training, one of the features that struck me as utterly unique to Workday at the time was the RaaS functionality--Reports as a Service. I quickly saw opportunities to leverage Excel with reporting. The ability to create a report in Workday, generate a URL, and consume that data natively in Microsoft Excel was a game changer. It meant that all of the power of Excel was now applicable to virtually any piece of data in Workday. Early on, I found several clients who had reporting needs that would exploit this feature to its fullest. I began developing a process and methodology for using Microsoft Excel, VBA Macros, and Workday data. Using these very powerful tools allowed me to provide end users with report specifications down to the row- and column-level for consumption across the enterprise, whether by humans or computers.
Today, I apply these same skills and methods to my teamUpHR customers, whether they need self-bill reports for insurance, 401(k) audit reports, or simple column transformations not easily accomplished with calculated fields.
As Workday has grown, more customers are running reports that result in thousands of rows. When I engage with customers to help meet their reporting needs, one of my first questions is, "Is your end user of this report going to scroll up and down through hundreds/thousands of rows, or are they simply going to click the Excel icon and slice and dice in Excel?" Quite often the answer reveals that the end user will always be viewing the report in Excel. My follow-up question relates to whether or not dozens of required calculated fields will be shared with other reports. If not, why create many calculated fields in Workday instead of creating the logic and calculations where the end user works, in Excel?
This methodology isn’t for every single use case. Sometimes the Workday-native tools are enough. For large, complex reports, sometimes powerful middleware is the right answer. But in the right circumstances for all those use cases in the middle, our Excel approach is a powerful toolset that has literally saved clients hundreds and thousands of hours of manual labor! Follow my blogs for more about this simple and powerful yet often overlooked approach to getting the most out of your Workday data.
