When a portal lacks stable record identifiers, define an owner-approved combination of matching fields and verify it against the actual candidate rows. A similar name or row position is insufficient. Preserve the observed evidence and stop when required fields are missing, conflicting or unable to distinguish duplicates. A local task reference can organise your notes, but it does not create authoritative identity for the portal’s record.
Establish what the portal can actually show
Inspect the available fields with the portal owner before designing a selection rule. A list may show shortened names, dates, amounts and statuses, while the detail view supplies a reference or entity context. Identify which fields are authoritative for the intended operation and which are only descriptive hints.
Do not assume a reference in the interface is permanent or unique. Ask what it identifies and whether it remains valid across exports, account changes or revisions. If its meaning is unknown, preserve that uncertainty. Renaming it record ID in the automation does not improve its authority.
Keep the approved task scope narrow. Selecting a report row for inspection is different from selecting a supplier record for amendment. The consequences of a mistaken match determine what evidence and human review the owner requires, not the model’s apparent confidence.
Define matching fields before searching
Write the accepted account/entity context and required matching fields in the brief. Depending on the portal, those fields might include a documented transaction reference, record type, date and owner-approved descriptive attributes. This is a proposed selection design, not a claim that every combination guarantees identity.
Preserve raw field values and accepted normalisation rules. Removing display spaces may help compare a known reference, but dropping leading zeros or merging similar entity names can destroy a meaningful distinction. Ask the owner which transformations are legitimate for the relevant field.
Source: OpenAI Structured Outputs supports schema-constrained results. A proposed candidate record can require observed fields, matching status, source view and uncertainty reason. Schema conformity does not establish that the candidate is the intended portal record.
Inspect the candidate population and its limits
Record the actual filters and scope used to find candidates. A result on the first page does not establish that no equal candidate appears later. Where the portal hides rows through pagination, loading or permissions, define how the accepted process verifies the relevant candidate population.
Treat incomplete search as a limitation. If required pages cannot be inspected, the process should not confidently select a row merely because it is the only one visible. The owner can approve a narrower scope, supply another identifying field or choose manual handling, but that decision must be explicit.
Compare candidates against all required fields. A strong name resemblance does not cancel a conflicting account reference. An amount and date match may still be shared by separate transactions. Keep those fields as evidence under the owner-approved rule rather than using an unexplained confidence score as the selection authority.
Preserve evidence without inventing portal identity
Source: OpenAI function calling separates model requests from application execution. A proposed tool request that acts on a candidate should carry the evidence and checks required by the application. The model’s selected row must not become unquestioned authority for a later mutation.
Use a local task reference to connect the brief, candidate observations and human decision. Label it as your workflow’s reference. It can support investigation, but cannot replace a missing portal identifier or prove that a row still represents the same record after the page changes.
Capture enough restricted evidence for a reviewer to understand the selection. Avoid storing unrelated rows or whole customer histories merely because the list was open. Record the relevant account context, observed fields and time, with handling rules set by the information owner.
Portal row-selection worksheet
Task/brief version: ______ | Portal/account context: ______ | Record owner: ______
| Matching item | Expected evidence from the brief | Observed portal evidence | Disposition and resolution owner |
|---|---|---|---|
| Entity context | Accepted supplier/customer entity and account | Visible account and relevant page context | Confirmed or unresolved; owner ______ |
| Owner-approved fields | Required combination of reference, date, type or other verified attributes | Raw displayed values with source view | Matched, different or unknown; owner ______ |
| Candidate population | Accepted filter/scope and handling of hidden pages | Candidates inspected and any unavailable rows | Complete for scope or incomplete; owner ______ |
| Conflicting fields | Values that disqualify or require clarification | Specific conflict and evidence reference | Reject candidate or hold; owner ______ |
| Duplicate candidates | Evidence needed to distinguish otherwise equal rows | All remaining equal candidates | No guessed selection; owner ______ |
| Freshness | Relevant brief and portal version/time | Latest permitted reread before the next action | Recheck changed values; owner ______ |
| Proposed selection | The candidate and exact evidence supporting it | Restricted view or temporary selection reference | Human accepted, rejected or unresolved; reviewer ______ |
Selection rule: choose only when the owner-approved fields and scope establish the intended candidate without unresolved conflicts. A row position, display-name resemblance or generated local reference does not prove portal identity. If the evidence cannot distinguish candidates, stop and use the approved manual route.
Work through one match, equal rows and a conflict
Consider a hypothetical portal listing dispatch records. The approved brief supplies the account context, a documented dispatch reference and a date. One permitted detail view shows all those values without conflict. Under the owner’s accepted rule, the reviewer can accept that candidate for the next scoped inspection step. This does not grant permission to change it.
In a duplicate case, two rows show the same shortened description, date and amount. Neither displays the reference required by the brief. The process remains unresolved and asks the owner for another accepted distinguishing view or manual selection. Picking the first row would turn ordering in the interface into an identity rule.
A conflicting case shows the expected reference under a different entity. Preserve both facts and stop. The reference might be unique only within an account, or the brief might contain an error. The portal owner resolves that question; the agent should not choose whichever clue seems more persuasive.
In a missing-field case, the date is blank in the list and the detail view is unavailable. Do not substitute today’s date or use the newest-looking row. Record which required field could not be checked and who must supply the evidence. Missing information is not a zero or a matched value.
Recheck selection before the next action
A list can resort or refresh after navigation. A previously selected row number is then unreliable. Before the next permitted operation, reread the accepted identifying evidence and relevant current state. If the fields change or the candidate can no longer be established, invalidate the earlier selection decision.
Source: n8n human review for tools documents approval or denial before a selected agent tool runs. Where that mechanism fits an integration, show the proposed target and parameters to the reviewer. Approval of a tool request does not itself establish that a portal row was matched correctly.
Test the worksheet with sorted rows, duplicate labels, hidden candidates, conflicting references and missing detail views. Review the expected and observed dispositions with the record owner. A blocked selection is a valid pilot outcome when the evidence cannot support a reliable match.
If the portal cannot provide adequate matching evidence for the intended action, consider keeping that action manual or seeking a supported integration with stable identifiers. The decision should reflect actual evidence and consequences rather than a promise that a browser agent can infer identity from appearance.
FAQ about selecting records without stable IDs
Can the agent use the row number as the identifier?
Only as an observation of that view, not as proof of enduring record identity. Sorting, filtering or refreshed data can change positions. Verify the owner-approved fields again before the next permitted action.
What should happen when two candidates look equally correct?
Preserve the candidates and the missing distinction, then stop for an authorised decision. Obtain another verified field or use the approved manual route. The agent should not break the tie using confidence or visual similarity.
Does giving the candidate a local reference solve the problem?
It helps organise the workflow’s evidence, but it does not create a portal identifier. Keep the local reference linked to observed fields, time and reviewer decision, and recheck current identity before acting.
If your business needs help scoping this workflow, explore Custom AI agents, our AI automation services, and the custom-agent workflow guide. The agents and automation comparison and custom AI agent glossary explain the options. To discuss your systems and approval rules, get in touch.