Report security

This blog will probably be a mishmash of Workday, PeopleSoft and SuccessFactors for the foreseeable future as I continue to consult on Workday topics while using SuccessFactors and PeopleSoft in my day to day job.

SuccessFactors

Today, I was supporting an HR user who needed access to certain data in order to do some analysis for the HR VP over here in Europe. I know that I have access to a really good report but my user did not. My user has access to similar data so I asked my SF guru colleague in the US what I needed to do to enable the report for the user.

"Hold on, I'll add her to the report."

Me: Wait, what? We need to grant access to reports individually?

My colleague: "Well, in some cases, yes. It depends how the report security was originally set up."

It's an interesting concept that you can roll out reports and lock them down individually, at a user level but there is always a maintenance and upkeep tradeoff, isn't there?

Workday

I previously posted about Workday domain security and the same concept still holds true. If you can access the domain you can see the data on the pages or in a report.

I guess this SF concept is a little like the 'report sharing' feature in WD. You can share a report with another user which is like giving them the framework and structure to easily run a report but the output is still dependent upon their domain security so you cannot give them more access than what is in the domain security.

PeopleSoft

Old faithful is predictable on the topic of report security. If you have access to all the tables, you can access the report. Even PS had a 'sharing' option but it was more than you were copying your report definition over to another user id and then you each had your own copy rather than a 'shared' version.

So I guess in this case we are more alike than different from a user perspective.  :-)

But I just want a basic report!

We are currently trundling through our rest of world (non US, Canada, Mexico) Workday implementation. We are in the second round of test loading data.

As a part of our data validation our Workday implementation partner is issuing reports to us from the test system. I am combining these reports with PeopleSoft reports in Access. Then our HR community is reviewing the data to ensure that it matches.

One of the items that we need to validate is 'HR Partner.' In PeopleSoft we have an HR partner assigned at the department level. We're bringing that over to Workday and assigning an HR partner to a supervisory org (along with other roles such as Absence partner).

I have a report from PeopleSoft, it includes two fields: Department ID and HR manager ID.

Trying to get the equivalent from Workday is like trying to get blood from a stone.

First our Workday implementation partner ran me a report that looked something like this:


Our Workday implementation partner seems to be staffed with consultants who have never worked in-house. Fair enough, a lot of consulting houses are like this, as they've never done operational support they have no concept of how things actually work once the software is turned on.

I know everyone likes to say how great Workday is, that you no longer need to know codes you can work off of description but try matching on names from two different systems. People get married, etc. it's just inefficient.

Also, how am I supposed to parse all of the gobbletygook in the box?

I clarified the request and asked specifically for 'Supervisory Org code' and 'HR Partner employee ID'. In return I received this response:

Due to the Worker, Sup Org, and security business objects in Workday, we’re limited from splitting out a single org’s assignments into multiple rows when an org has multiple assignments. We’re trying one last effort during India time tomorrow to see if we can get it to work, but it’s not looking promising.

I mentioned a while back when I took the reporting class, how Workday reporting is not intuitive, but these folks are experts, Workday certified consultants.

I'm not quite sure if the problem is consultant knowledge or the Workday system itself. If I ever get to the bottom of it I'll let you know. In the meantime we'll just go on a wing and a prayer than our HR Partner data is being converted successfully.

Testing report performance in Workday

As someone who supports users who write/run queries in PeopleSoft, I thought I'd share a few features that I like about Workday report writing, functionality that doesn't exist in PeopleSoft.

1. The ability to 'test' a report while building/editing it.

Best practice in query/reporting writing dictates, 'test early, test often' to ensure that you are not breaking something or building it incorrectly.  Often, when a user is building something terribly complex in PeopleSoft, however, testing such a query can take 10-15 minutes per test run, which can be a hassle if you're adding multiple criteria, expressions, outer joins, etc.  *The assumption here is that you have a large PeopleSoft database.  Small instances may not have such obstacles.

Workday delivers this 'test' button when you're building or editing a report.  In this case, I'm editing a Workday delivered sample report, Employee Birthdays:

When you test a report, it does a small run of it, delivering 10 results.  In this test output, I may notice that I have blank birthdays or terminated people in my report, thus causing me to stop and consider another data source, before I'm too deeply into the report build:

Here are the data sources, by the way.  It's been over a year since I formally took Workday report writer training and I'd say that it one of the more difficult things, to choose the right or most efficient data source for what you want to do as there are just so many of them, and many are similar.

Once you're happy with your report, when you use the 'Run' button, you'll get the whole dataset, rather than the 10 test rows:

 2. Analyzing report performance

