Hi Everyone,

Core issue is that if any modifications were made to a table after its creation, then a replica is made without the exact same sequence of steps (which cannot be looked up in any way), it will drop variable associations in the replica version once migrated into another environment.

We are aware that we cannot change the original data table schema that we defined when we created the data table. For example, when we export the data table that we edited, the exported .csv file contains the original custom field keys, and not the newly edited titles (or labels) of the keys. 

We were also advised that we cannot modify the API Field ID later. They have different purpose. Hence, labels are for display purposes while ID is used to identify the field.

However, are there any workarounds so that fields (with assigned variables) from the originating data table would not drop variables in the replica version?

For context, please see screenshots attached and details below:

Name of original flow(s).

We have quite a few tables and flows that are in this situation. One flow you can try it with would be the "DS_Main_IVR".

Step/block number of Data Table Lookup action in the flow: 408

Steps on how we can possibly reproduce this behavior? 

Build a table with a few fields in environment "A", and create a field you don't actually want.  Since you cannot delete it, rename it and move it to the bottom of the fields list. 

Create another new one, and move it up to the middle of the fields you have created. 

In environment "B" create the same table, but just build it exactly as they ended up in environment "A" (without the deletion or shuffling anything around). 

Create a flow in environment "A" that references the table and assign variables to each field except the one you renamed since technically it would not be used.. 

Export the flow from environment "A" as a .i3InboundFlow, then import it into environment "B". 

Check the database fields in the lookup block for that table and you should see the variable dropped in the field you moved to the middle of the stack.

Hello Joseph, 

The only possible workaround I can suggest is duplicate the data table without column names. The id's for the columns cannot be edited. 

I would be happy to see what the rest of the community has to offer as a possible workaround. 

Cheers, 

Hi Everyone,

Core issue is that if any modifications were made to a table after its creation, then a replica is made without the exact same sequence of steps (which cannot be looked up in any way), it will drop variable associations in the replica version once migrated into another environment.

We are aware that we cannot change the original data table schema that we defined when we created the data table. For example, when we export the data table that we edited, the exported .csv file contains the original custom field keys, and not the newly edited titles (or labels) of the keys. 

We were also advised that we cannot modify the API Field ID later. They have different purpose. Hence, labels are for display purposes while ID is used to identify the field.

However, are there any workarounds so that fields (with assigned variables) from the originating data table would not drop variables in the replica version?

For context, please see screenshots attached and details below:

Name of original flow(s).

We have quite a few tables and flows that are in this situation. One flow you can try it with would be the "DS_Main_IVR".

Step/block number of Data Table Lookup action in the flow: 408

Steps on how we can possibly reproduce this behavior? 

Build a table with a few fields in environment "A", and create a field you don't actually want.  Since you cannot delete it, rename it and move it to the bottom of the fields list. 

Create another new one, and move it up to the middle of the fields you have created. 

In environment "B" create the same table, but just build it exactly as they ended up in environment "A" (without the deletion or shuffling anything around). 

Create a flow in environment "A" that references the table and assign variables to each field except the one you renamed since technically it would not be used.. 

Export the flow from environment "A" as a .i3InboundFlow, then import it into environment "B". 

Check the database fields in the lookup block for that table and you should see the variable dropped in the field you moved to the middle of the stack.

Thanks, Cameron. Hopefully, there are still other ways to somehow reduce the repetitive tasks while migrating between environments.

Have a great weekend ahead!

Hello Joseph, 

The only possible workaround I can suggest is duplicate the data table without column names. The id's for the columns cannot be edited. 

I would be happy to see what the rest of the community has to offer as a possible workaround. 

Cheers, 

Hi Everyone,

Core issue is that if any modifications were made to a table after its creation, then a replica is made without the exact same sequence of steps (which cannot be looked up in any way), it will drop variable associations in the replica version once migrated into another environment.

We are aware that we cannot change the original data table schema that we defined when we created the data table. For example, when we export the data table that we edited, the exported .csv file contains the original custom field keys, and not the newly edited titles (or labels) of the keys. 

We were also advised that we cannot modify the API Field ID later. They have different purpose. Hence, labels are for display purposes while ID is used to identify the field.

