Travel & Trips
Employee travel requests, approvals and trip records.
Travel & Trips gives business travel a proper home instead of a thread of emails and a spreadsheet nobody trusts. Anyone raising travel — an employee's line of business trip, a site visit, a conference — records it as a travel request that moves through a deliberately lightweight workflow: pending, then approved or rejected, then completed once the trip has happened. The request itself becomes the trip record, so the question of who went where, when and at what cost always has one answer.
Each request captures the essentials without ceremony: the travelling employee, the destination, a free-text purpose, the from and to dates, and an estimated cost. Nothing beyond the destination is compulsory, so a quick placeholder request is as valid as a fully specified one — you can raise the trip first and fill in dates and cost as they firm up. Costs are stored as proper amounts and displayed with thousands separators, so the list reads like a ledger rather than a text file.
Alongside requests sits a travel expense log. Expenses are recorded against a description, a category — airfare, hotel, meals, local transport or other — an amount, a date and the employee who spent the money, and each one carries its own status from pending through approved to reimbursed or rejected. The two registers together give you both halves of the story: what a trip was expected to cost, and what was actually spent.
The module is aimed at the people the workflow serves. Employees or HR staff submit travel requests; whoever holds the approval seat clears them; and administrators record the organisation's policy preferences in the module's settings — whether approval is required, whether travel advances are allowed, whether per-diem applies — alongside the expense categories the organisation recognises. Access to the whole area is governed by the same role-template permission matrix that controls every other module in Nexa People.
How Travel & Trips works
Raising a travel request
From the Travel Requests screen, New travel request opens a single dialog: pick the employee from the organisation's directory, name the destination, describe the purpose, set the from and to dates side by side, and enter an estimated cost. Only the destination is required — the employee, purpose, dates and cost can all be left blank or zero and added later, which keeps the barrier to recording travel as low as possible.
Submitted requests land in the list immediately with a pending status. The table shows destination, the employee's resolved name, both dates, the formatted cost, a status badge and the actions available right now — so the state of every trip in the organisation is readable at a glance without opening anything.
An approval lifecycle the server enforces
A pending request offers exactly two actions: Approve and Reject. An approved request offers one: Complete, for marking the trip done once travel has actually taken place. Rejected and completed requests are final and show no further actions — the interface only ever offers moves that are legal from the current state.
The same rules are enforced on the server, not just in the browser. Each transition checks the request's current status first and refuses anything out of order — only pending requests can be approved or rejected, and only approved requests can be completed — returning a clear conflict error rather than silently overwriting state. However a request reaches the API, the lifecycle holds.
The employee hears about every decision
Every transition announces itself. When a request is approved, rejected or completed, the login account linked to the employee's email receives an in-app notification naming the trip and the decision — 'Travel request “Lahore site visit” approved' — filed under the travel category in their notification feed.
Where your organisation has outgoing email configured, the same decision is also emailed to the employee's address on record, on a best-effort basis that never blocks or breaks the approval itself. Requests raised without a linked employee simply skip the announcement.
Logging what the trip actually cost
The Expenses tab is a running log of travel spending. New expense records a description, the employee, a category chosen from airfare, hotel, meals, local transport or other, the amount, the date and a status — pending, approved, reimbursed or rejected. Amounts are formatted as money in the list, employees appear by name, and statuses are colour-coded badges, with reimbursed rendered as a positive outcome.
Expenses stay editable after the fact: every row carries Edit and Delete actions, with the edit dialog pre-filled from the current record and deletion guarded by a confirmation. That makes the log practical for the common reality of receipts arriving late and amounts being corrected once statements come in.
Settings that describe your travel policy
The Settings tab holds the module's configuration in two parts. General Setting records the organisation's stance on requests as simple yes/no switches — whether approval is required, whether travel advances are allowed, and whether per-diem applies — saved together against your organisation's configuration with one click.
Expense Categories is a maintainable list: add the categories your organisation recognises, such as Airfare or Hotel, see them numbered in a table, and remove any that no longer apply. Both settings areas persist to the same organisation-level configuration store used across Nexa People, so they survive sessions and apply organisation-wide.
Access controlled like everything else
Employee Travelling appears in the navigation and accepts visitors only for roles granted the module in the Role Templates permission matrix. The matrix carries dedicated entries for the travelling request, travel approvals, travel settings and travel reason type forms, and unchecking the module as a whole removes both the menu item and the route — navigating to the URL directly is held to the same rules as the visible navigation.
Self-service employee accounts are confined to their own surface by default and reach the travelling module only when the matrix explicitly grants them its forms, so who can raise, approve and configure travel is entirely your organisation's decision.
Features
One record per trip
Employee, destination, purpose, from and to dates, estimated cost and current status — a travel request is a compact, complete trip record. Only the destination is compulsory, so recording travel takes seconds and detail can follow as plans firm up.
Approve, reject, complete
Requests move pending → approved → completed, with rejection available while pending. Actions appear only where they are legal, and the server independently refuses out-of-order transitions with a clear conflict message, so the lifecycle cannot be short-circuited.
A list that reads at a glance
The requests table shows destination, employee name, dates, cost with thousands separators and a colour-coded status badge on every row. Pending rows carry Approve and Reject buttons inline; approved rows carry Complete — no drilling into records to act on them.
Travel expense log
Record each expense with a description, employee, category, amount, date and status. Statuses run pending, approved, reimbursed and rejected, so the log doubles as a reimbursement tracker, and every entry can be edited or deleted as the paperwork catches up.
Built-in expense categories, plus your own
Expense entry offers airfare, hotel, meals, local transport and other out of the box, and the settings area maintains a named category list of the organisation's choosing — add what your policy recognises, remove what it does not.
Notifications and email on every decision
Approval, rejection and completion each raise an in-app notification to the affected employee, naming the trip and the outcome. With outgoing email configured, the employee is emailed too — best-effort, so a mail hiccup never blocks the decision itself.
Policy switches for advances and per-diem
General settings record whether approval is required, whether travel advances are allowed and whether per-diem applies — three yes/no switches saved to organisation-wide configuration, giving the module a written statement of your travel policy.
Permission-gated end to end
The module and its forms — travelling request, travel approvals, travel settings, travel reason type — are individual entries in the Role Templates matrix. Remove the module from a role and both its navigation entry and its route disappear for those users.
History that survives staff changes
Requests are keyed to the employee record but do not depend on it: if an employee's record is later removed, their past trips remain on file with the trip details intact, so the organisation's travel history is never silently thinned.
Used by: Employees or HR staff submit travel requests.
Works with the rest of Nexa People
Travel & Trips reads its people from Employee Management. The employee picker on both the request form and the expense form is the same organisation directory used everywhere else, and lists resolve identifiers to real names from that directory — so a trip always belongs to the same employee record that attendance, leave and payroll describe. Every request and expense is stored against your organisation alone, resolved from the signed-in session on every call.
Decisions flow into the shared notification system. Travel keeps its workflow deliberately simple — a pending → approved/rejected → completed lifecycle, consistent with expense claims and piece-work rather than the multi-level chains of leave and attendance — and every approval, rejection and completion surfaces in the employee's in-app notification feed under a travel category, riding the platform's email service to the employee's inbox where email sending is configured.
Configuration and access both live in shared infrastructure: travel settings and expense categories persist to the organisation-wide settings store alongside every other module's configuration, and the Role Templates matrix maintained in Employee Management decides who sees the travelling module at all — the same matrix, the same enforcement, one place to manage access.
Frequently asked questions
What does a travel request record?
The travelling employee, the destination, a free-text purpose, from and to dates, an estimated cost and the request's current status. Only the destination is required — everything else can be left blank at submission and filled in later, and the cost defaults to zero until you set it.
How does the approval workflow operate?
Every request starts as pending. From there it can be approved or rejected; an approved request can later be marked completed once the trip has taken place. The interface only offers actions valid for the current state, and the server independently rejects any out-of-order transition, so a request can never jump or repeat a step.
Is the employee told when a decision is made?
Yes. Each approval, rejection or completion raises an in-app notification to the employee linked to the request, naming the trip and the decision. If your organisation has configured outgoing email, the same message is also emailed to the employee's address on record — sent best-effort, so email problems never block the decision.
How are travel expenses handled?
The Expenses tab keeps a log of spending against travel. Each entry records a description, the employee, a category — airfare, hotel, meals, local transport or other — an amount, a date and a status running from pending through approved to reimbursed or rejected. Entries can be edited or deleted afterwards, so late receipts and corrections are easy to absorb.
Can we define our own expense categories?
Yes. The settings area includes an Expense Categories list where you add and remove named categories for your organisation. The list is saved to organisation-wide configuration, alongside the general travel switches for approval, advances and per-diem.
Does a request have to be tied to an employee?
No. The employee field can be left blank — useful for provisional trips where the traveller is not yet decided. A request without a linked employee simply skips the notification step; one with an employee keeps its trip history on file even if that employee record is later removed.
Who can access the travelling module?
Whoever your Role Templates matrix says. The module carries its own permission entries — travelling request, travel approvals, travel settings and travel reason type — and removing the module from a role hides its navigation entry and blocks the route itself, so direct links are held to the same rules. Self-service employees see it only if explicitly granted.
Related modules
See Travel & Trips in your own setup
We'll walk you through the modules you care about and email you login credentials to try it yourself.