Forum Discussion

HansHamm's avatar
HansHamm
Qrew Assistant Captain
5 years ago

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 process there is no Employee ID # assigned​ for the recruiter to use.
I need some type of work around - I want to retain the Employee ID Number as the Key Field, but I am not sure of a creative way to get around some of this.... and thoughts or ideas would be GREATLY appreciated!!

------------------------------
Hans Hamm
------------------------------
Tables and fields
  • MichaelTamoush's avatar
    MichaelTamoush
    Qrew Captain
    5 years ago
    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
    ------------------------------
    • HansHamm's avatar
      HansHamm
      Qrew Assistant Captain
      5 years ago

      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

      hans.hamm@advantagesolutions.net|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.

       



      • BlakeHarrison's avatar
        BlakeHarrison
        Qrew Captain
        5 years ago
        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
        bharrison@datablender.io
        DataBlender - Quick Base Solution Provider
        Atlanta GA
        404.800.1702 / http://datablender.io/
        ------------------------------