There are many ways to build the same report in Workday.  For example, let's say that I want to run a report on active employees.  Referencing the data source screen above, I could build a report on 'All Active and Terminated Workers' and filter out the terms, or I could just build directly on 'All Workers' which would be more efficient.  Both (and a variety of other) options are possible, but some are more efficient than others.  To measure report performance, Workday has recently (in the version 20ish range) opened up some options that were previously only for Workday internal use.

So check this out...I test run my report, under the 'Test Report Performance' menu.  Here I'm running a summarized headcount report:

 I get some output, great!

Now, I can see some logs.  If I would have skipped the above step, I would not have had these available to me:

Here are the log outputs:

It's mainly self-explanatory, but if your report is running slow, you're able to analyze where the hold up is located.  For example, my report here has no sorting or filters, but potentially if you were doing a lot of filtering or sub-filtering rather than using an efficient data source, that would quickly become apparent here.

In my current PeopleSoft world, to do the equivalent troubleshooting, I'd first eyeball the query and go through the chosen fields, filters, expressions, etc. to see if anything is clunky.  I'd review the table joins and tables used, to see if they are bulky ones.  Finally, if I didn't see anything with my trained eye, I'd need to take it into a SQL tool and start to take it apart line by line to see where the slow down is occurring, potentially with a database admin to look at the server side, if I still couldn't get to the root cause.  As you can imagine, I'm pleased as punch that Workday puts these logs out there, as potentially it makes it easier for the support resources to get to the needed information and fix any issues.

After a hiatus, I'm ready to start writing again.  If you've read this far and if this has been helpful and you'd like to see more, please click any of my ads.  It's nice to know that someone is reading me.  :)

Tracking exempt status in Workday

A reader recently sent me a note, asking about how to track Exempt/non-exempt status.  I thought this info might help others, so here it is.

Workday allows you to track exempt status on a job profile, as do most HRMS these days.  A nice thing about Workday, however, is that you can attach different exempt statuses to one job profile based on location:

In previous HR systems that I've seen, you'd be stuck creating new jobcodes, profiles, positions, etc., each time that an exemption status changed, in order to track that status.  Prior to version 11 WD was in a similar situation, so nice to have seen them build out this functionality.

A few things to keep in mind though:

• You need to have your processes locked down tight, as to how you will use this tab.  Will you assume that any state values are exceptions to the country value?  
• Who is pulling any government reports, and where do they come from?  The use case presented on this one is that employees in California may be in the same job as someone in Texas, but due to California legislation, they are non-exempt rather than exempt.  There are a variety of ways to accomplish this reporting....

1. Put the exceptions into WD.  Document that a country is the norm and only exceptions are documented.

2. Don't put the exceptions into WD.  Establish your procedures outside of the system to assume all California jobs of a certain profile (grade level x etc) are non-exempt--in which case put employee work location into your report.

3. You could always put ALL the data into WD...so 49 exempt states and 1 non-exempt.  I'm not endorsing it, but I'm saying it's an option.

There are lots of options here and WD offers a lot of flexibility on this front.  To be successful, you need to ensure that your data entry procedures are watertight and that the reporting folks are working off of them consistently.

Workday Training Schedules...still 'unglobal'

Way back in November 2012, I was whining about Worday's US-centric training schedule.  Here we are 18 months later, and I'm about to do it again...

I am very lucky that my company will pay for me to attend training.  While I've done most of the basic training early on in the project, our US colleagues are struggling post go-live with reporting topics.  I took the basic reporting class last year, but wanted to get my hands into the 'Calculated Fields' class, a 1.5 credit (15 hour option).

On the plus side, it's a virtual class offered over 3 days at 5 hours a day.

On the minus side, the timing is pretty poor.  For a company that claims to support global companies, I find it lacking.

• There are 8 instances of this course scheduled between now and the end of July.
• None are in the Eastern US timezone (which is somewhat palatable to London), but 7 are in Pacific or Central US.
• One is in the 'London timezone' (from 11 AM - 4 PM) according to their website.  I cannot quite figure out why the Pacific and Central classes start at 9 AM, but Workday thinks that in London our workday begins at 11 AM??  For anyone on the continent, that's a noon-5 PM run.
• That being said, the class does fall inside the European workday, a novelty from my friends in Pleasanton.
• Most of the US classes are Wed-Fri, so even if you did want to bite the bullet and take the US-centric offering, you're stuck online until 11 PM Friday night if you choose the Pacific option.  As well, starting a course at 6 PM on a Friday after a long work week will not be effective for me.

I wish I could have a better report out in this area.  I can only assume that Workday's customer base/focus remains heavily in the US market?

How to create a calculated field in Workday

I was having a discussion recently with someone, about the calculated field functionality in Workday.  I've previously posted about procedures and tips around using calc fields in an operational capacity, but I recently put together this quick example to explain the topic further, so thought I'd share it here too.

Once you're in Workday, the first thing to do is to define the type of calc field that you'd like to build:

