Trip types
Business trips, workations and assignments — and why the type you choose is load-bearing.
Every trip has a type, fixed when the trip is created. It is the single biggest determinant of how premote handles the trip.
| Type | What it is |
|---|---|
BUSINESS_TRIP | A work trip to another country — client visits, conferences, site work |
WORKATION | Remote work from another country, at the employee's own initiative |
ASSIGNMENT | A long-term posting abroad, managed as a multi-phase HR process |
Why the type matters
Type is not a label. It selects, at creation time:
- Which policy applies. Policies are defined per trip type. If no policy matches the type, destination and dates, creation fails with
404— nothing is created. - Which fields are required.
GET /trip-fields?tripType=BUSINESS_TRIP— API Reference — returns the fields for a given type. Sending values for fields that don't apply is pointless; omitting required ones fails completeness. - Which approval rules run. Approval chains are configured per trip type, so the same traveler and destination can need one approver as a business trip and three as a workation.
- Whether a risk assessment runs. Risk assessment is switched on or off separately for business trips and workations.
- Which compliance obligations are evaluated. A1 coverage, posted-worker notification duties and the rest are assessed differently for a client visit than for self-directed remote work.
Type is immutable in practiceThere is no "change the type" operation. If a trip was created with the wrong type, cancel it and create a new one — otherwise it keeps the policy, fields and approval chain of the wrong type.
Check a set of draft values against a type before committing to it with POST /trips/completeness/USERID — API Reference.
Assignments work differently
ASSIGNMENT trips are the exception to everything on the Trip statuses page.
An assignment'sstatusstaysPENDINGfor its whole lifeDo not read
trip.statusto track an assignment — it will not move. The real lifecycle lives inassignmentPhase.
Fetch an assignment with GET /assignments/{tripId} — API Reference.
Phases
assignmentPhase runs through:
| Phase | Meaning |
|---|---|
DRAFT | Being set up, not yet submitted |
EXPLORATION | Feasibility being assessed — cost, tax, immigration |
PENDING_CONFIRMATION | Awaiting the go/no-go decision |
PRE_DEPARTURE | Confirmed; visas, permits and paperwork in progress |
ON_ASSIGNMENT | The employee is in the host country |
START_REPATRIATION | Return process started |
OFFBOARDING | Being offboarded from the host country |
POST_ASSIGNMENT | Home and closed out |
Submitting a draft (POST /assignments/{tripId}/submit — API Reference) moves it to EXPLORATION. A phase can also be set directly with PUT /assignments/{tripId}/phase — API Reference.
Separately, AssignmentStatus is a coarse rollup with just two values: IN_PROGRESS and COMPLETED.
Steps
Each phase contains steps from your company's assignment workflow — GET /assignments/trip/{tripId}/steps — API Reference. Each step carries its own status:
| Step status | Meaning |
|---|---|
PENDING | Not started |
IN_PROGRESS | Being worked on |
COMPLETED | Done |
SKIPPED | Deliberately not applicable to this assignment |
REJECTED | Rejected — needs attention before the phase can advance |
Advance one with PUT /assignments/step/{instanceId}/status — API Reference — or route it to an owner with PUT /assignments/step/{instanceId}/assign — API Reference.
Recap
| Task | Endpoint |
|---|---|
| Fields for a trip type | GET /trip-fields?tripType=… |
| Validate values against a type | POST /trips/completeness/USERID |
| Read an assignment | GET /assignments/{tripId} |
| Read its steps | GET /assignments/trip/{tripId}/steps |
| Submit an assignment draft | POST /assignments/{tripId}/submit |
| Set the phase | PUT /assignments/{tripId}/phase |
| Update a step | PUT /assignments/step/{instanceId}/status |
Updated 19 days ago