The Back-End

Introduction

The back-end to this system is Microsoft SharePoint. I know many folks are hesitant to use SharePoint due to previous negative experiences, and admittedly there is a lot about SharePoint that I don't like either. That said, in my opinion, SharePoint online has incredible value in the SMB space as most small businesses already have a 365 subscription because they need office, email, or some other Microsoft service and in most cases SharePoint is already included.

Permissions

Create a role called FormUser that allows Read and Add access, this can be done from Site Settings > Site Permissions > Permission Levels > Add a permission level.

As you create your lists you will want to go into the advanced list settings and change the item level permissions to only allow the end user to view items that they created, otherwise folks that can fill out these forms will be able to see all the other form entries.

As SharePoint does not have column level permissions for lists I recommend splitting up the lists ahead of time to account for your permission needs. While requisition and offer letter forms could technically be rolled into a single list for you may have folks in other departments that need to look at particular lists and don't need access to things like the offer letters or new hire info.

Lists

Assignments

The first list to create is assignments, or what groups and permissions you will assign to users later. If you have Azure AD P1 or P2 you could assign licenses via groups and skip the the 365 license column in the job titles list later.

Departments

The next list to create is a list of departments. In addition to the columns below I have also used columns to track cost centers, supply purchase approvers, and pay change approvers to give you an idea of how this can be extended.

Job Titles

Next up is Job Titles. I enforce the use of a new job title form to ensure job titles are uniform (project manager II vs project manager 2), and to give IT a heads up to figure out what access a job title will need. Once you have job title uniformity in your directory you can start doing string matching in workflows and not worry about catching every variation of a job title before processing conditions specific to a job title. I also utilize calculated columns to predict how much a particular job will cost in terms of up front and recurring IT costs over 1 year and 5 years.

Locations

This one is pretty straight forward, in addition to the columns below, If you do location based access to certain groups you could add an assignments lookup column here.

Requisitions

Here's where we get into the meat and potatoes of the system. In my mind the process for this system usually starts with a job requisition (unless it's for a brand new position in which case one would start with a new job title form). Filling out the form associated with this list can simultaneously let HR, Accounting, and IT know that actions for each department need to be taken, buy a laptop, make job postings, allocate budget, etc. Using Power Automate in the workflow section of this guide you can deliver this information to each time how they would like to receive it, email, IT ticket, etc. You can extend this with more fields you will likely want to work closely with your HR department on.

Offer Letters

Offer letters are basic, because of the nature of compensation info I tend to keep this list separate from the new hire list as typically only HR and Payroll need this information whereas most IT folk do not. If you choose to use this list be sure to communicate to your end users that fill out the form that it is different from your new hire form and that once an offer has been accepted that they should fill out the new hire form.

New Hires

The new hire form has some obvious fields, first name, last name, preferred names, notes, etc. We also have some more complicated columns like the lookup to the requisitions, job titles, and location lists. I try and limit the amount of questions I ask managers about the new hires as much as possible - if you know what job title someone has you should know what department they're in, what standard access they get, what doors to allow their keycard to open, etc. Try and put as much of that in the departments and job titles list as you can and automate these actions. I find that the more questions you ask hiring managers the more opportunity you give them to give you wrong answers.

I also like to ask for pronouns, I'm not trying to be the keeper of pronouns but I make pronouns a choice column instead of a write-in. I use a choice column to:

• Ensure the text fits in our directory application
• Ensure consistent formatting "He / Him" vs "He/Him".
• Preventing abuse or anything inappropriate showing as an available option.

If folks want an additional pronoun or set of pronouns added I add them as options in the choices for that column. In the future I'm thinking about adding a Microsoft form that gets sent to an employee's personal email when they get hired and then feed back into the system vs having the hiring manager fill this out but that's a project for another day.

Changes

Ch-ch-ch-ch-changes! I prefer to have a consolidated change form but you may want to split this out into multiple lists if you have a permissions need. I use a Boolean column for Job Change, Pay Change, Manager Change, and Name Change and then an associated Boolean column for if the task has been completed.

Terminations

A lot of this is going to be very specific to your organization, work with your HR department to figure out what fields you need. I would just recommend that you still try and follow the principle of asking fewer questions. I include an IT approval so an account doesn't get deactivated without an IT person touching the ticket. I recommend using a field for last day worked for payroll purposes and a field for termination date and time for account deactivation purposes.

Versions

This list will be used to check if the Power App for the forms is up to date since they get cached and can run older versions of your forms for quite a while. This will allow us to create a prompt later that tells a user to refresh their page.