Processing New Hire Checklists
I'm trying to build a set of checklists for my company that will help in processing new hires. The checklists themselves aren't hard, but I'm having a problem because each new hire will fall into one...
Forum Discussion
I have done New Hire checklist apps. A low tech solution is to use the copy parent detail wizard. Set up 4 model Employees. Use that wizard 4 times to create, respectively, 4 buttons to import children from specific records.
Then use a form rule to only show the user the correct button according to the EE type.
Then use a form rule to only show the user the correct button according to the EE type.
- I guess I must be using the Copy Parent Detail system wrong, can you give a few steps for this process?
- Well just follow that wizard but when it gets to a point it will ask you if you always want to copy children from a specific record, choose that option.
- Alternatively, you could use a Google Form, fill that in, and have the results imported into QuickBase.
IMHO if this is a checklist for IT, then it would be a bad idea. But if it's a checklist for other dept's, then it's a decent idea. In my company, we still have a word doc for the checklist for HR and the admin side. For my IT dept, we are walled off intentionally from that process as it doesn't work well for us.
If you break down the process, New Hires have many Checklists (New Hires < Checklists) so you can see how the relationship works.
If you'd like to provide an example of some of the fields you're using, I can make a demo app and share it with you quickly. - imho, since there is an easy native solution using Quick Base, I see no purpose in having to integrate with a google form.
Also once you get that first wizard field created, then it can be easily hand edited to make the three very similar button if you did not want to go though the wizard 3 more times. I believe in keeping everything native Quick Base for future supportability.
These days no one stays in a job for very long before they change companies or change jobs. Someone after you will inherit your app and its support. - I normally agree with native solutions, but QuickBase isn't always the "best" option for client-facing projects everytime. A Google form is ubiquitous and more simple to users than most QB interfaces by far. Retention is usually better in favor of Google more so than QuickBase.
We really don't know the whole use case here. I'm inclined to believe if new hires are being onboarded, that we need to know who is responsible for administering this document? Is it HR, a manager or the new hire themselves?
In theory, if it's just the HR Dept, then a basic example of his form is all we would really need to see or just an example of some of the fields. I find it hard to believe he would need a structure harder than ( New Hire have many checklists ).
If some of this information is stuff the new hire themselves need to fill out, there get a cheap tablet for a kiosk and have them fill out the form. Have the results saved to a table in Google which can be synced into QuickBase. Kills two birds with one stone and it's not hard to document or support. - In the apps I have done it is a combination of tasks which need to be completed by the HR department and the hiring manager. Not the EE.