However, are there any workarounds so that fields (with assigned variables) from the originating data table would not drop variables in the replica version?

For context, please see screenshots attached and details below:

Name of original flow(s).

We have quite a few tables and flows that are in this situation. One flow you can try it with would be the "DS_Main_IVR".

Step/block number of Data Table Lookup action in the flow: 408

Steps on how we can possibly reproduce this behavior? 

Build a table with a few fields in environment "A", and create a field you don't actually want.  Since you cannot delete it, rename it and move it to the bottom of the fields list. 

Create another new one, and move it up to the middle of the fields you have created. 

In environment "B" create the same table, but just build it exactly as they ended up in environment "A" (without the deletion or shuffling anything around). 

Create a flow in environment "A" that references the table and assign variables to each field except the one you renamed since technically it would not be used.. 

Export the flow from environment "A" as a .i3InboundFlow, then import it into environment "B". 

Check the database fields in the lookup block for that table and you should see the variable dropped in the field you moved to the middle of the stack.

Hi Everyone,

Core issue is that if any modifications were made to a table after its creation, then a replica is made without the exact same sequence of steps (which cannot be looked up in any way), it will drop variable associations in the replica version once migrated into another environment.

We are aware that we cannot change the original data table schema that we defined when we created the data table. For example, when we export the data table that we edited, the exported .csv file contains the original custom field keys, and not the newly edited titles (or labels) of the keys. 

We were also advised that we cannot modify the API Field ID later. They have different purpose. Hence, labels are for display purposes while ID is used to identify the field.

However, are there any workarounds so that fields (with assigned variables) from the originating data table would not drop variables in the replica version?

For context, please see screenshots attached and details below:

Name of original flow(s).

We have quite a few tables and flows that are in this situation. One flow you can try it with would be the "DS_Main_IVR".

Step/block number of Data Table Lookup action in the flow: 408

Steps on how we can possibly reproduce this behavior? 

Build a table with a few fields in environment "A", and create a field you don't actually want.  Since you cannot delete it, rename it and move it to the bottom of the fields list. 

Create another new one, and move it up to the middle of the fields you have created. 

In environment "B" create the same table, but just build it exactly as they ended up in environment "A" (without the deletion or shuffling anything around). 

Create a flow in environment "A" that references the table and assign variables to each field except the one you renamed since technically it would not be used.. 

Export the flow from environment "A" as a .i3InboundFlow, then import it into environment "B". 

Check the database fields in the lookup block for that table and you should see the variable dropped in the field you moved to the middle of the stack.

HI, 

You should try Archy tool to migrate IVR flow and their data table along with attribute. Archy and CXasCode help to migrate these kind of task easily.

Hi Everyone,

Core issue is that if any modifications were made to a table after its creation, then a replica is made without the exact same sequence of steps (which cannot be looked up in any way), it will drop variable associations in the replica version once migrated into another environment.

We are aware that we cannot change the original data table schema that we defined when we created the data table. For example, when we export the data table that we edited, the exported .csv file contains the original custom field keys, and not the newly edited titles (or labels) of the keys. 

We were also advised that we cannot modify the API Field ID later. They have different purpose. Hence, labels are for display purposes while ID is used to identify the field.

However, are there any workarounds so that fields (with assigned variables) from the originating data table would not drop variables in the replica version?

For context, please see screenshots attached and details below:

Name of original flow(s).

We have quite a few tables and flows that are in this situation. One flow you can try it with would be the "DS_Main_IVR".

Step/block number of Data Table Lookup action in the flow: 408

Steps on how we can possibly reproduce this behavior? 

Build a table with a few fields in environment "A", and create a field you don't actually want.  Since you cannot delete it, rename it and move it to the bottom of the fields list. 

Create another new one, and move it up to the middle of the fields you have created. 

In environment "B" create the same table, but just build it exactly as they ended up in environment "A" (without the deletion or shuffling anything around). 

Create a flow in environment "A" that references the table and assign variables to each field except the one you renamed since technically it would not be used.. 

Export the flow from environment "A" as a .i3InboundFlow, then import it into environment "B". 

Check the database fields in the lookup block for that table and you should see the variable dropped in the field you moved to the middle of the stack.