info@suretysystems.com

contact us
Select Page

Using Kronos Workforce Integration Manager—4 Common Shortcuts to Avoid

Jun 12, 2019

Home » Kronos » Using Kronos Workforce Integration Manager—4 Common Shortcuts to Avoid

Kronos Workforce Integration Manager (also known as WIM) simplifies the process of sharing data between your Kronos application and third-party systems, including human resource management, payroll, and Enterprise Resource Planning (ERP) systems.

If used correctly, WIM allows your Kronos solution to be completely collaborative with other business-critical solutions throughout your organization, which is great, because streamlining the process of sharing workforce data can improve efficiency, save you money, and reduce data errors. However, our consultants have found that clients are sometimes tempted to take shortcuts when using WIM—shortcuts that lead to costly repairs down the road).

Here are 4 common mistakes people often run into when using WIM, as well as how to avoid them:

1) Not Assigning Variables to Fields

One common shortcut WIM users take is not assigning variables to fields. In other words, developers create field definitions for records using position numbers from the source—such as assigning the first field as position 1, which aligns to the column “first name” in the source query—instead of following the WIM best practice of assigning each field a variable like “first name” or “employee number” instead. Why is this an issue? When you’re trying to export data to a CSV file and need to change the position of your columns, fields without variables are going to give you a lot of trouble. Here’s an example.

Let’s say that you need to pull from a table in Kronos, your input is a SQL call, and your output is a CSV file. Your table has 25 columns, and someone wants five of those positions changed—perhaps they’d like the first column to be “employee number” instead of “first name.” If you took the common shortcut of not assigning variables to your field, changing that column is going to take an extensive amount of coding.

We find that people usually only make this mistake once (and spend hours fixing it) before they always make it a habit of assigning variables to fields.

2) Not Using Special Lookup Tables

Oftentimes, a developer working in WIM will create variables that get their values from static text, source fields, calculations, and SQL Queries prior to output. A common shortcut people take in this situation is to run a SQL call inside that variable as a detail type interval. Why is that an issue? Let’s take a look at an example.

Let’s say you want to look up the most recent status of an employee. If they’ve ever taken leave time, that person may have more than one status at your company. Kronos stores all of these statuses as different records, so if you don’t define that you’re only interested in the most recent record, it could pull all of the records. (Now imagine how long your interface will run trying to process 50,000 employees record-by-record….)

That’s why the best practice for WIM when you’re doing anything related to SQL is to use a special lookup table. A special lookup table assigns one value for each employee, and that value will be the same no matter how many records the employee has. Using a special lookup table first will help with the performance of the interface, since it knows exactly what you’re asking it to look for. (It’s like the difference between giving a librarian the ISBN for the book you want instead of saying, “I think it had a blue cover?”)

3) Putting APIs in One Link

When someone creates an interface in WIM, they have a variety of APIs to choose from. For example, if you have an API for “demographics” and another one for “attendance,” you might consider taking a shortcut by putting both of them in one link. Easier than making two separate ones, right?

In a perfect world, putting both of your APIs in a single link wouldn’t be an issue, but if that doubled-up link ever gives you an error, how will you know which API caused it: demographics or attendance?

You wouldn’t, which is why best practice for using APIs when creating interfaces is to separate them by logical grouping. (In other words, keeping the “demographics” API in one link and “attendance” API call in a separate link.) Doing so may require a slightly larger up-front investment of time, but the grief you’ll save yourself when troubleshooting an error makes it worthwhile.

4) Not Documenting Your Interface

When you open the interface in WIM, there’s an intro section where you can put the name of the person wrote the interface, name, date, etc.. Far too often, people don’t enter this information in an effort to “save time” (AKA a shortcut). Not only is that information valuable by itself, but you can also put even more detail about purpose and variables in the intro section of the WIM interface, which means people won’t have to look at the data behind the scenes to identify it—saving you more time in the long run.

A Word doc is a great place to put this sort of documentation so that it’s easily shared, whether that’s with someone who needs to make changes down the road, or if you need a consultant to help with your system.


We hope these simple tips help save you time and some hassles when using WIM. If you need additional support, our network of senior-level Kronos consultants can assist with integrations, perform system assessments, and migrations (just in case you’re thinking about moving to Kronos Workforce Dimensions, for example).

Search
Generic filters
Exact matches only
Filter by Custom Post Type