Two agents can need different information from the same register. One is checking tomorrow's outstanding supplier replies, while another is preparing a later group's transfer list. An ordinary shared filter can interrupt their work when one person changes the visible rows. A well-defined filter view lets each agent inspect the relevant subset without repeatedly changing another person's view.
The operational risk is that a convenient view can start to feel like the whole register. A booking excluded by an old criterion may appear to have disappeared. A colleague may mistake a personal selection for a final departure list. Use filter views as a way to navigate the records, with a clear distinction between visibility, editing and the real status of each booking.
Choose a task that needs a view
Start with a recurring question that the existing columns can answer. Examples include supplier responses still outstanding for a defined departure period, bookings assigned to one agent or a particular product requiring document checks. State the inclusion rule in ordinary language before selecting values in the spreadsheet.
Avoid naming a view urgent work unless urgency is actually represented by a reliable field and definition. A label that sounds important can conceal arbitrary criteria. A more useful name describes the subset, such as Supplier replies outstanding, with its date condition explained where staff can find it.
Check whether the register contains the information required for the task. If the owner field is incomplete or several labels mean the same reservation state, a filter cannot repair the classification. Resolve that data issue or document the limitation before relying on the resulting list. A precise-looking view can still be based on inconsistent records.
Keep the task separate from the final operational decision. A view of confirmed bookings may help prepare a departure list, but the list still needs the agency's normal checks for current amendments, cancellations and supplier reconciliation. Do not treat the visible rows as an automatically approved manifest merely because the view has a familiar name.
Distinguish a shared filter from a filter view
Google's current collaboration guidance distinguishes ordinary filters from filter views that do not affect someone else's view. The Workspace Learning Center also explains that collaborators can use different views and save named selections. Choose the mode that matches the task rather than assuming every funnel-shaped control behaves identically.
For individual analysis of a shared register, a filter view is generally the relevant starting point. If the team intentionally needs a common filtered display, an ordinary filter can serve another purpose. Explain that choice to staff so someone does not inadvertently alter the shared working view while trying to find their own reservations.
A filter view is still connected to the underlying data. It is not a private copy in which an editor can experiment with real booking facts without affecting colleagues. Changing a reservation field is a data edit. Changing which rows the view displays is a visibility choice. Keep that distinction explicit during training.
Nor is a filter view an access-control boundary. A supplier who should receive only a limited guest list should receive an appropriately prepared, authorised handover through the approved channel. Do not give them access to the full register and assume that a filtered link protects the rows currently out of sight.
Create a named view from the intended range
Google's current desktop collaboration instructions describe selecting a cell with data, choosing Data and Create filter view, setting the filter options, then saving and naming the view. Existing views can be reopened through Data and Change view. Check the current interface in the actual workbook, particularly when it uses a table rather than an ordinary range.
Inspect the range and headers before applying criteria. The booking identifier, departure date, product, state and action owner need to remain associated within the same records. A view that covers only an old portion of the register can exclude later entries even if its filters are otherwise correct.
Use a test copy or a controlled initial setup where appropriate. Include known example rows inside and outside the intended criteria. The test should establish that the view includes the right bookings and excludes the right bookings for understandable reasons. Record the criteria and range so the next agent can inspect them without guessing.
Choose a stable name that describes the purpose rather than the person who first created it. A view named after a former employee gives the next colleague little context. If several staff use it, make clear whether they may change the saved criteria or should create their own separate view for another task.
Check what a visible subset means
Before acting, compare the view's criteria with the question you need to answer today. A view prepared for an earlier departure date may still open successfully and display plausible rows. Successful opening is not evidence that the selection remains current. Check any date, product, agent and status conditions that affect inclusion.
A useful review distinguishes four different situations:
| What staff observe | What it might mean | Appropriate next check | | --- | --- | --- | | Booking is visible | It matches the current view criteria | Verify its current evidence before acting | | Booking is absent | A criterion or range may exclude it | Find it in the full register by identifier | | No rows are visible | No included records match, or criteria are unsuitable | Inspect criteria and range before concluding no work exists | | Row order has changed | A sort has changed presentation | Identify records by booking reference, not old row position |
The table provides diagnostic possibilities, not a conclusion about every missing row. A record can also have been deleted, moved or entered in a different system. Begin with the least disruptive check: leave the personal view, inspect the full register and search using the stable booking identifier.
Do not add a duplicate reservation simply because it is absent from the current view. The duplicate can later cause two supplier requests or two client messages. Establish whether the original record exists and resolve its classification or range issue first. A visibility problem should not become a booking-integrity problem.
Preserve the complete booking row
Treat the booking identifier as the anchor when working in any sorted or filtered display. A row number is a position in the current presentation, not a reliable reference for a reservation. Use the approved reference when handing a question to another agent or checking supplier evidence.
Be careful with actions involving multiple cells, pasted blocks or a selected column. The team should understand whether the operation affects visible rows, underlying rows or the entire selected range in its particular workflow. Test a proposed bulk operation in an appropriate copy before applying it to live booking records.
Do not sort an isolated column of a booking register if doing so would separate a date, name or status from the rest of its record. Work with the intended complete data structure and verify a few known identifiers afterwards. This is a record-integrity requirement independent of whether the display uses a shared filter or a personal view.
For routine updates, change the specific identified booking and inspect the result. A state change may legitimately make a row disappear from a view of outstanding work. Confirm that the row remains in the register with the new state rather than assuming that its disappearance means the edit failed.
Coordinate views used by several agents
Google's documentation allows saved views to be reopened and shared through links. When a team distributes such a link, include the purpose and any important limitation. The recipient needs to know whether it is a live working selection, a temporary analysis or a view that still requires a current date check.
Avoid changing a widely used saved view's meaning without notice. If an agent needs another selection, a separate clearly named view can preserve the established workflow. Periodically remove obsolete duplicates through the authorised owner so staff do not choose between several nearly identical labels with unknown differences.
A colleague with view-only access may be able to create a temporary filter view rather than save a persistent one, as Google's help explains. Confirm the actual permission and device context before promising a particular handover method. The ability to inspect a subset does not give the recipient authority to edit the underlying booking.
Keep a short note of important team views: name, purpose, criteria owner and the task they support. This is especially useful when staff cover another agent's shift. It turns the view from a personal convenience into an understandable aid without making it a separate source of reservation truth.
Work through a two-agent example
Imagine one agent reviewing next week's supplier replies while another checks outstanding transfers for a later group. This is a hypothetical shared-register example. Each uses a separate filter view with a stated purpose and an appropriate date condition. Neither needs to reset the other's visible selection repeatedly.
The first agent receives a supplier confirmation and updates the identified row using the approved evidence. That row no longer matches the outstanding-replies view, so it disappears from that display. The agent verifies the record in the full register if needed and records the next action through the normal workflow. They do not recreate the row or leave an obsolete pending label just to keep it visible.
The second agent sees a booking missing from the transfer view. They leave the view and search the full register by reference. The record exists, but its action-owner field was not updated during a handover. The responsible colleague corrects the underlying record after checking the facts, then the view includes it for the right reason.
Both cases show why a view needs reliable data and a stable identifier. It helps staff find work, but it does not decide the booking state or complete the handover. Keep the supplier response and ownership decisions in the appropriate records so another colleague can understand the result.
Check totals and handovers outside the narrow view
Before issuing a final count, define exactly what is being counted. Reservations, travellers and seats can be different units. A visible-row count is not necessarily the number of guests on a departure, particularly when one booking can contain several people or more than one service.
Use the business's established counting and reconciliation method. Compare the relevant approved records and check whether the current filters exclude cancelled, unconfirmed or recently amended entries appropriately. If a report is intended to cover the whole register, confirm that it does not inherit an accidental personal selection.
For an external supplier handover, prepare the authorised output with the required current fields and verify its recipients and content. A link to a live internal register is not automatically a suitable substitute for a controlled list. Keep the output's date and scope clear so later changes can be communicated through the agreed process.
After a material template or import change, test that the important views still cover new records and retain their intended criteria. A routine factual update to one booking does not require rebuilding every view. Preserve a few representative checks so the next maintenance task remains finite.
The completed workflow lets agents inspect different subsets while maintaining one coherent register. Staff know how to find the full record, distinguish presentation from edits and verify counts before acting. Filter views then save time without turning hidden rows into hidden operational problems.
