Closing the Loop: Why Lookup Asymmetry is Harming Data Integrity in Creator

Closing the Loop: Why Lookup Asymmetry is Harming Data Integrity in Creator

TL;DR: Lookup fields allow users to add new related records inline via the "+" icon, but there's no equivalent ability to edit an existing related record without navigating away and losing form context. Adding a native "Edit" icon—with automatic User Input workflow re-triggering on save—would close this asymmetry and prevent the data quality issues that arise when fixing related records is too disruptive to bother with.
I've discovered a significant gap in how Zoho Creator handles related records through lookup fields, and I'm hoping the Zoho team can address this in a future update. This limitation creates a disjointed user experience that breaks natural workflow patterns.

The Issue
According to Zoho Creator's lookup field functionality, users can add new related records directly through a lookup field—both single-select and multi-select variants support this via the "+" icon. This is an excellent feature that streamlines data entry.
However, there is no equivalent ability to edit an existing related record while adding or editing the parent record. Once a related record exists, users must navigate away from their current form to make changes—breaking their workflow and context.
Example Use Case
Consider a Sales Order form with a lookup field to Clients.
Scenario: While creating a new Sales Order, the user notices the selected Client's phone number is outdated.
Desired behavior:
  • Click an "edit" icon next to the lookup field
  • Update the Client's phone number in a popup/modal
  • Save and return to the Sales Order form with context preserved
  • Continue completing the Sales Order without interruption
Current reality: The user must abandon their partially-completed Sales Order, navigate to the Clients report, find and edit the Client record, then return to create a new Sales Order from scratch—or risk losing unsaved data.
The Problem
Zoho Creator provides asymmetric functionality for related records—you can create but not edit:
Action Single-Select Lookup Multi-Select Lookup
Select existing related record ✓ Yes ✓ Yes
Add new related record ✓ Yes (via + icon) ✓ Yes (via + icon)
Edit selected related record ✗ No ✗ No
View selected record details inline ✗ No ✗ No
The openUrl() Workaround — And Why It Falls Short
Technically, you can use Deluge's openUrl() function to open a related record for editing—either from the User Input of a field or from an anchor tag in an Add Notes field. According to the documentation on editing records via Record ID: 
// URL pattern to edit individual records by passing record ID:
// https://<base_url>/<account_owner_name>/<app_link_name>/#Form:<form_link_name>?recLinkID=<record_ID>&viewLinkName=<view_link_name>

// Example: Open related Client record for editing via User Input
client_id = input.Client_Lookup.ID;
edit_url = "#Form:Clients?recLinkID=" + client_id + "&viewLinkName=Clients_Report&zc_LoadIn=dialog";
openUrl(edit_url, "same window");
Critical Limitation: While openUrl() can open the related record for editing, the lookup field's User Input workflow does not re-trigger when the related record is saved. This means any field population logic that runs on record selection won't run again after an edit.
The result is a broken workflow:
  • Parent form → Can open child record for editing ✓
  • Child record → Can be edited and saved ✓
  • Parent form → User Input workflow does not re-trigger
  • Parent form → Lookup display shows stale data
  • Parent form → Dependent fields remain outdated
Workaround Approach Implementation Problems Status
openUrl() from User Input Trigger openUrl() on field change to open related record in dialog - User Input workflow doesn't re-trigger after edit
- Lookup field shows stale display data
- Dependent fields remain outdated 		⚠ Partial solution
Anchor tag in Add Notes Embed clickable link using <a href="..."> in Add Notes field - Same limitations as openUrl()
- Requires visible Add Notes field
- Less discoverable for users 		⚠ Partial solution
1-Row Subform Replace lookup with a subform limited to 1 entry for "inline" editing - Cannot search/select from existing records
- Designed for creating new child data, not picking existing
- Doesn't scale (can't browse 5,000+ records)
- Loses all lookup field benefits 		✗ Architectural mismatch
JavaScript Widget Build custom widget with iframe and postMessage API - Requires complete UI rebuild
- Complex development effort
- Maintenance overhead
- Not native Creator experience 		✗ Overkill for simple requirement
Navigate Away User leaves current form, edits related record, returns - Loses unsaved parent form data
- Destroys dynamic form state and transient variable calculations
- Breaks user workflow
- Poor user experience 		✗ Not viable
The Missing Pieces
For a complete solution, Zoho Creator would need to provide:
Capability Current State Required State
Native Edit Icon Not available on lookup fields Edit icon alongside + (add) icon
Parent Form Preservation No mechanism to preserve state Parent form remains open with unsaved data intact
User Input Re-trigger Does not fire after related record edit Existing User Input workflow re-triggers on related record save
Lookup Display Refresh Display shows stale data after edit Lookup field reflects updated related record data
What Should Happen Instead
Proposed Solution 1: Native Edit Icon on Lookup Fields
Add an edit icon (pencil) alongside the existing add icon (+) on lookup fields: 
[ Selected Client Name     ▼ ]  [+]  [✏️]
                                 │     │
                                 │     └── Edit selected record (NEW)
                                 └──────── Add new record (existing)
