Leave Types and Locations
REACH has been designed to allow schools to manage Boarder movements in one of three ways:
What is a Leave Type?
- By requiring that Leave Requests be submitted for approval PRIOR to actually going on Leave (Pre-Approved Leave Request)
- By allowing On or Off Campus movements that have been PRE-approved by schools (and parents if the school requires/allows)
- By automatically creating “Approved” Leave Requests ad hoc
REACH allows schools to define how REACH behaves when Boarders or Parents submit Leave Requests. This “definition” is done via Admin -> System Config -> Leave -> Leave Types.
A Leave Type represents the rules regarding individual Leave Types that a Boarder/Parent can apply for. This includes:
- Which year levels are allowed to apply for this type of leave
- Whether you require notes to be provided or not
- Which actors (see below) are involved
- The order in which each actor is involved
- What communication methods are employed for Approved and Rejected leave (and Authorisation in REACH v3)
- Which staff members MUST be involved (an override for the default actors in point 3)
- Which staff members MUST NOT be involved (also an override for the default actors in point 3)
As you can see, Leave Types are sophisticated and as such, can be confusing. What is the definition of Leave Type?
Leave Types are defined as “Any time a Boarder needs approval to go on Leave BEFORE they come to sign out for that Leave”. This means that if pre-approval is required then you’ll need a Leave Type.
That’s not to say that some Boarder movements cannot be ad hoc, nor that you have to do one and not the other. Leave Types are simply a set of rules that REACH uses when “pre-approved” leave is required. How should I define my Leave Types?
Your Leave Types are completely unique to your school, but there are some consistent patterns that Touchline Connect has found with all of our customers.
An extremely common Leave Type is one where a Leave Request is submitted by a Boarder, needs to be approved by their Parents and Host first, then needs to be approved by a Leave Approver before it is considered “Approved”. Let’s take this Leave Type as an example.
As stated above, to define a Leave Type we need the following items:
Year Levels who are allowed to apply
- Year Levels who are allowed to apply for the Leave Type
- Whether you require notes or not
- Actor Approval Matrix Details
- Actor Override Details
This simply states whether you are restricting this Leave Type to one or more Year Levels or whether everyone is allowed to apply for this Leave Type.
You can have any combination of Year Levels excluding the “Everyone” option, or you can simply select the “Everyone” option instead of selecting each Year Level one by one.
If you have Year 7, Year 8 and Everyone selected, Everyone is the only option that is used, thus the Year 7 and 8 options are superfluous. Whether you require notes
Notes are a fantastic way of providing information that is not always clear with certain Leave Types. For example, if flight details are available for a Boarder’s leave, then the notes section is designed to be the place where you put this information.
Simply select the checkbox to indicate yes or no. Actors and the Approval Matrix
An actor is simply a person who is involved in the Approval process. Say, for example, you have a Head of Boarding (HOB) who manages two houses and two Heads of House (HOH) one for each House, each of these are managing Leave for Years 7-12.
The Leave Approver “actors” would be three people in this example. The Parent “actors” would be one or more Parents who have been associated with the Boarder. The Host and Boarder “actors” represent a single host associated with the Boarder AND the Leave Request, and the Boarder themselves.
So to process this Leave Request we have, in this example, 3 Leave Approvers, 2 Parents, 1 Host and 1 Boarder, a total of 7 “actors”.
The Approval Matrix allows you to define which actors NEED to approve, the ORDER in which that approval must occur and how to communicate with those actors when Leave is Approved or Rejected.
REACH v3 introduces a new comms method called Authorisation, which allows you to expand upon the default EMAIL ONLY Authorisation that REACH v2 currently implements. Defining the rules
Let’s make up an example Leave Type called, “Weekend Leave”. For weekend leave we want the Boarder’s Parents and Host to approve the leave first, then we want to have ALL of the staff Leave Approvers to have a chance to approve.
The rules here are extremely common across our existing customers and are defined as such:
- Label is: Weekend Leave
- Who can apply: EVERYONE
- Note Required: No
- Approval Matrix
- Leave Approvers checkbox TICKED
- Leave Approvers order 2ND
- Leave Approvers Approval Notification - Leave it blank… we’re happy to not inform the Leave Approvers that they just Approved this leave request
- Leave Approvers Rejection Notification - Again, Leave Approvers can be blank here as they’re the ones who have just committed the action
- Parent checkbox TICKED
- Parent order 1ST
- Parent Approval Notification - Check Email
- Parent Rejection Notification - Check Email and SMS and PUSH
- Host checkbox TICKED
- Host order 1ST
- Host Approval Notification - Check Email
- Host Rejection Notification - Check Email and SMS and PUSH
- Boarder checkbox UNTICKED
- Boarder order N/A
- Boarder Approval Notification - Check Email
- Boarder Rejection Notification - Check Email and SMS and PUSH
- Staff Overrides leave blank
Ok, this “seems” like it’s complicated but let’s examine what we’re really saying here.
The Label, who can apply and notes required are pretty self explanatory. Approval Matrix Explained
In the above example we have Leave Approver, Parent and Host checked but Boarder was not checked. Why do we do this?
Well ticking the checkbox next to the actor tells REACH that they are participating in the approval process. Since we don’t want Boarders to participate in the approval side of things we simply leave them unchecked.
There are cases where Boarder Only approvals are extremely valid but that’s another story.
Also, we’ve set Parent and Host order as both 1st, what does that mean?
REACH has an escalation order in that, when ONE person from an actor group (remember, Parent can be Mother, Father, Step Mother, Step Father, etc.) has ACTIONED the Leave Request, REACH considers that actor group to have Approved/Rejected the Leave Request.
REACH then looks to see if there are any other actor groups at the current level. Since the Host actor group is also at the 1st level, REACH simply waits until the Host actions the Leave Request.
This allows REACH to say, if the Host approves first then the Parent, the behaviour is identical to that of the Parent approving first then the Host. Obviously these actors might not get to their emails in a timely fashion so instead of holding things up, we simply allow any of those actor groups to action the item when they’re ready.
REACH then escalates to the next highest order level when ONE person from each actor group at each level actions the item.
If the Parent approves the leave request and the Host rejects it, the Leave Request is terminated right there and then. All parties then get sent a communication (via whatever method(s) you have specified above - in this example, Email, SMS and PUSH) stating that the Host rejected the Leave Request for whatever reason they specify.
If anyone rejects a leave request at ANY stage, the Leave Request is considered REJECTED and the Rejection Notifications are sent out to whomever you’ve specified in the Approval Matrix above.
When the Parent and Host actor groups approve the Leave Request, REACH checks for any other actor groups at level 1. If none are found it escalates to level 2. In this example REACH finds the Leave Approvers at level 2. ONLY then will the Leave Approvers even be informed that the Leave Request has been submitted (obviously if the Leave Approver logs into REACH they’ll SEE the request, but they won’t be emailed requesting authorisation until it has been escalated to them).
Again, once ONE of the Leave Approvers has granted Approval or Rejection the same methods are applied and the appropriate notifications are sent out.
REACH once again attempts to locate any other actor groups at level 2. In this case it finds none and escalates to level 3. Since no actor groups are found at level 3, REACH considers this Leave Request to have reached FULL Approval.
This then sets the state of the Leave Request to Approved which allows the Boarder to SISO out on that Leave Request. Staff Overrides (Advanced Leave Type Configuration)
As stated above, actor groups can contain ANY number of actual people, and the list of the people involved depends specifically on the Boarder making the Leave Request (or for whom the Leave Request is being created for).
For example, say the HOB wants to be aware of all Leave Requests for both houses, but the HOH for each house only wants to be aware of Leave Requests for their respective Houses, how does REACH differentiate between them?
Each Boarder has a House and Year/Grade associated against them. Each Leave Approver has a corresponding “Groups Managed” item checked against them (Admin -> Staff Management -> Select the Staff Member -> Groups Tab).
HOH 1 would have House 1 and Years 7-12 checked whereas HOH 2 would have House 2 and Years 7-12 selected. HOB would have EVERYTHING selected.
Let’s say a Boarder in House 1, Year 9 applies for Leave. REACH then asks, which Staff members are Leave Approvers, it then finds ONLY the Leave Approvers who are set to approve leave for House 1 and Year 9. In this specific case, it would be the HOB and HOH 1.
So the Leave Approver actor group, in this specific case, comprises of HOB and HOH 1.
Now, let’s say for example we have a situation that requires a FOURTH Staff member to be involved, even if they’re NOT a Leave Approver. The first Staff over-ride says, IF you specify a list of Staff members, the DEFAULT list of Leave Approvers (in this case HOB and HOH 1) will be OVERWRITTEN and ONLY the Staff members selected will participate in the Approval Process for this Leave Type.
This feature is for Leave Types that are exceptions to the rule. It also allows you to temporarily promote Staff to Leave Approver status on SELECTED Leave Types only (by adding them when you want them to be a part of the process and removing them when they’re finished).
Now, let’s say we have the exact OPPOSITE scenario. The Leave Type has the defaults of HOB and HOH 1 in this example, and now the HOB says, for this Leave Type, I’m happy for the HOH’s to handle it, I don’t want to be involved or made aware.
By selecting the HOB in the second Staff Override list you are EXCLUDING them from participating.
This allows you to prevent people from being sent Authorisation requests WITHOUT having to manually specify each Staff member for each Leave Type, over and over again.
Both these overrides are EXCEPTIONS to the rule and will only apply if you have complex Leave Type requirements, though REACH does support these restrictions out of the box. Locations, what are they and how do I use them?
If a Leave Type is defined by “needing approval prior to going out on Leave”, then should I create a Location for every “location” a Boarder can go to?
In short, the answer is no. If a Boarder submits a leave request for Aunty Sarah’s house, having a location called “Aunty Sarah” will allow you to SISO (Sign-in Sign-out) them to Aunty Sarah’s, but this location is only ever used by one (or a few) Boarders at best, and in the end, your Location list will grow into the thousands.
A location is a GEOGRAPHICAL location that a Boarder can BE at. That being said there is a “special” location called “Approved Leave” in REACH v2 which will be removed in REACH v3 to avoid ambiguity.
Locations, such as Gym, Cricket Oval, Local Shops, Mc Donalds, etc. are prime candidates for locations as they represent both On and Off Campus locations that Boarders can go.
Each Location can also be locked down to prevent Boarders from freely signing out to that location. Lockdown can be done by requiring a Boarder to enter their PIN number, requiring a Staff member to enter their PIN number or a combination of both. This security configuration is completely at your discretion.
When Boarders wish to go to a preset location, such as the Gym, the Boarder can come down to reception and find a staff member and ask for permission and the Staff member performs the SISO, or the Boarder can come down to reception and find a Kiosk terminal and SISO themselves. They can also SISO directly from their mobile device by logging into REACH as themselves and updating their Location in the Quick SISO widget.
Unattended SISO can be disabled by means of locking down Locations to requiring a Staff PIN, or by selecting NO in the System Configuration -> Leave -> Allow Boarders to see Off Campus locations item. So what’s an Ad Hoc Leave Request?
Let’s say, for example, Boarder John Smith comes down to reception and asks whether he’s allowed to go to the Gym. In this case the Gym is on campus and is an approved location for Boarders to go to.
There are two options that REACH can process here:
- Allow the Boarder’s “location” to be updated to Gym
- Create an Approved Leave Request for the Boarder to go to the Gym and set a DEFAULT amount of time that the Boarder is allowed to be at the Gym before REACH determines that the Boarder needs to be back
In instance #1 we see that the Boarder’s location has been updated only. This tells ALL staff where the Boarder is. All attendances taken will state that the Boarder is at the Gym and during an emergency, the Boarder’s location will be displayed to all staff.
When the Boarder returns to the Boarder House they simple SISO back in by selecting their photo in Kiosk View and selecting the Boarding House to which they have returned.
In instance #2, REACH can be configured to say, whenever I select a location (in this case the Gym), create an automatically Approved Leave Request for X number of minutes and SISO the Boarder out to “Gym” all with the press of one button.
The Location can still be locked down to requiring PIN numbers, but instance #2 gives schools the ability to automatically create a record in REACH to state when the Boarder SHOULD be back at the Boarding House.
So when a Location with a Default Leave Request is triggered, REACH will automatically create a Leave Request on behalf of the Boarder, requested by the Staff member who triggered the event, Leaving “now” (ie. when the Location button was pressed) and returning “now” + X number of minutes as stated in the Location Configuration.
This Leave Request is identical to any other, thus if the default amount of time is not satisfactory in this specific instance, the Staff member can simply go to Metrics View, look for the Leave Request created and alter that Leave Request return time accordingly. Conclusion
Whilst Leave Types and Locations can be daunting due to their level of sophistication, that complexity is there to serve your school.
Understanding the difference between Locations and Leave Types will give you a greater understanding as to how REACH behaves when you use either.
The short rule of thumb is, if the event requires pre-approval by Parents/Leave Approvers, etc. then make it a Leave Type. If the event requires Staff approval only (or no approval what-so-ever) then make it a Location. If the event requires Staff approval only to go somewhere then make it a Location with a PIN attached to it.
That way, anything that requires pre-approval can be configured to behave in a consistent fashion. Anything that is ad hoc and does not require pre-approval can be handled by a location change and anything that requires Staff to intervene can simply be a location change locked down to requiring a Staff PIN.
If you ever have any doubts as to what you should create then please contact the REACH support team (email@example.com
) and pose the question. We can then advise you on the best configuration that would suit your specific situation.