Key Field Work Around
I have an employee table where the Key Field is their Employee ID Number, now we are wanting to allow a new set of users to access and use this table; the recruiters. The problem is during the hiring ...
Forum Discussion
I had a similar situation and end up regretting using the Employee ID as my key. The only thing I came up with was using a temporary placeholder for the employee ID (if it is a text field it could be like TEMP-001, if it numeric maybe 99999, 99998,99997, etc) and changing it later.
The catch there is if you have any child fields, you need to write an automation that says if you change the parent key field, go through the children and change the related field to match. Otherwise, all your children will be orphaned.
In our company, they actually can switch employee IDs for a few different reasons (mostly if they switched internal departments/companies). I rebuilt my app so that I had an employee table with name, email, phone, emergency contacts, etc etc. Then an employee ID table that stored their employee ID, company, supervisor etc. The items that are specific to that ID. That helped me as I could enter the employee and add the ID later. I use the ID as a key so I can import time cards and other info, which I can still do.
However, I wish i had made the employee id a text field instead of numeric so i could have leading zeros.
------------------------------
Mike Tamoush
------------------------------
The catch there is if you have any child fields, you need to write an automation that says if you change the parent key field, go through the children and change the related field to match. Otherwise, all your children will be orphaned.
In our company, they actually can switch employee IDs for a few different reasons (mostly if they switched internal departments/companies). I rebuilt my app so that I had an employee table with name, email, phone, emergency contacts, etc etc. Then an employee ID table that stored their employee ID, company, supervisor etc. The items that are specific to that ID. That helped me as I could enter the employee and add the ID later. I use the ID as a key so I can import time cards and other info, which I can still do.
However, I wish i had made the employee id a text field instead of numeric so i could have leading zeros.
------------------------------
Mike Tamoush
------------------------------
Mike appreciate the response.... Actually it has provided me an idea!
Each recruiter be assigned a set of numbers 100, 200, 300 then they can use any of those they wish – if the person is hired, lets say their 112 would become the actual Emp ID.
Thank you,
Hans J Hamm
O: (770) 840-1840
[email protected]|www.advantagesolutions.net
This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
- I generally encourage clients to have a separate table for Candidates vs Employees. Once someone has been selected / hired, you could have the record copied over to the Employees table. This allows you to keep the workflows separate and you don't run into the issue of the Employee ID.
------------------------------
Blake Harrison
[email protected]
DataBlender - Quick Base Solution Provider
Atlanta GA
404.800.1702 / http://datablender.io/
------------------------------