Clicking the edit icon would open the selected record in a dialog/modal, preserving the parent form's state.
Note for Multi-Select Lookups: The edit icon could appear next to each individual "pill" or selected item in the list, allowing users to edit any of the selected records independently.
Proposed Solution 2: Re-trigger Existing User Input Workflow
When a record is selected in a lookup field, it already triggers the field's User Input workflow. This same behavior should occur automatically when an edited related record is saved—no separate event type needed: 
// Existing User Input workflow on Client_Lookup field
// This ALREADY triggers when a record is selected
// It SHOULD also trigger when the related record is edited and saved

on user input of Client_Lookup
{
    // Populate fields based on selected client
    input.Contact_Phone = input.Client_Lookup.Phone;
    input.Contact_Email = input.Client_Lookup.Email;
    input.Billing_Address = input.Client_Lookup.Address;
}
Expected behavior: After editing the Client record via the lookup field's edit icon and saving, the User Input workflow should re-trigger automatically—without requiring the user to manually de-select and re-select the record. This seamless refresh is what makes the UX feel native. The workflow would update any dependent fields with the corrected data using existing logic, no new code required.
Proposed Solution 3: Lookup Field Property for Edit Behavior
Add a lookup field property to control edit behavior: 
Lookup Field Properties:
├── Allow Add New Record: ☑ Enabled
├── Allow Edit Selected Record: ☑ Enabled  ← NEW OPTION
│   └── Edit Opens In: ○ Dialog  ○ Slide-in Panel  ○ New Tab
└── On Related Record Save: ○ Refresh Lookup  ○ Custom Script  ○ No Action
Note: The Edit icon should naturally respect the user's Module Permissions. If a user does not have 'Edit' access to the related form, the icon should remain hidden or disabled—consistent with existing permission behavior for the Add (+) icon.
Real-World Impact
This limitation affects any workflow involving:
  • CRM/Sales workflows — Updating client contact info while creating quotes or orders
  • Project management — Editing task details while logging time entries
  • Inventory systems — Correcting product specifications while processing orders
  • HR applications — Updating employee details while processing leave requests
  • Support ticketing — Modifying customer information while handling tickets
  • Data integrity — When users spot typos or outdated info but can't fix it easily, they tend to ignore it. This leads to "dirty data" accumulating simply because the "cost" of fixing it (navigating away, losing context) is too high
  • Any parent-child data relationship — Where child record corrections are discovered during parent record creation

User Experience Impact: Users are forced to choose between completing their current task with stale/incorrect related data, or abandoning their work to fix the related record. This friction compounds across every data entry session, significantly impacting productivity.

The Asymmetry Problem:
The ability to add new related records directly from a lookup field is incredibly useful and demonstrates that Zoho Creator understands the value of contextual record management. The absence of an equivalent edit capability creates an inconsistent and frustrating user experience.
If users can add related records without leaving the form, they should be able to edit them too.
Setting the Standard:
Zoho Creator is marketed as the platform for building bespoke solutions—applications tailored to workflows that standard SaaS offerings cannot accommodate. Bespoke solutions shouldn't be constrained by out-of-the-box limitations like this.
Creator is the ideal place to pioneer this feature. Developers choose Creator precisely because we need workflows that are more fluid and contextual than pre-built software allows. Native inline editing for lookup fields would reinforce Creator's position as a developer-first platform.
Request to Zoho Team

Can this be addressed in a future update?

The current implementation forces users to choose between:

1. Workflow Continuity
Complete the current form with potentially outdated related data, then fix later (risking data quality issues) 		2. Data Accuracy
Abandon the current form, navigate to fix the related record, then start over (losing time and unsaved work)

We shouldn't have to make this choice—lookup fields should support both adding AND editing related records.

Community Input Requested: Has anyone else encountered this limitation or developed a more elegant workaround? I'd particularly love to hear from anyone who has implemented a JavaScript Widget solution and whether the development overhead was justified.


📚 Documentation References:
🔗 Related Community Discussions: