We’re data focused. It’s what we do better than almost all the other UKG consultants we’ve met.

But too often, it’s hard to get the right answer. No matter which API or reporting tool you choose. You need to perform the data double backflip with a twist. With your eyes closed.

Because the setup isn’t right.

Read more…

In California if a person doesn’t take a break after five hours, they receive extra pay. Unless they attest that it was their choice to skip the meal. A similar rule applies for rest breaks.

UKG has standard functionality to handle this but it’s not straightforward. Our client had an added challenge. Some of their employees use a different system to enter time and attestations. that data needed to be interfaced.

Read more…

Here’s a list of all our UKG Pro related posts. Let us know if you have questions or other topics you’d like to see covered.

UKG Data Integration

• UKG Pro
  • UKG Pro Rest API Example in Postman and PowerShell
  • UKG Pro – Reports as a Service vs Rest API
  • UKG Reports as A Service in Postman
  • UKG Pro – Assigning Platform Configuration Field Values to Business Rules
  • UKG Pro – Importing Simple Business Rule Values
• UKG Pro WFM
  • Kronos – UKG Dimensions API Postman Example
  • Kronos Workforce Central to UKG Dimensions: Does SQL Still Matter?

Data Warehouse – Power BI/Other Tools

• UKG Pro
  • Using Power BI with UKG Pro/UltiPro
  • Power BI and UKG Pro
  • Connecting UKG Pro Employee Job History to your Data Warehouse
  • Connecting UKG Pro to your Data Warehouse – Payroll Detail.

UKG Reporting

• People Analytics – Cognos BI
  • Before you train on UKG People Analytics
  • UKG People Analytics Quick Tip – Cut Your Columns
  • UKG People Analytics Quick Tip  – Parentheses in Formulas
  • UKG Pro People Analytics – Labeling Data Items and Pages
• UKG Pro WFM
  • Data Hub vs People Analytics for UKG (Kronos) Dimensions
  • Figuring out the apply date in UKG Kronos Dimensions Datahub

Our last post discussed payroll history challenges and your data warehouse.

Today, you’ll learn about challenges involving Employee Job History

You know that it’s not enough to know what your job counts and job titles are today. You need to know what they were last month, last quarter, and last year.

Read more…

You want your UKG Pro data in your Data Warehouse. We’ve touched on why we -recommend reports as a service here. You’ll never pull all your UKG data into your data warehouse. It’s too large and too much of it is only important for HR, Benefits and other compliance purposes.

So, what should you put in your data warehouse?

Read more…

Why We Use Reports as a Service over Rest APIs with UKG Pro

You need to decide how to get your data from UKG Pro. We recommend Reports as a Service (RAAS) even as we also support Rest APIs. Here’s the data.

1. It provides the most data
   We’ve found all the data we need in People Analytics. While the API list is long, it’s not FULLY comprehensive. For example, the Employee Pay Statement shows everything the employee sees on their check. It doesn’t show Org Level Job allocations. If you do a lot of payroll analysis, this doesn’t work. If you’re like all my customers, you have at least SOME people that work in multiple departments and even in multiple jobs. If someone has found an API that provides this detail, please, please, please let me know I’m wrong.
2. RAAS leverages user knowledge.
   There are plenty of folks who know how to use people Analytics. We want to leverage that knowledge. Consulting time is expensive. You should pay for what you need, not for what you can already do. Of course, if you don’t have People Analytics expertise, we are happy to help
3. RAAS is one thing to learn.
   There are lots of APIs. And they all work. But they all work differently. Which means every new piece of data means something new to learn. We’ve learned most of them. But it wasn’t fun.

UKG Pro Rest APIs have their place. If you want to build your own user application, APIs can be the way to go. But for analytics, we think RAAS is the way to go.

Two other options before we leave.

UKG Pro also supports Informatica. Informatica is a complex tool and resources are expensive and not easy to come by. We prefer widely known tools like PowerShell. When you choose an approach, you want to make sure that you’re not dependent on a particular resource.

If you already have a cloud data warehouse like Snowflake or RedShift, you have another option to consider. Portable.io has created a pipeline to take data from UKG Pro directly into several cloud data warehouse like Snowflake and RedShift based on the APIs. We’ve been working with Snowflake for other purposes and as we learn more, we’ll be sure to post.

What have you been using to get your data from UKG Pro?

You want to understand how to run People Analytics Reports as A service (RAAS). If you just want the sample Postman code, you can request that here. Please note that the last step of the process requires a few lines of PowerShell outside of Postman. For your reference, here’s the UKG documentation.

Read more…

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.

Why would you choose us?

Read more…

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.

Read more…

This post will take you through a step-by-step Dimensions Rest API example in Postman. In our Postman example, we’ll be sending two requestions:

1. Access Token – This retrieves the access token which we need to run the next request.
2. Retrieve Person by Extension – This retrieves data about an employee.

If you just want the example code, we’re happy to send it to you.

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.

Again, I do suggest you read the documentation. We’re focusing on our particular Postman example. (And aren’t you missing SQL and your on-premise database already!)

Step 2 – Retrieve Person by Extension

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:

1. 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.)
2. Check what products this key may use.
3. 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:

1. Update the variables.
2. Run the authentication/AccessToken request.
3. 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.

And once again, we’re happy to send you the code.

*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.