Wednesday 14 January 2015

Proxy access in Workday

I was recently catching up with some former work colleagues who now work in a company that uses Workday.  They were not aware of the proxy functionality in Workday, so I put together a little info, maybe helpful for someone else too. 

What is the 'Proxy' functionality in Workday?

  • It allows certain users to switch over to *acting as* another user (without having to log in as another user).
  • It is only valid in non-production environments--you configure the ones where you want to use it.
  • It allows you to set boundaries--which users who can use it, who they can/cannot log in as, etc.
  • It's been available since 22 or 23 (off the top of my head)
 

Why use proxy?

  • For those in the trenches having to test out/approve functionality, this is a huge time saver.  
  • In particular, it saves you the hassle of having to create accounts, reset passwords, log in again, etc. plus the added risk of having those floating around.

How do you use it?

1. Log in as normal.  If you are a user with this access, then go to the 'Start Proxy' menu and choose who you'd like to proxy in as.  Here, Logan will proxy in and act as Steve:


2.  Test out whatever functionality you want.  You'll see whatever Steve has access to see.  Note the 'on behalf of' in the corner in case you forget who you're logging in as.


3.  Once you're done, access the 'Stop Proxy' menu, Confirm and hit OK.


4. There you go, you're back to your original access.


What is the configuration behind this functionality?

 

Here you go. 
  • Choose which non-production environments where you'd like to enable this functionality.
  • Choose any exceptions (CEO, VP's etc?)
  • Choose the user groups who can proxy.
  • Choose which user populations can be used for proxy testing.  This one is helpful if you have certain restricted groups, such as a European Works Council heavy country that you'd like to exclude.  As well, you might want to only enable a certain sub-population if you're just rolling out a piece of functionality to a certain population.

How do I know what Proxy functionality is currently enabled?

 

Run the report:


Overall:

  • I like this functionality a lot, I think WD got this one right 'out of the box,' instead of drip-feeding us a little preview functionality and then enhancing over 5-6 versions.
  • This is a huge time saver for people doing testing, enabling you to really see what a user sees without going through all the account creation jazz.
  • It's simple to run/stop and use.  Full points on the usability front here.
  • I haven't talked to my friends in compliance on this one, so no comments there.  I suspect that's why WD keeps it out of the Production environment, to minimize the risk on that front.

Saturday 10 January 2015

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

Tuesday 6 January 2015

DayNine hiring/training Workday consultants

A former employee recently approached me to be an employment reference.  She's in the 4th of 5 stages of interviewing with DayNine for a consulting position based out of London.  I've never worked with anyone from DayNine so I cannot vouch for their work abilities or culture although I casually met a few of their consultants in the past at some of the Workday sponsored events and meetings.  Their internal recruiter seemed pleasant enough and accommodating when scheduling my time to discuss her past performance.

Interestingly, from their website:  'DayNine is a professional services firm built from the ground up to support Workday. Workday is the leader in enterprise-class, Software-as-a-Service (SaaS), for managing global business.  We are 100% focused on implementing Workday.'

I find their lack of diversification quite interesting.

My former colleague is quite excited as she'd like to get to travel and DayNine will send their new employees to the US for full training.

So for those of you in the London area, as well as other areas outside of the US and looking to break into Workday, perhaps worth a look at their website.