Record Selector ignoring Data Source mapping and auto-populating from URL parameter

Application Builder
1

I have a shared Add/Edit page* that uses URL parameters to switch contexts. I have a Record Selector bound directly to Data Records > Single REQUEST > ID.

Even though this element is not bound to the Single ITEMS data source, the builder is auto-populating it with the ITEM ID from the URL whenever I enter ‘Edit’ mode instead of leaving it blank.

Is there a way to prevent the builder from injecting URL parameters into bound Record Selectors when the Data Source context doesn’t match the URL context? It seems like the builder is overriding my explicit field binding with the URL state.

My workflow utilizes a button on the ‘Request’ page that navigates to my shared Add/Edit form, passing a Request ID to prefill a Record Selector (using only the Single REQUEST data source). This ensures the submitted item is automatically linked back to the original request, and the user can click that link to view relevant details.

The issue is that the Record Selector is incorrectly auto-populating during the ‘Edit’ flow. Even though this element is explicitly bound to the Single REQUEST data source, it is being force-populated with the Item ID (Single ITEM data source) from the URL whenever I enter ‘Edit’ mode. Crucially, when adding an item without a request (or when editing), this field should remain blank, but the current state management is overriding my binding.

*Historically, the recommended best practice for this builder was to use a single, shared form for both Add and Edit operations. Post-upgrade, I’ve received guidance to split these into separate pages. However, I’m seeking to avoid this approach because it introduces significant maintenance overhead, and any change made to the ‘Add’ flow must be manually replicated in the ‘Edit’ flow, which is highly inefficient.

I’ve designed this workflow to prioritize user experience, as expecting manual record selection would be both prone to error and confusing for the average user. My setup automates the Request ID mapping to keep the submission process streamlined, which is why the current issue is so problematic.]

2

Hey @frederikdc,

Could you please take a look at this request? Maybe you know if there’s a way to prevent a Record Selector from being automatically populated from the URL context?

3

Hi,

I’m not sure if I understand the question. Is it possible to record a small demo video or describe your process step by step?

4

My setup works like this:

  • I use one shared form page for both adding and editing items.

  • I have two data sources on this page. ITEM and REQUEST.

  • To edit an item (ITEM data source), I open the same form in prefilled mode by passing ?id=# in the URL, which is the ITEM id. ex: /add/item?id=#

  • The page contains a Record Selector that is explicitly bound to the data source REQUEST. It is used so that when someone clicks a button called “Fulfill request #38” the /add/item form page opens and the record selector is automatically populated with #38.
    This also give the url a parameter: /add/item?id=38

Is there any way to prevent Record Selectors from automatically consuming the page id parameter? Only use it when it comes from the link intended (clicking on the fulfill request button to take you to the add item page), but not when editing an item.

Or am I doomed to fiddle with two time-consuming forms and risk errors because I might forget to update the edit form?

Does anyone have a suggestion for a similar working setup?

5

Maybe having 2 Record selector elements on the page and use a condition in the Visibility tab to determine which one of the selectors you show to the user might be an option?

6

Even though the record selector isn’t visible, it is still populated and passed to the table on submit.

7

I’ve resolved the issue. The solution is to create two parameters: id (numeric) and request_id (numeric). Then, configure both the record selector and the button on the separate page to use request_id rather than the standard id.

I didn’t know it was possible to do this (thanks, chatGPT!).