Add effective date to 'Employee Type'

  • 2
  • Idea
  • Updated 1 year ago
  • Under Consideration
It would be helpful to have an 'effective' date added to the user profile when the employee type changes from contractor to FTE.
Photo of Green, Melissa

Green, Melissa

  • 8 Posts
  • 0 Reply Likes

Posted 1 year ago

  • 2
Photo of Aashnee Kamboj

Aashnee Kamboj, Community Moderator

  • 1446 Posts
  • 104 Reply Likes
Hi Melissa,

Thank you for sharing the idea. Currently you can setup a user level custom field to track the date of employee type change. That will help you know when the user was changed to FTE from contractor.

Thanks,
Aashnee 
Photo of Richard

Richard, Design Team Manager

  • 63 Posts
  • 7 Reply Likes
Supporting effective dates on things like "Employee Type" does make a lot of sense.  It is something we would like to support, but is not something we currently have a set plan to complete. 

The direction we are going with our product is to introduce new groups (Cost Center, Division, Location, and Service Center) which have been built from the ground up to support effective dates.  These handle not only the simple situations with effective dates, but also do the harder parts for getting the data security and reporting right.  Each group type can be renamed to let customers label and use each of the 4 group types in a way that makes sense to their business.  Once groups are fully rolled out across the who application, Employee Type and Department will be converted into groups so that they can get all the same effective date and data access functionality as groups.  Currently groups have been added to most of the app, but there is still a ways to go.  The main part missing groups are projects which only supports department.

For your case with wanting effective date on Employee Type, I would recommend seeing if groups can be used instead.  Since employee type is not used in projects, group support in projects will not be a problem for you.  If there is nothing missing functionally wise, switching to use a group instead of employee type would get you the full timeline support that is missing from employee types.  The renaming should help avoid training issues by letting you name the group something that makes sense to your employees for an "employee type" replacement.