Dynamically specifying column names on table field update/create

[derac]

Hi all,

It would be useful to be able to specify rows to update or create in a table dynamically, perhaps through specifying an object with column names for the keys and values for the values, for instance:

Update row by Table Id and Row Id with one object specifying the fields:

{
“Salesforce opportunity Id”: “xxxxx”,
“Salesforce user Id 1”: 4,
“Salesforce user Id 2”: 4,
“Salesforce user Id 3”: 4,
}

In this way you could dynamically generate a table with arbitrary column names that are then programmatically filled with data. Currently, I believe this limitation could be worked around by passing around a csv and creating the table from that.

Thanks,
Derek

[connor]

Just to make sure I understand the use case you’re laying out, you mean that you want to be able to only update certain columns in a row but you want the ones you update to be dynamically chosen? I assume this would be so that you’re not overwriting info in the existing cells that you’re not updating.

One of the workarounds for that scenario would be to read from the existing row first and then use some logic to either set the values to the new value if they’re meant to be updated or set the values to the already existing values if they’re not meant to be updated. This would at least let you get the updating action down to one final card that handles all of it, although there would be a decent amount of FLO logic preceding it.

[derac]

Hey Connor,

I’ve attached an image to demonstrate the use case more clearly. I’m going to solve this particular problem in a different way, but I think this might be a useful idea to write out.

1. Creating a dynamic schema - I want to get a list of users from Salesforce in a particular department to associate data with. The number of columns and the column names will depend on the number of users returned and their names.

2. Create a table based on that schema. Maybe attach a datestamp.

3. Create a row based on that dynamic schema, currently impossible.

Thanks,
Derek