We’re nuts and bolts data consultants. So, we keep up with the latest but focus on the basics. To be successful in People analytics, your data must be:
Clean The article lists several excellent best practices for people analytics. First on the list: Examining the quality of your data. If you gave your company an HONEST grade on data cleanliness, what would it be? My sample is skewed. Folks don’t hire consultants if everything is clean and orderly. But would you give yourself better than a C? You can’t have any kind of understanding if you’re systems aren’t set up correctly and if your data isn’t consistent. Which goes back to the basics of HR Data Management.
In Context If you’re data is clean and reliable, it still may not be meaningful. How do you know if a given KPI is good, bad or indifferent? Case in point. We looked at turn over for a large non-profit client. In this case, 40% of new front-line workers left within 8 weeks. Which is not what a good number. But how bad is it? These are difficult jobs that paying close to minimum wage. So, how much better can they expect? The ease of getting comparatives depends on your industry. But it’s essential if you know that you have a solvable problem?
In Demand Who’s asking for this data? Have you built reports that no one in the business looks at? And so, behavior doesn’t change. You need to think how folks with OTHER priorities will work with your data. What will make sure that the knowledge you provide delivers the actions you desire.
As with many things, you need to get the basics right before you can do the cool stuff.
Where are you on your People Analytics journey? Let me know in the comments. And if you want to talk about how to get clean, in context, and in demand data, let’s talk.
There are many UKG Pro/UltiPro/Kronos/Dimensions consultants out there. And if you’re searching for help, all the websites may have started to merge together.
Everyone has years of experience, focuses on their client and delivers great results.
As a data person, you’ll find that platform configuration fields are among the most useful features of UKG Pro aka UltiPro. These are user fields on steroids, allowing not only to add data, but to validate that data. In order to validate that data, you’ll generally need to set up a custom business rule. I’m not going to go through all the steps for adding a platform configuration field as there is solid documentation on the web site. However, once you have the field setup, you’ll want to add values. And if you have lots of records to update, you don’t want to do that manually.
We’re not going to repeat what’s available in the documentation. If you’re new, you may wonder to get to the documentation. The answer is the developer portal.
You can find the Developer Portal under administration:
Or by searching:
If the developer portal does not appear, have your administrator confirm that your Function Access Profile has the appropriate access. The required access can be found under: Manager Common Setup -> Developer Portal -> Administration Access and Developer Access.
Please note that the account you’ll be using will need appropriate access to do whatever you’d like to do. You can’t look up an employee (as we’ll do in this example) if you don’t have access to the employee from with the application.
Now let’s show you how to find the documentation for our requests:
Dimensions Developer Portal Documentation
Step 1 – Authentication:
Unlike UKG Pro/UltiPro APIs which we’ve described here, Dimensions APIs require a two-step process. The first request gets you an access token which is then used in the second request..
To find the documentation from the developer portal, click on Authentication.
We’re going to use a simple API which retrieves data for a particular person. To find the documentation, click under People under the API column.
Now, expand “Persons” and scroll down until you see “Retrieve Person by Extension”
And you’ll find the documentation:
Please note:
You’ll find a search function at the top. However, I’ve found that it returns so many results that it’s at best “sub-optimal”.
Postman Example:
Dimensions Authentication/access_token
Now to postman.
For the first part
We’ll be looking at four parts of the postman request.
The URL
Headers
Body
Test
For this example, everything that will be custom to your site is stored in an environment variable.
The environment will be called UKG Dimensions – For GitHub:
Here are all the variables we’ll be using:
We’ll review each of these in depth. However, in brief:
The first three values were provided during implementation. If you don’t have them, you can open a case to get them:
VanityURL
Client_id
Client_secret
The next two are for the user that you will use to run the API
UserName
Password
The appkey will need to be setup within the application. We’ll walk this through further in the post.
The Person_number can be any valid employee number in your application TO WHICH the username has access.
The AccessToken is a variable to pass the value from the authentication request to the second request.
The URL
The URL tell us the API you wish to call and the type of API (POST, GET, etc).
Please make sure you pay attention to the request type. Some request which are just reading data use POST. (As I figured out in the middle of a support call. Oops.)
The request needs the vanity URL. The vanity URL should be provided by the implementation team. Otherwise, you’ll need to open a case. (It took very little time to receive the information)
Headers
You only need two values in the headers. The content type is standard.
You need to set up the AppKey in the Dimensions application.
To do so, go to Application Setup -> Common Setup-> My Apps
Then click Add:
Name your key. The name doesn’t matter and won’t be used anywhere else. (It can be called Fred. Not that I suggest that you do so.)
Check what products this key may use.
Click Save.
You should receive a message that the key was successfully created.
As I said, you don’t actually use the name you entered anywhere. Highlight the key (by clicking on it) and click details at the top:
Your appkey will appear. You may copy using the icon to the top right of the key:
Body
The body has six values, four of which are variables.
Client ID and Client Secret were provided at implementation. If you don’t have them, you’ll need to open a support ticket.
The Username and Password can be for any Dimensions user with the appropriate security.
Tests
The entire point of this request is to get the access token.
This very small piece of java script saves the accessToken into the environment variable so that it may be used in the next request.
Retrieve Person by Extension
So, now you have you’re AccessToken. You probably want to actually do something. We’re going to get information for a given employee. This is actually a simpler request. Let’s parse the postman step by step.
In this case, we’ll look at the request, the parameters and the Headers.
You’ll see that the request uses the same VanityURL we used for the access token. Thus the great value of variables.
Also, we have one parameter called person_number which we assign in our environment variables.
Headers:
The headers have three values, two of which are variables.
We’ve discussed both the appkey and the AccessToken previously.
Running the example.
To run the example, you need to:
Update the variables.
Run the authentication/AccessToken request.
Run the Retrieve Person by Extension Request.
(Note that we should be able to call the AccessToken Request directly from the Retrieve Person by Extension request. When I have that working, I’ll update the code).
After all this, you have JSON. Which you have to parse. Which is a topic for another day.
If you have questions or comments, please leave them below. Or contact us if you’re interested in training, development or consulting.
*They do have examples in Curl and Java. As a data guy who longs for the days when SQL was my tool, let’s just say that I’m not going to learn Java. Indeed, when we need scripting, we use Powershell. And everything needs to start with Postman.
Power BI doesn’t work directly with UKG Pro/UltiPro. However, there are ways to leverage your staff’s Power BI skills. Let’s summarize our main recommendations first and then dive into the details.
In this post, we’re going to give you a step by step walk through of using a Rest API with UKG Pro. (We’re planning on dealing with the SOAP API in a different post).
For this example, we’re using the employee lookup API. As a UKG customer, you can find the API documentation here. We’re happy to send you all the sample code.
It’s easy to setup a simple business rule in UKG Pro. And if you don’t have that many values to enter, it’s not a big deal to enter them by hand.
But if you have dozens of possible values, this isn’t so easy. Especially if you are working in test and eventually want to move to production without repeating all your work.
