I am working with the “SeaTable Rework” app in make.com.
However, after creating a new row, the fields of the row are not displayed when referencing in subsequent modules. This is different with the old version of the SeaTable make.com app (and with Airtable).
Can you deliver more details? Is the row really created in SeaTable? Did you probably use a “read-only” API Token and therefore make.com can not generate the new row?
My API token is Read/write and the new line is also created in SeaTable.
I have created a new SeaTable base and a new scenario in make.com as a test. I also use SeaTable Rework here.
After successful execution of “Create a Row”, all newly created fields are displayed in the confirmation - however, keys are specified instead of the field names.
In the following process step (here only a “Set Variable” as a test), the fields from the previous step are displayed - but only with the above-mentioned key names.
I have reproduced this in my make.com scenario mentioned at the beginning. And there, too, only key names are displayed in the transaction history, not the field names.
However, in the “old” scenario, the key identifiers are not displayed for selection in subsequent process steps. There is therefore a difference between existing scenarios and newly created scenarios.
As far as I know make.com keeps old versions of the apps and executes a node always with the version of the app of the creation time. Therefore, it is possible that the same node behaves different depending when the node was created.
On the one hand I like this, because it might prevent errors due to code changes. On the other hand it confused like now.
The problem is, that I have no access to the source code of the SeaTable App. I only can manage the SeaTable Rework App and also there I can not see any kind of history.
I have 10 workflows that I switched from Airtable to SeaTable. I used the original SeaTable-make.com app, which is now marked as “deprecated”. It only worked with a lot of workarounds…
I now wanted to switch the 10 workflows to the make.com app “SeaTable Rework”. But I get the problem described here. I obviously have to recreate all scenarios “from scratch”. This should not become a recurring pattern for future changes to the SeaTable make.com app.
Regardless of the fact that I have to recreate all scenarios, the problem remains that key names are output instead of field names. This is a bug in the current “SeaTable Rework” app - which does not exist in the old one.
I just checked the history of this case. Here is the explanation.
The SeaTable API always returns the column ids (like 0000) after a row is created. One of the first versions of the SeaTable Make.com App contained a function that after such a create another call was executed to get the column names.
I decided that this additional command was removed due to these reasons:
you just half your api limit if you do two requests instead of one
the column_id stays fixed, even if you change the name of the column.
also you can detect the value that you want to may by the output, not the column name.
Therefore I decided to remove this convenient function.
Still there is an easy workaround if you need the column names in every case. Just add another “Get a row” command after the creation and search for the newly created row by the _id. You will get the row with the column names.
The problem is not only the field names but also the contents of “single select” fields. Here, too, only keys are displayed instead of values, making it impossible to implement correct logic.
Here is an example from an n8n call of the current community app n8n-nodes-seatable. The same applies to the current make.com Seatable rework app.
Addendum: So you MUST connect a “Get Row” for each “Create Row” so that you can program comprehensible logic. And this does not save any transactions - you always need two transactions.
If you “CREATE A ROW”, then you have already all the values. Why do you need to read the values again from the output of the creation event?
If you “GET A ROW”, you will get all the columns and values in a way, that you can work with it.
Let me make an example:
you receive some data from a form like “Mercedes” and “red”
you create a record in SeaTable and you write “Mercedes” into the first column and “red” into a “single select column”.
now there is a third step. There you want to use “red” but from SeaTable you only receive “55341” which is the key of the single selection option. But this is no problem, because you can use as input in the third step the output of the first step. There you have the information “red”.
In my opinion, you are inventing a problem where there is none.