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

If used correctly, WIM allows your Kronos solution to have a collective set of mission-critical solutions throughout your organization.

What it is WIM?

Workforce Integration Manager is a data integration tool that allows you to transfer data from one data source (such as the Workforce Central application, text file, or SQL query) to an output end point. That output destination can be a text file, database, XML document, or another ERP.

01 | Organize your Links (KNX)

When creating an import interface into Kronos using WIM, there are a variety of APIs to choose from. For example, if you need to update employee “demographics” this may include more than just Timekeeper data. One may be tempted to create just one link with 2 records connected to APIs. (Personality – “Employee Demographics” and PersonSkillAssign – “Employee Skills for Scheduler”). This shortcut is easier than making two separate links, right?

In a perfect world, putting both of your APIs in a single link wouldn’t be an issue, but if that multi-record link ever gives you an error, how will you know which API caused it: Demographics or Skills for Scheduler?

All the errors would be bundled in the same section of the log, which is why the best practice for producing import interfaces is to separate them by logical grouping. (In other words, keeping the “Demographics” API in one link and “Skills for Scheduler” API call in a separate link.)

Now the Interface Results Summary/Link Error Report will distinguish the Employee Demographics errors from those of the Skills for Scheduler Skills as unique steps. This empowers the developer to focus on the correct record and link!

Hence, this practice may require a somewhat larger up-front investment of time, but the heartache you’ll save yourself when troubleshooting errors makes it advisable.

02 | Assign your Fields to Variables Names

A common sidestep WIM developers subscribe to is not assigning variables to fields. For instance, 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”. Why is this a problem? When you’re exporting 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 export data from a table in Kronos, your input is a SQL call, and your output is a CSV file. The table has 25 columns, and requirement asks for five of those positions changed—possibly they’d like the first column to be “employee number” instead of “first name.” If you took the familiar shortcut of not assigning variables to your field, changing that column is going to take an extensive amount of coding.

Most developers generally make this mistake once (and spend hours fixing it) before they commit to the habit of assigning variables to fields!!

Assigning variables to fields

03 | Special Lookup Tables are Overlooked

Generally, a developer working in WIM will make variables that derive values from static text, source fields, calculations, and SQL Queries prior to output. A frequent practice in this circumstance is to run a SQL call inside that variable as a detail type interval. Why is this a problem?

For instance, a requirement could be to return 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….)

Therefore, the best practice for a Workforce Integration Manager when you’re using SQL to retrieve information for hundreds of employees is to use a special lookup table. Special lookup tables are lookup tables generated at the time a link is run. They are refreshed with the latest data available from their source.

In this case, the 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?”)

Special Lookup Tables Closeup

04 | Leave a Legacy, Document the Interface

When you open the interface or link in WIM, click the General Tab and there is a section labeled Description. At a minimum the following should be keyed here:

  • General summary of what the link or interface does
  • The developer’s name
  • Company’s name
  • Date the link or interface was deployed


Another good place to document is the comment section for each variable. I admit that my cool variables are not always enough to tell the story!


The Configuration Report can give you a leg up in documentation if you took the advice above.


Leave a Reply

Your email address will not be published. Required fields are marked *