There are many different options, more than I'm showing here, but the point is to know what you are seeking to do.  An average, untrained user would probably be stopped at this point.  Let's keep it simple and do a concantenation example.  It's also relevant to note--you need to know what business object should be invoked here.  We'll use the Worker object, since it's a main source for employee data.

On the next page, you're brought into a screen that functions in the same manner as the 'normal' reporting page.  So you can choose your fields, as well as add in the more intense logic if you're building something more complicated.  In my example, I just want to concatenate two fields together.  I'm using email+mobile just as a sample, so that I get a mix of letters and numbers:

Next after you save your new calculated field, you can use it in your reporting.  You need to choose the same Object (in our case Worker), to be able to find the field.  Then, your new calculated field will exist like any other field on Worker.

Then, you're ready to run your report.  Here's the example which I then ran into Excel:

 

 

A few points (and the reason I included a snippet of the output)...you'll see some workers have only a phone or some have only an email...so this is all you get.  So getting a good output on a calculated field will depend on what data you have to work with underneath it.  You can see where these can get tricky then as well, once you make more complex ones...is your bad output due to bad design of your calc field or bad data?

 

This was a quick and dirty two minute example.  WD offers a 3 day/15 hour training class on the topic, to get really in-depth with the logic of creating these special fields.  However, seeing how easy it is to create them, you start to get an idea of how dangerous they can become, if not regulated.  

 

Calculated fields in Workday

An interesting feature in Workday is the 'calculated fields' functionality.

 

To quote WD, 'Calculated fields allow users to perform simple arithmetic, date calculations, text manipulation, logical expressions, retrieval of related data, and transformations of their existing data. You can use calculated fields in reporting, business processes, integrations, scheduling recurring processes, and other areas within Workday.'

 

It's a nifty little feature, as

• it gives complex power to the users in reporting, via an online interface where you build them.  (As opposed to having to write complex expressions with if/then statements, for those of us from a PeopleSoft world).
• it allows for 'cleaner' development, as a developer is also using the online point and click functionality to build these items, rather than writing code from scratch.
• they are convenient, since you only need to build them once and then can reference them in reports, integration, etc.

So as a practical example, if you are interfacing to various systems, let's say 'gender' and one system needs 'M' or 'F', another system needs 'Male' or 'Female', another system needs '1' or '2' and another system needs 'M' or 'W' (male/female in German would be 'männlich' or 'weiblich').  So in each instance, you'd create a calculated field to allow for the M or F or 1 or 2, etc.  Then, if these systems ever changed their coding, it would be a simple online update to change the interface.  It's much nicer than other systems I've seen where hardcoded SQL needs to get updated.

 

As well, you can do traditional if/then or 'evaluate' expressions.  So if an employee's hire date is more than 10 years ago, put >10 or that sort of thing. 

 

From a reporting perspective, it allows you to build user friendly reports in an easier manner than I've previously seen in other systems.

 

Where are they not so convenient?

 

Like much of WD, the functionality is very flexible.  If you don't have your business processes in order to support this flexibility, you're in for some issues...

 

In our implementation (being lead by a mainstream consulting partner, but supported by multiple offshore consulting firms), the main parter says that best practice is to implement WD by 'an iterative approach'.  Basically, we keep putting data in, seeing how it looks, then tweaking here and there what we're doing.

 

