Unused Employee Access Groups in Kronos

Back in April, I wrote about how to clean up Employee Access Groups in Kronos. Specifically, I looked at how to identify inactive labor levels that were still assigned to an access group.

Another bit of maintenance that I like to do is periodically removing unused access groups. I frequently create user-specific groups. When that employee is no longer with the organization, there is no need to keep their access group hanging around. It just clutters up the list of available groups and is one more item you may have to audit.

Fortunately, the query to identify unused groups is very straightforward. All we have to is join over to the 'prsnaccsassign' table, get a count of how many managers are assigned to an access group, and then limit the output to those access groups with a count of 0.

select
    laboracctsetid 'LAS ID',
    shortnm 'Mgr Acces Grp Name',
    count(personid) 'Count of Mgrs Using'
from
    laboracctset
left outer join
    prsnaccsassign
on
    laboracctset.laboracctsetid = prsnaccsassign.mgraccesslasid
where
    labacctsettypeid = 2
group by
    laboracctsetid,
    shortnm
having
    count(personid) = 0

Again, just like last time I'm filtering on labor account sets being used as Employee Access Groups (labacctsettypeid = 2). Also, I'm running this across all employees, not just active ones. If an access group is assigned to a terminated associate, it will still get a count and be excluded from this report.

The LORD bless you and keep you; the LORD make his face to shine upon you and be gracious to you; the LORD lift up his countenance upon you and give you peace.
Numbers 6:24-26 (ESV)

Cleaning up Kronos Employee Groups and Labor Level Sets

In Kronos Workforce 6, one the key components of security is the Labor Level Set when used as an Employee Group. These sets restrict the employees that a manager can see.

One issue with these sets are that they are not self-healing or self-maintaining. If you deactivate a labor level entry, it will still be included in a labor level set. While this doesn't directly cause any harm (it won't grant someone access to employees they shouldn't, for example) it can negatively impact system performance. Why include a condition that is no longer valid?

Unfortunately, there are no system-delivered reports that will identify inactive labor level entries assigned to sets. Likewise, there is no magic "cleanup" button that will just go through and remove them for you.

This became a specific pain point for me just recently. We went through a major account change in our financials system that reworked a bunch of our labor levels. This rework included inactivating a lot of old ones that are no longer used. This was coupled with a quarterly audit report of manager accounts that showed exactly what labor levels each manager had access to. Seeing a lot of old inactive departments included on the audit report caused a bit of consternation and raised a few yellow flags.

The question then became, "What is the easiest way to clean up the labor level sets?" In our case, we completely changed our naming schema, so it was pretty easy to tell the old accounts by visual inspection. However, I didn't relish the thought of manually going through hundreds and hundreds of labor level sets looking for old labor level entries to remove. Instead, I poked around in the database schema and was able to come up with a query to identify inactive entries for me.

This query was written against the 6.0 schema on SQL Server 2005. If you are on Oracle, you may have to tweak the syntax slightly. I don't believe these tables have changed in the 6.x product line, so it should work all the way up to 6.3.

select
    laboracctset.shortnm,
    laboracctset.laboracctsetid,
    llelabacctstmm.laborlevelentryid,
    laborlevelentry.laborleveldefid,
    laborlevelentry.name,
    laborlevelentry.description,
    laborlevelentry.inactive
from
    laboracctset
inner join
    llelabacctstmm
on
    laboracctset.laboracctsetid = llelabacctstmm.laboracctsetid
inner join
    laborlevelentry
on
    llelabacctstmm.laborlevelentryid = laborlevelentry.laborlevelentryid
where
    laboracctset.labacctsettypeid = 2 and
    laborlevelentry.inactive = 1
order by
    laboracctset.shortnm,
    laborlevelentry.laborleveldefid,
    laborlevelentry.name
   
A few explanations are in order. The field 'LabAcctSetTypeID' in the LaborAcctSet table specifies what type of Labor Account Set it is. Since I was just worried about Employee Groups, I specified a value of '2'. The other possible values are 1 (All Sets) and 3 (Labor Level Transfer Sets).

I plan on adding this query to my routine maintenance checks, so that we can keep our Employee Groups cleaned up. Also, a partner query that I plan on writing is one that will identify unused Labor Level Sets. I prefer to keep these types of configuration items as lean as possible. There is no reason to hold on to old, unused sets if they're no longer used by anyone.

The LORD bless you and keep you; the LORD make his face to shine upon you and be gracious to you; the LORD lift up his countenance upon you and give you peace.
Numbers 6:24-26 (ESV)