Flight time, flight number, transfer status, and hotel information for an international patient form one operational record. When these details are scattered across conversations, your team cannot easily see a missing piece. Receiving a document does not mean its data has entered the record. Losing travel details in attachments or notes makes the final check dependent on personal memory and fragmented messages.
In Zoho, the structure that separates incomplete travel information is a custom view applying criteria to record fields. The view lists matching records but produces no notification, task, or reminder. The solution therefore separates two decisions: storing filterable data in suitable fields and deciding when operations reviews the list. Any additional alert mechanism requires separate verification; an undocumented trigger is not assumed.
A patient waiting at the airport
The flight time is in one conversation, the hotel name in another, and nobody has recorded who will provide the transfer. When the patient lands, someone calls, and the only place to look is one person’s phone. Although fragments arrived, they never became a shared operational record. The final check consequently depends on a particular employee’s access, memory, and availability instead of information visible to the team.
On the operations morning, someone asks which hotel the patient should be collected from. The record opens with an empty hotel field because nobody completed it when the information arrived, and no list exposes the gap. The omission appears when a transport decision is due, not during preparation. This situation shows the difference between possessing a conversation and creating usable operational data, as well as the practical consequence of unclear ownership.
Where travel information belongs
Zoho custom fields follow a closed list of field types. Flight time uses Date and Time, flight number uses Text, and transfer or accommodation status uses a Pick List; a type name outside the list cannot be used. Keeping details needed before operations in direct record fields gives the team a consistent data foundation for separating records with missing numbers, times, or unresolved statuses.
A subform can carry repeated travel rows, but Enterprise permits two per module and Ultimate five; lower editions have none. A layout cannot exceed 25 total subform fields, and all its subforms together cannot exceed 200 rows. Subform fields cannot be used in custom-view columns, validation rules, or workflow criteria. If their totals are needed in those places, an aggregate field must first be added to the subform.
Put incomplete records on a list
A Zoho custom view fills with records matching its criteria. Text fields such as flight number support “is empty” and “is not empty.” Date and Date Time fields additionally support “between,” “Today,” “Tomorrow,” and “Due in Days.” The view can therefore filter an empty flight number or records in a defined date range. A travel field inside a subform, however, cannot be displayed as a view column.
This list is a control surface, not an alert engine. A record appearing because it matches the criteria does not send a notification, open a task, or create a reminder. Building the list and assigning operational responsibility are separate decisions. Your team names the reviewing role, selects a suitable review rhythm, and assigns completion of each missing field. Even correct criteria cannot ensure timely discovery when nobody examines the view.
Place requirements in the right layer
A Zoho validation rule runs during manual record creation and editing. Field changes take precedence during imports, workflow field updates, approval processes, Blueprint, and API updates. The rule cannot be configured for multi-select pick lists, formulas, auto numbers, image uploads, multi-line text, multi-select lookups, or multi-user fields. These boundaries require the field type and the record’s input route to be evaluated within the same design decision.
Conditional required status is the Set Mandatory Fields action of a layout rule. Layout rules do not run for imports, web forms, or the lead conversion page; API operations support only the Set Mandatory Field action. Each layout permits up to ten layout rules, and a rule is evaluated during drag and drop in Kanban view. Depending on one control layer without mapping how flight data arrives leaves coverage gaps hidden.
Tickets and reservation documents
A ticket or reservation document can use a File Upload or Image Upload field. File Upload and Image Upload each carry their own per module limit: two in Standard, five in Professional, ten in Enterprise, and fifteen in Ultimate. Each file has a 20 MB maximum. A File Upload field inside a subform allows up to five files per field. Document demand, available field capacity, and file size should be planned together.
Having the document in the record does not replace filterable data such as flight number or accommodation status. A subform file field also does not alter the restriction preventing subform content from becoming a custom-view column. Separating the document from operational data in direct record fields keeps the control basis clear. The team can see gaps without opening the ticket, while responsibility for transferring document details into fields remains explicitly assigned.
Ownership before the operations day
The documented fields for a Zoho date-based workflow trigger are limited to Created Time, Modified Time, Last Activity Time, and Unsubscribed Time; execution timing is defined by day, week, or month. Support for connecting this method to a custom operation date is unverified. In Appointments, workflow actions are limited to webhooks, email notifications, functions, field updates, and tags; no task action exists. An alert flow beyond these boundaries is not assumed.
A scheduled report is another documented control route. It can be sent daily, weekly, monthly, or yearly and carry up to 2,000 records as an XLS attachment. Channels are email, Cliq, and Cisco Webex, while scheduling the report requires Schedule report profile permission. This supports periodic review but cannot be described as an immediate or operation-date-specific alert. The process identifies who reviews the report and who completes the gaps found there.
Edition threshold boundaries
Because custom fields are unavailable in Free, this design requires at least Standard. Per-module custom-field limits are 10 in Standard, 155 in Professional, 300 in Enterprise, and 500 in Ultimate. A field moved from the layout to Unused Fields continues consuming capacity. When capacity is tight, prioritizing filterable core fields such as flight time, flight number, transfer status, and accommodation status prevents unused details from filling the allowance.
Subforms provide two per module in Enterprise and five in Ultimate, with none in lower editions. File and image upload field limits for Standard, Professional, Enterprise, and Ultimate are respectively 2, 5, 10, and 15, with 20 MB per file. Appointments is available in Professional, Enterprise, and Ultimate. Function-based validation is limited to three rules per module in Enterprise and five in Ultimate. Without subforms, filterable core details remain direct fields.
Pre-launch checks for the travel record
Before configuration, distinguish required travel details from optional ones. Decide whether each field is completed when information arrives, when the reservation is confirmed, or during manual record editing. Name the person moving data from conversations into fields and the role reviewing the incomplete-information view. Address imports, API operations, and web forms not covered by validation or layout rules separately. A custom view criteria set accepts up to 25 rows and evaluates each record on its own; it cannot compare one record with another.
Before designing a reminder around an operation date, verify the trigger fields and timing options shown in Setup. Record in the control plan that a Zoho custom view only lists records and produces no action itself. If validation or other coverage is needed on an appointment record, do not assume undocumented support. Keep product boundaries separate from institutional experience. A dependable travel record combines suitable field types, supported edition thresholds, known input boundaries, and named human ownership in one configuration decision.
