Event types can be configured so they must be requested from line managers in advance. The primary supervisor and acting deputies are informed of new requests from their subordinates and can choose to approve or reject them. This allows more natural workflows to be achieved within the service and distributes workload from line managers to their subordinates.
A common use of this feature is holiday planning, but any kind of reservation or need for request and approval between line managers and subordinates can be managed this way. See the Common use-cases heading below, for more information.
Future versions of this feature will add the ability to opt for "in-site" notifications about requests, removing the need for emails from this workflow entirely.
The first step is to identify or create Worktime event types for the topic you wish to enable requests and approvals for. This can be done for the whole environment from Worktime > Administration > Working Community Settings > Work hours > Event types, or for specific setting groups from, Worktime > Administration > Setting groups > Work hours > Event types.
To configure an event type so it can be requested, it must be flagged as "Must be requested from supervisor". It is recommended that event types that should be requested are not flagged as "In use", "On terminal" or "From direct link", as requests by their nature, should be for a date in the future, not recorded in real-time.
After configuring the event type(s) to be requested, please ensure the Worktime roles (See Worktime > Administration > Worktime roles) for subordinates permit them to record events of that type from their calendar, and their supervisors can edit and approve them.
Once event type behaviours are set, and permissions are configured, subordinates will be able to make requests just like creating any other event.
Please note that if you wish to make use of the request email notifications, each person in the workflow, including supervisor deputies, must have a valid email address saved in Nepton. You can check this from Employees > Persons.
How to approve efficiently (Best practices)
- All pending requests are included automatically by default. Only set a specific date range when necessary, as this can increase loading times.
- The fastest way to use the tool is to systematically work through each person and their requests, selecting all requests that require the same action, before doing that action.
For example, cycle through each person and their requests and select each that should be approved using the related checkboxes. Once having checked all requests for approval, approve them all at once using the 'Approve' button. After that cycle through each person and remaining request again but this time select all the requests needing rejection. Once having checked all requests for rejection, reject them all using the 'Reject' button. Finally, handle any conflicts and individual messages and edits.
- The details of all requests for a person or date can be quickly viewed in the side panel by clicking the related name or date title.
- All of a persons' pending requests can be quickly selected or deselected using the checkbox on the left side of their name. The state of this checkbox is also an easy way to quickly find people who have, all, only some, or none of their requests, currently selected.
- When doing holiday and absence approvals, it is best to set a deadline for team members to make all their requests, so that approval for the whole team can be done in one go and with all the information.
- A requested event can be edited directly by clicking its title from the side panel. This opens the event editing page, similar to the Worktime > Work hours > Calendar view. Direct editing of an event can be useful for quickly resolving conflicts, correcting mistakes, or sending bespoke messages to individuals.
- Use the built-in messaging feature to handle comms about approvals directly from the approval tool. All people related to selected requests can be messaged at once with the message box at the bottom of the approval view. Messages can also be sent about individual requests by selecting the related person/date cell and editing the request via the side panel, by clicking its title or the add or reply to message link in its details.
Workflow & Notifications
The event requests workflow is between subordinates and their primary supervisor (and/or active supervisor deputies), and follows three main steps; Request, Review, and Approval.
During these steps, edits can be made to refine the request, and messages about the request can be sent between supervisor and subordinate from within Nepton. All edits, including messages, are recorded and can be viewed later in the event history. Relevant people are automatically informed of any significant actions on a request via email. More details on this can be found in each step described below.
Please note, that notifications are sent in near-real-time and will only reach people who have a subordinate/primary supervisor/supervisor deputy relationship at the time of the notification. Notifications will not be sent retrospectively if relationships are changed after the fact.
Making a request
New requests can be created by anyone with permissions to add events of that type. Requests are created in the same way as other events, but due to their nature, should be created for a future start date. Requests are easily distinguished in the calendar view, with a dashed outline and bright blue heading, as shown below.
A request spanning 4 days in an employees' calendar, waiting for approval.
When a request is created, the requester can record all the usual event information, including projects, supplements, attachments, etc. They can also optionally include a message to the approver. Messages about a request are collected into a conversation history and can be viewed when editing the request. New messages on a request, trigger a notification to the subordinate or primary supervisor and active supervisor deputies.
To help people create sensible requests, any accrual usage and projected balance after requests, are shown when the event is edited. Screenshot below. Please also see the dedicated heading about Accrual usage & predictions, below.
Unless the primary supervisor was the one creating a new request, the primary supervisor and any active deputies are notified by email, with a link to review and approve it.
The event editing form with accrual usage highlighted. In this example request, 4 hours of accrued balance leave are used, leaving 17 hours balance available immediately after the request, but minus 7 hours in total when considering all future requests and events. This implies the employee must accrue 7 hours more balance hours to have enough for all their requested leave.
In this example request, 12 days of accrued annual leave is used, making the balance at the end of holiday year -6 days after the request.
Reviewing and approving pending requests
Selecting requests in the Approve event requests
Approve event requests - table view is the default layout of the event request approval tool. Primary supervisors and their active deputies are notified of pending requests from subordinates via email, and also by visual "Pips" in the Worktime navigation. In later versions of this feature, it will also be possible to opt for in-site notifications about requests.
"Pip" next to Approve event requests in the Worktime navigation indicates that there are event requests that need approval.
Requests can be reviewed one-by-one in an individuals' Worktime calendar, or via Worktime > Workhours > Approve event requests, where all pending requests from subordinates are listed. Requests can be edited and approved or rejected by a person's acting supervisor. Access to Approve event requests - view requires permissions to approve events.
The Approve event requests view, from a supervisors perspective, with multiple requests waiting for approval.
The approve event requests view is designed to show a visual indication on how each person's event request spans in the selected date range. In the view each person has their own row which shows the relevant accruals for the requests and events that span across the selected dates. For example if there is a balance leave request, the view will show the person's balance, and if there is an annual leave request for 2021 holiday year, the view will show person's annual leave balance from holiday year of 2021. Negative accrual balances are marked with red color. The highlights assist in quickly evaluating requests, but it is important to note that team dynamics, like coverage and required competencies, are not known by Nepton, and therefore cannot be highlighted.
By default the view opens with a list of all of the persons subordinates to be selected in the approval view for approving their event requests. The dates can be left blank to load all unapproved events for selected users. Users who have event requests that need approval are selected by default.
By default dates can be left blank. Event requests for selected users can be viewed with the View event requests to approve - button.
The Approve event requests - view can be filtered by dates and users. Date period can be set by setting the end and start date in the date fields in the upper left corner and clicking the refresh icon beside the date bar. Usually it is not necessary to set date periods as leaving them blank loads all unapproved event requests for the selected users. Person selection form can also be opened by clicking the Filter-button in the approval view.
Week view/Day view-button can be used to toggle the view from showing days to showing weeks.
Week view shows the date range as weeks.
Legend-button opens a legend describing the event type category coloring and other description about the view.
Legend shows how pending requests are indicated with dashed borders and selected requests are indicated with solid borders. Also color coding of exceptional entries, public holidays and event type categories is shown.
A date can be selected for reviewing the requests on that date by clicking the date cell.
Clicking a person's date cell will open a side panel which will show all events for the person in the date clicked. Displaying of additional info about the event like balance, possible request messages and exceptional entries can be toggled from the arrow next to the event type and date. The event can be edited by clicking the event type, which will open the event editing form with the clicked event.
Add-button under the person's name can be used to add an event for the person. Clicking the button will open the event editing form.
A date has been selected in the side panel with it's info expanded. Negative accrual balances are indicated with red color. A new event for the person can be added by clicking the Add-link. Event can be edited by clicking the event type link ("Balance leave - request" in the example image). Reply-link will also open the event editing form for adding a message for the request.
An important step in the review process is communication, and potentially negotiation, between the acting supervisor and subordinate. It is possible for each party to send messages about the request from within Nepton, forming a conversation. New messages can be saved without approving or rejecting events, and receiving parties are informed of each new message. An individual message about the event can be made by clicking the Reply-link beside the Messages-header. This will open the event editing form where a message can be added.
The event editing form with Messaging controls and a conversation about a request highlighted.
If the event is a pending request, it can be checked from the side panel so that it can be approved or rejected. Multiple requests can be selected so that for example all the requests that are ready to be approved, can be approved in one go.
Request is selected by ticking the checkbox in the side panel. Amount of selected requests is shown in the Event requests selected x/x - text.
Clicking the checkbox in the left side of the person's name will select all requests for that person. Clicking the person name will show all the events of the person in the selected date range in the side panel.
All of the persons events in the selected date range are shown in the side panel after the name of that person has been clicked.
An empty date can be selected if it is needed to add an event for that date for the person whose date cell was clicked.
A date is selected where the user has no events.
After requests have been selected, the action buttons below the person list become active. Requests can be approved, rejected or a message can be sent about them. The action performed will be done for all of the selected pending requests. When approving event requests, only the requests that are good for approval must be selected and then they can be approved by clicking the Approve - button. The same logic goes for rejecting requests, first all requests to be rejected are selected, and then the Reject - button is clicked to reject the events.
If a message to requesters is set, it will be included in the email sent to the requesters of the selected events whilst informing about request approval or rejection. The message field is optional.
Send message only - button will send an email message for the requesters of the selected requests but does not perform approval or rejection for the request. This is useful if it is needed to make a mass message on for example pending requests that overlap each other.
The action buttons become active if pending requests are selected to be handled.
Approving a request will mark the event as approved by the acting supervisor. Approved requests behave in the same way as any other approved event in service. However, by editing the event in question, approval can be temporarily rescinded or the request even entirely rejected. In this situation, the subordinate will be informed, respectively, that their request is being reconsidered, or is rejected.
Rejecting a request will remove the event from all views and notify the subordinate. For convenience, the subordinate is provided with an email link to recover a rejected request, so they can quickly request again with similar information. E.g. same projects, supplements, attachments, etc, but on different dates. This also has the benefit of preserving request edit and message history. Rejecting a request means that accruals need to be calculated again after removing the requested event, so it is slower than approving events.
The event editing form being used by a subordinate to recover a rejected request.
Approving and rejecting requests in the Approve event requests - list view
List view can be selected by clicking the list view - link that is after the Event requests selected: x/x - text. This view lists the event requests as a list. The action buttons work in the same way as in the table view.
Click the table view - link to get back to the table view.
Approving and rejecting requests in individuals calendar
Approval can also be done one request at a time in an individuals' Worktime calendar or by clicking the event's event type in the Activity request approving view's side panel.
The event editing form with the request approval controls highlighted.
Accrual usage & predictions
An essential part of the event requests feature is that employees and their supervisors have the necessary information to make good requests, and informed decisions for approval. However, when using the predicted accrual values, it is important to note their behaviour and limitations, each of which is detailed below.
"Running balance" style accruals (e.g. Balance)
Predictions for the remaining balance of a running accrual use the last complete day as a base and then assume the in-progress day, and any future days, will finish with +/- 0 balance change. The current day's markings are not considered because Nepton has no way of knowing if further edits will be made before the day ends.
When annual leave is requested the accrual balance will be shown based on the related earning period, minus all requests.
Requests that relate to future or incomplete earning periods assume the current workday and all future workdays with an obligation, will be worked fully using the person's default event type ('Work' by default). This allows a prediction of future balances and more meaningful decisions to be made.
In cases where a request falls on more than one spending period, the balance calculations will be based on only the earning period related to the requests' start date.
Annual leave accrual can have decimals but only meaningful decimals are shown for the accrual, e.g. 10 days, 6,5 days etc.
The event requests feature is designed to be flexible, so that any kind of request/approval workflow could be configured. Below are common use-cases and suggested best practices. More will be added as we get feedback and ideas from customers.
Planned holidays & absences
Please read this article in full for specifics about the event requests workflow and it's setup. This heading only summarises the suggested approach for handling planned holidays and absences.
If your organisation allows employees to request absences, like annual leave and balance leave, the event requests feature can be used to simplify the process by recording all information about it in a single place, keeping people informed, and helping people to make well-informed requests and approval decisions.
Start by flagging your planned holiday event types as "Requested from supervisor in advance". Then ensure the supervisors and their subordinates have the necessary permissions in their Worktime roles, to create and edit them. Finally, make sure everyone has a valid email address saved in Nepton.
That's it! Now subordinates can create new requests, which will inform their primary supervisor and/or acting deputies to review and approve them. All parties can send messages about the request directly from within Nepton, and each is informed of any edits and/or decisions that are relevant to them, via email.
When a holiday request is being created or edited, information about the relevant accrual usage is shown e.g. annual leave and balance leave (aka Saldo). The balances are highlighted in red if there are any problems. This helps subordinates make sensible requests, and supervisors to make good approval decisions. However, it should be noted that team dynamics, like coverage and required competencies, are not known by Nepton, and therefore cannot be highlighted.
Near-future versions of this feature will add the ability to opt for "in-site" notifications about requests, removing the need for emails from this workflow entirely.