Native Automation Create Row rejects valid Single Select option ID

[stuartyoung1971]

Hello Baserow team,

We are testing a native Baserow Cloud automation and have encountered a reproducible problem with a Single Select field in a Create a row action.

Workflow: 57953
Destination table: Assessments & Reassessments
Single Select field: Assessment Type
Field ID: 10760947
Valid options: Initial Assessment and Reassessment

The workflow repeatedly fails at the native Create a row action with:

Value error for field "Assessment Type": The provided select option value '7659151' is not a valid select option.

We have tried the following:

1. Confirmed that Assessment Type is a valid Single Select field and that both options exist.
2. Disabled Assessment Type in the Create Row action, published the workflow, and tested again. The workflow still attempted to submit 7659151.
3. Deleted the entire Create Row node and created a completely new Create Row node.
4. In the new node, we configured only the Client field and never enabled Assessment Type.
5. Published the new workflow and tested again.
6. The completely new node still failed with the same Assessment Type error and the same value 7659151.
7. When Assessment Type is enabled in the native Create Row action, its input displays “Choose a number value, e.g. 42.”

The preceding nodes—HTTP trigger, Client lookup, Staff lookup, Assessment duplicate check, and Router—all complete successfully. The failure occurs only at Create a row.

Could you please advise whether this is a known Automation Builder issue, or explain the correct way to provide a Single Select value to a Local Baserow Create Row action?

We would also appreciate clarification about why the Create Row action continues attempting to submit 7659151 even after Assessment Type is disabled and after the entire Create Row node has been deleted and recreated.

Thank you for your help.

[AgustinCarozo]

Hi Stuart ,

That could have been a wrongly set up field or a cache issue.
I managed to run your automation normally,

In order to user a static option you just need to write its corresponding text, and if you would like to do it dynamically you just need to chose the dynamic option from the previous node.

[stuartyoung1971]

Hi Agustin,

Thank you for your help. We tested your recommendation today. In the Create Row action, Assessment Type was set as the static text “Initial Assessment” rather than an option ID. We published the workflow and ran a new test.

Unfortunately, the Create Row action still failed with the same error:

Value error for field "Assessment Type": The provided select option value '7659151' is not a valid select option.

The workflow configuration visibly shows “Initial Assessment”, but at runtime the Create Row action still appears to submit 7659151. The HTTP trigger, lookup steps, and Router all completed successfully; only Create Row failed.

We have stopped further testing for now to avoid consuming additional automation credits. Is there a cache/reset step we should perform, or does this behavior indicate an Automation Builder issue?

[AgustinCarozo]

I changed the trigger to a manual one and ran it again,
and once again I was successful, I did this by emulating your account so all steps are running normally.

[stuartyoung1971]

Hi Agustin,

Thank you again for testing the automation from our account. We continued testing and have narrowed the remaining issue down considerably.

The HTTP trigger is now working correctly and receives our synthetic POST requests successfully. We also corrected the Create Row mappings. When the Create Row node is tested, it now correctly writes the Client, Completed By, Assessment Type, Assessment Status, and Source Submission ID.

We also confirmed that the duplicate-check logic works when the nodes are tested individually. The Assessment lookup can find an existing row by Source Submission ID, and when a match is found, the Router correctly takes the Default branch rather than the “Create — No Duplicate Found” branch.

The remaining problem occurs during a full HTTP-triggered test run. We send the same synthetic submission ID again, but the “List rows in Assessments & Reassessments” lookup returns []. The Router therefore treats the submission as new and executes Create Row again, creating a duplicate.

We removed and recreated the lookup’s dynamic reference as:

HTTP trigger → Body → submission_id

but the same behavior continues during the full workflow.

We also downloaded the full payload from the lookup node’s History result, but Baserow provides only []; it does not show the resolved runtime filter/input value. So we cannot determine from the History screen what value the lookup is actually receiving during the full execution.

Could you please emulate our account again and inspect this workflow, particularly the runtime behavior of the Source Submission ID lookup and duplicate/idempotency check? We would like the workflow to behave as follows:

First submission → no matching Source Submission ID → create one Assessment

Same submission received again → matching Source Submission ID found → Default branch → do not create another Assessment

We have stopped further testing for now so we do not continue creating synthetic duplicate records while troubleshooting.

Thank you very much for your help with this.

Best regards,
Stuart Young
FamilyBridge: Aging Advisors

[AgustinCarozo]

Hi Stuart,

perhaps the issue is that you are using the trigger webhook url as test and if live you should be using the “Published one”?