Trace what happened to a booking

Every create, edit, check-in and cancellation a booking has ever had, on one screen. Ask the caller for the booking reference, paste it in, read the trail, and download it as a spreadsheet. About five minutes.

Updated 18 Aug 2026

Somebody’s meeting moved and nobody admits to moving it. The booking log is where that gets settled: every create, edit, check-in, extension and cancellation a booking has ever had, each one stamped with who did it and which part of Offision they did it from.

A tall blue panel on the left holds a booking called Design review and its reference, BK0042. From it a line labelled every action fans out into five rows, newest at the top: Booking end, by nobody, from Backend auto; Check out, by Marco Lai, from Device; Check in, by Marco Lai, from Device; Edit, by Ivy Chan, from Management console; Create, by Marco Lai, from User Portal. Each row is coloured by the interface it came from, and the two Device rows share a colour.

One booking reference gathers every action, wherever it came from — a person in the app, an administrator in the console, a room panel, or Offision itself.

1. Open the booking log

In the Booking module the log sits in the list down the left — but it is not one of the pinned entries, so choose Show more before Booking log appears.

Open Booking log

It opens on the whole estate, newest action first, with no date filter applied. That first view is everything Offision has ever recorded about every booking, so it is not somewhere to browse — it is somewhere to look one thing up.

The log at rest: one row per thing that happened, newest at the top.

The log at rest: one row per thing that happened, newest at the top.

2. Ask for the booking reference

Every booking carries a reference: BK followed by its number, padded to four digits — BK0042. It is fixed for the life of the booking, and past 9999 it simply runs longer. Nothing ever renumbers.

The reference matters because the person who booked can see it too. It is a row near the bottom of their booking’s details in the Offision app, under Booking ID. So the first question to ask a caller is not “which meeting?” — it is “what does the booking ID say?”. That one string replaces a conversation about which Tuesday and which big room, and it is the only handle that still works after the booking has been deleted.

It is the organiser’s copy that carries it. Open a colleague’s booking and the app shows a short card with the room and the organiser and no reference, so ask the person who made the booking, not whoever forwarded you the invitation.

3. Find the booking

The search box at the top right is labelled Search ID, title or code, which undersells it. Three different things go in, and it works out which you meant:

What you typeWhat it finds
BK0042, bk 42 or just 42The booking with that reference
42Also a booking whose check-in PIN is 42
Anything elseBookings whose title contains it

Type at least two characters and the matches appear beneath. A repeating booking is listed as the series, with its individual dates indented under it. Choose one and it becomes a chip in the search box: the table below is now that booking’s trail and nothing else. Clear the chip to go back to the estate.

Pasting in a reference. The matching booking appears — choose it to scope the log to it.

Pasting in a reference. The matching booking appears — choose it to scope the log to it.

Two things save typing:

  • Clicking any reference in the table scopes the log to that booking, so you can follow a row you noticed into its full history without going back to the search box.
  • A deleted booking still has a trail. Search its reference and it appears marked Booking no longer exists; choose it anyway and the log shows everything up to and including the deletion. This is usually the booking being asked about.

4. Read the trail

One row is one thing that happened. Rows are newest first, always — no column sorts, and that is deliberate for a log. Narrowing is done with the filters, and every column header carries its own: a date range on Action time, tick-lists on Type, Status and Interface, and people, resource and device pickers on the rest.

Four columns carry most answers:

  • Action time, to the second — enough to put two near-simultaneous changes in order.
  • Type — what was done. Create, Edit, Delete, Check in, Check out, Extend, Approved / Rejected.
  • Status — how it ended. Success carries a green dot and Error a red one; Rejected and Running carry a neutral one. Rejected is the case worth reading: somebody tried and a rule said no. Which rule is in Description.
  • Interface — where the action came from, and the column that usually settles the argument.
InterfaceThe action came from
Management consoleAn administrator, in the admin console
User PortalThe person themselves, in the Offision app
DeviceA room panel
Visitor APPA visitor, on their own device
Outside AccessSomebody with no Offision account
External calendarA Microsoft 365 or Google Workspace sync
Third party APIAnother system, through the external API
WorkflowAn automation you built
Backend autoOffision itself

Backend auto is the one to know. A booking nobody touched still grows rows — Booking start, Booking end, Mark as no show, Rejected by system, Synchronize from external calendar. This is why a trail is nearly always longer than anyone’s memory of the booking, and why “I never touched it” and a five-row history can both be true.

Selecting a row opens the same fields as a panel on the right, which is quicker than widening columns when you only care about one row.

One row, read as a panel.

One row, read as a panel.

5. Show the columns an investigation needs

Six columns are hidden until you ask for them, under the Sorting / Columns pill. Two of them are the ones you actually came for.

The columns chooser. Drag to reorder, tick to show.

The columns chooser. Drag to reorder, tick to show.

ColumnWhat it adds
Booking before changeThe booking as it stood before this row changed it — the only way to see what an edit actually edited
Access fromThe city, country and IP address the action came from
DescriptionThe full sentence, and the rule that refused a rejected row
VisitorWho the visitor was, when a visitor did it
Request, IDThe raw instruction and the row’s own id — what support will ask for

Ticks and drag order are remembered against your account, so the layout follows you to another machine.

6. Download it

Download opens a period picker — This week, Last month, Last 30 days and so on, or a custom range on the two-month calendar. Its confirm button also reads Download. The file covers the dates you pick plus whatever filters are still set, including a booking chip, so scoping to one reference first gives you that booking’s history and nothing else.

To send just a few rows instead, select them and use Download in the bar that floats up from the bottom.

Choosing the period to download.

Choosing the period to download.

7. Check you have the right booking

Open the file and confirm two things. The Booking ID column should read the same reference the caller gave you, on every row. And the oldest row — the last one — should be a Create. If it is not, the period you chose starts after the booking was made: clear the date range and download it again.

What the booking log does not show

  • Sign-ins, passwords and user administration. Those are audit trails, kept in system settings, not here.
  • What happened to a room. The log records what happened to bookings — a room taken out of service is not a row in it.
  • Why an approval went the way it did. The decision appears as Approved / Rejected; the approver’s comment lives with the approval.
  • Anything you can change. The log is read-only, and nothing in it can be undone from this screen.