Follow

Vacancy Requisition goes by many different names - some of our customers call it Authority to Recruit or ATR, the VRF or the RAF (not to be confused with the Air Force, obviously); while others simply call it the Requisition or Req Form

Whatever you end up calling this part of the process, this is ultimately the form your Hiring Managers complete when raising a new Vacancy within the Hiring Manager Portal.

The Vacancy Requisition Form is one of the first fully customisable parts of the system that you need to think about.  It will also be, generally, the first step in your Recruitment process.

The key thing to know about customising this form is that it's not something you can do yourself - this has to be done by your Implementation Manager.

The obvious question then is, how does your Implementation Manager know what to put on the Requisition Form?  The answer is simple, we ask you to fill in a Specification form - which is what we'll be looking at in this article.

To jump to a specific part of this article, please use the links below:

How many forms do I need?

As with many things inside Eploy, such as the Recruitment and Authorisation workflows, Application and Onboarding Forms; you can have multiple Vacancy Requisition Forms.

As part of your initial scoping conversations, you'll have already decided whether your Hiring Managers can raise a requisition from scratch (i.e. a blank document), copy an existing Vacancy or use Vacancy Templates (the most common option); and as part of that conversation you'll have decided whether the same Requisition Form can be used all the time or whether you need a different form for specific circumstances.  

You'll also have decided whether the different areas of the business need different Requisition Forms, or whether it's ok for everyone to use the same form.

None of this is set in stone, however.  As projects move forward, requirements change and we have a Change Control process in place to deal with these changes as and when they arise.

The key thing to think about is that just because you can have multiple requisition forms, doesn't mean you need multiple requisition forms.  The main drawback of having several requisition forms is that when something needs to be amended, it'll have to be amended across several forms, whereas if you have just the one form, the change only needs to be made once...plus changes to the layout of each form can only currently be done by Eploy - it's not something you can change yourself.

Ok, so I'm having one Requisition Form, how do I ask specific parts of the business different questions?

This is a question that comes up frequently - you're only going to have the one, largely standardised form, but there are occasions where you'll need to ask different questions to different people.

Generally, we'd handle this by using, what we call, Show/Hide fields.

These are fields which appear and disappear (show and hide...see what we did there?) depending on how pre-defined conditions are met.

So, you could have a drop-down question on the page with several options available, and depending on which option is selected, subsequent fields can appear or disappear as required.

This behaviour cannot be added to the system by yourselves - again, this has to be done by your Implementation Manager, and they'll do this when pulling together your Requisition Form.  So it's really important that you discuss your requirements with them, in detail, so they know how to configure this behaviour properly.

What is in a "standard" Requisition Form?

Every business is different, and their requirements for Vacancy Requisition is different...so there's really no such thing as a standard requisition form.

What you'll find in your Eploy demo system is an example requisition form - something we have added in to help you get used to the system and have a play with as you're pulling together the specifications for your actual requisition form.

How do I fill in the Vacancy Requisition Spec form?

The Vacancy Requisition specification form can be found within the Files section of your project in Teamwork; however, it may also have been emailed directly to you by the Sales team or your Implementation Manager.

Tip even if this document has been emailed to you directly, we would always recommend using the version within Teamwork, as you can be assured that this is the latest version of the document.

In this document, you'll need to add a new Row for each Field you want included on the form, and in each column, tell us how you'd like it to behave:

  • Field - this is the name of the field in Eploy.  As a default, the field name in the HM Portal will be the same as in the Core System, but if you'd like it to be called something else in the HM Portal, note this in the Comments/Changes Required column
  • Field Type - here you can tell us what type of field this should be, and we have a series of options for you to choose from:
    • Boolean (Y/N) - this is a question which can have a Yes or a No answer and can be displayed as either a Radio Button (the circles that have a dot in them when you click them) or a tick box.  You might hear your Implementation Manager refer to this as the Render mode for the field
    • Date - a special number field, formatted to only accept dates (In Eploy, all dates have the same format - DD/MM/YYYY)
    • Drop Down - this option displays a drop down list.  Use this if you want to give your HMs several specific options to pick from.  You can edit the content of any Drop Down List from within the Core System
    • File Uploader - this allows the HM to upload a file, such as a Job Description.  
    • Long Text - this creates a large text box for your HMs to fill in
    • Numeric - this is a small text box formatted to only accept numbers
    • Multiple Choice - this will present your HMs with a series of tick boxes, allowing them to select as many options from the list as they choose.  The options available can be amended from within the Admin menu of your Eploy system (we'll teach you how to do this during the Customer Configuration phase of your Implementation)
    • Picker - this is a special field which allows your HMs to pick from a list of existing records from within the system
    • Short Text - this puts a small text box on to the Requisition
    • Title - Use this for section headers
  • HM Portal Enabled - with this option set to YES, the field will be active and visible in the HM Portal
  • HM Portal Read Only - With HM Portal Enabled set to YES, you can set this field to YES if you want the HM to see the field, but not make any changes to it
  • HM Portal Mandatory - with this set to YES, the field must be completed to allow the requisition to progress to the Authorisation stages.  Tip if you're going to set this to YES, make sure you also set HM Portal Enabled to YES
  • Comments/Changes Required - use this field to capture any additional comments or changes you'd like to make to the field, for example, if you want the field to be called something else in the HM Portal compared to the Core System, enter the change here.

As a default, the Vacancy Requisition form is broken down in to several sections: Pre-Insert Page, Requisition Details, Salary & Requirements, Job Description Upload, Advertising Details and Hiring Team.  If a section or group of questions isn't needed you can either delete them from the spreadsheet, or put something in the comments indicating that you don't want them in your requisition.

If you want to add a new section, insert a row in the appropriate place and add a Title field to correspond with the section heading.

In the video below we have filled in the Vacancy Requisition specification to match with the example Vacancy Requisition you'll see in your demo system.

Once you've filled in the Vacancy Requisition spec doc, you can upload it in to Teamwork, or email it to your Implementation Manager.  They'll review the form and come back to you with any questions.  Once they're happy, they'll use this spec doc to create your Vacancy Requisition form within the HM Portal.

 

Powered by Zendesk