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.  :-)

8 years later: how global is Workday?

Back in 2012 when I was just starting to learn Workday I wrote a post at the time How global is Workday? and I was especially curious about how they handled a European requirement which wasn't a US requirement. My use case was 'company cars'. 

What did Workday do for company cars in 2012?

 In 2012 Workday had no company car functionality which was a bit of a disappointment as:

1. PeopleSoft had company car functionality.  (Actually, I should use present tense here as PeopleSoft has company car data functionality, if you're an Oracle customer.)

2. The data structure is not complex or intensive.

3. There are government requirements around tracking who gets a company car since an employee is taxed on it. 

There was a brainstorm kicking around the Workday Community which many US multinationals and European customers voted up.

The suggestion from WD consultants at the time was to cannibalize the Business Assets functionality. It was an awkward suggestion to enter data in a consistent manner in fields that were not designed for this purpose. The other suggestion was to build a Custom Object, also not a great idea since there are multiple car data fields needed.

So we're just starting 2021 and nine years later, what's changed?

If you're a UK Payroll customer who only needs to track company cars for UK employees, you're in luck! If you're not a UK Payroll customer or you have cars outside the UK, to use a UK term, 'sod you!'

If you're in the former camp and you're a Workday UK Payroll customer, Workday has delivered the functionality to set up cars, assign them to employees and to run the report to deliver the data to the government for tax purposes.

Well...it's a start and it's better than nothing!

There are some kinks to still be worked out as others have pointed out. It would be nice to have an EIB to load the car data. Also WD has held back on exposing the tables so customers are not able to design custom reports around who has what car and even which employees have cars. I find both of those point to be big limits to gaining value from the data.

 And If you're not a UK Payroll customer you can...

(create your own list of ineffective workarounds here).

In all seriousness, you choose the best ineffective workaround that meets your needs. I've seen companies say:

- Store it in the local payroll systems - Great, that covers the taxation aspect but most companies in Europe operate at least one payroll system per country. Trying to get a report of all employees who have a car for compensation purposes is a lengthy hassle that involves contacting local resources and compiling reports.

- Create a dirty little custom solution, such as a .NET app - Great, but how many .NET apps do I need to create and does HR need to use instead of just using the core HCM?

- Go back to the Excel / local payroll combos we all know and love so well - Back in the early days of HRIS this happened quite a lot. Central HR needed to track X while local HR took care of Y in local payroll. It's not a great solution as it entails double data entry but it's certainly possible and was all the rage in 1983.

I plan to do an update nine years from now and sincerely hope that we're in better place at that time. In the meantime, happy motoring. 

As always, differing opinions fully welcomed in the comments or by email, always open to new ideas and perspectives. :-)