When the topic of calculated fields came up, our traditional approach was to try to standardise and lock down the functionality.  (We have 150k + employees and a large part of our business is manufacturing, so we live by documented processes, otherwise it's a free for all mess.)  Our consulting partner directed us that 'best practice' is to not standardize, as that would cause a bottleneck, and instead, each developer should be creating any/all fields needed.  Not quite sure that was the best way, in retrospect.

 

We have 200+ integrations that are being built (many offshore) as well as local development of reports that are also generating calculated fields.  As there is no clearinghouse or rules, people just make a new calc field rather than hunting for an existing one.  The Data Governance and Controls team is now quickly working to implement standards and structures as the count of calc fields has soared to above 1000.

 

An example

 

To put it into a practical perspective, I've been working on some reports recently, to support our HR colleagues who are looking at the data.  I was seeking 'Business Unit Descr' so I searched for 'Business Unit'.  The top field is the WD delivered one (is it descr?  code?  who knows).  The ones after are all our calc fields.  This is not all of them, as others created them as 'bus unit' and all sorts of shorter versions such as 'BU':



 

You can see where the standards of the Data Governance team are starting to come into effect, such as using 'CF' as a prefix for calc fields or 'INT' when an integration is involved.  If you have only a handful of folks using this functionality or creating reports, it might not be such a big deal.  However, we will ultimately have hundreds of HR folks in the system using (if not creating) reports, so this willy nilly lack of standards will be confusing for them, even if they are only running reports and seeing disparate field names.

Looking online at the Workday Community site, other companies are grappling with these very same issues.  (Sidenote:  I'm a little surprised that WD itself does not issue more guidance).  There is a 'solutions' section in the community where other WD customers can post their top tips and documents, to share with other companies.  The group at Brown University put together some really great documentation, but just to give you an idea of how extensive this calc field naming can get, here is a snippet of their rules:

 

 

 

In addition, another customer (who has been live for a while) has developed a series of reports for more what I'd call the 'structural' aspects of the system--so basically audits to keep things tidy and more efficient.  He also includes calc field review in his list of 30 reports, such as keeping up with the following:

My tip of the day

As you can probably gather from the above, calculated fields can get very messy, quite fast.  Not necessarily WD's fault as it's a side effect of the flexibility of the technology, but you need to have strong business processes in place to control the creation of these things.  So I'd suggest:

• Define who will create calc fields in the future.  Read up on Community, various customers have defined different ways for this to happen (HR Business users, HRIS, IT, etc.)
• Develop your guidelines and structure of how these items will be named and categorized.  WD does provide things like 'tags' to help you in classifying them.  Again, the Brown University guidance is a good start.
• Be prepared to do auditing on calc fields in the future, to be sure that your environment is doing well against your rules.

Training on calculated fields

It's probably worth a mention, calc fields is a 3 day/15 hour online course from WD, to give you an idea of the level of complexity that you can get into with them.  The pre-req is the Report Writer class (2 days/10 hours)

My review of the Workday Report Writer training

I recently attended virtual training on reporting from Workday. While you get a high level overview of reporting in the HCM Fundamentals class and run one report, Report Writer is the first reporting class that you can take to learn how to create your own reports.  It's a virtual class, 10 hours spread over two days. 

At first glance, the WD reporting product is not the easiest to learn on your own with no instruction (believe me, I tried!), especially if you're used to a relational database model.  In WD you can access the reporting tool from within a page, so you can click the 'related actions' from a hyperlinked field and choose to 'create report from here' or to view related reports.  However, if you don't have the report basics, you will soon be lost.

I'm happy to say that the two day WD training cleared that right up for me.  The class starts with some background about the WD database structure and some high level details about how the reporting works.  Then, you start to run delivered reports, then you build basic reports (on one object such as the Worker object), and finally advanced reports where you combine objects and then some simple matrix ones where you run counts, similar to an Excel pivot table.

This class was probably helpful to me at this point, because I now understand the structure of Workday, and how there are various objects such as the Worker, Location, Company, etc. and how the data is clustered around these objects.  There were some people in the class who have never seen WD beyond attending the HCM Fundamentals class (a required pre-requisite for this course) and they were lost before the end of the first day.  If you are at least in the implementation stage and have some idea of how to navigate around the WD system on your own and hire someone, for example, you'll be fine.

WD offers Report Writer as an introduction to reporting, then you can follow it up with Advanced Reporting and Analytics (15 hours over 3 days) and/or Calculated fields (15 hours/3 days).  These are all virtual options, with Report Writer being the pre-req to the other two.  There is also the option to do the reporting suite in a classroom setting by taking Workday Reporting:  Basic to Analytics.

That being said, assuming that you have a test tenant to use and can get a hold of the manual, you could probably walk yourself through the training quite easily. 

Some of the things that confused me at face value, before taking the course:

1. The overwhelming plethoria of fields with the same name.  Every instance of a field is its own reporting field.  This differs greatly from a relational database, where if you have something like 'jobcode description', you'll have one jobcode table with a description and you tie your code on your secondary table back to your foundation table. 

If you type 'Name' into Workday to find the field 'Name', you'll quickly get confused as you'll get all sorts of Names (descriptions) for things.

2. The icons used in the reporting tool.  The icons are meant to give you short-cut details about a field without having to look into the details, but until you know what they mean, it's a bit confusing.  Sure 'T' stands for text and '#' is a number field, but what's the thing that looks like a spoon?  Or the fireworks?  Once you know that the spoon is the base table and the fireworks represents a one-to-many relationship, it becomes a little more clear.

Once you get a handle on those basics, it becomes easier to navigate through the tool.

The one odd thing to me--and granted I come from a mix of HRIS systems from basic homegrown MS access applications to more sophisticated tools like PeopleSoft--is that WD locks down reporting from the join perspective.  So if you're doing a 'basic' report, then you're only working on one object--say 'Worker'.  If you change your mind and need other data that is not on Worker, you need to convert to an advanced report (which is possible).  However, if you start your report on an object and discover that it does not have all of your fields, if a join does not exist, you cannot 'force' a join the way you can in other databases.  You basically have to begin again, this time using the 'right' datasource.  I can imagine that one causing some frustration at the user level.

To view my other posts on training, click here.