Challenge! How to use an EnumList to populate a Child Table?

Currently, there is no mechanism to allow us to choose multiple child items in one dropdown so I am trying to build one.

My use case is adding Assigned Technicians to a WorkOrder. I want to select multiple technicians using an EnumList and then add those picked techs into the Assigned Technicians child table on saving of the form. Later each technician will update their time on the job site, recorded in this same child table.

I can create the EnumList to select multiple technicians with no problem. I am now trying to create a set of Actions to insert these picked techs into the child table.

I need to be able to add the Order ID as well as the Tech ID. And I need to do it once per picked technician.

The only Action type that makes sense is โ€œexecute an action on a set of rowsโ€. This will allow to cycle over the picked list and perform the add for each picked technician.

But once I navigated through the Actions to the point to perform the add, while I do have the Tech ID from the picked list, I no longer have access to the Parent row to get the Order ID.

Using โ€œadd a new row to another table using values from this rowโ€ will only allow adding of a single row. I need to do it once per selected technician.

Any suggestions on how to overcome this challenge?

Solved Solved
0 7 1,198
1 ACCEPTED SOLUTION

GreenFlux
Participant V
7 REPLIES 7

GreenFlux
Participant V

Hey @WillowMobileSystems! I ran into the same problem last year and came up with a solution that may work for you.

https://community.appsheet.com/t/dynamically-create-x-number-of-child-records-from-parent-enumlist-w...

Dang! I should know to search the community first by now! Iโ€™m surprised I missed this as I have been thinking about it for a while.

I am fairly certain I have seen other posts requesting similar functionality. So maybe this should be submitted as a feature request?

I have been analyzing your sample app and playing around with the functionality. Its a great solution to the problem and probably the most compact. Its not difficult to implement but not trivial either. I now just need to decide if I want to include this (i probably will) or stick with the standard way of adding one by one.

There is one potential โ€œgotchaโ€ I feel you might want to be aware of. In your CopyMasterLineItem action you have the expression:

`ANY(FILTER(โ€œOrderโ€,CONTAINS([Trigger],โ€œCreateLineItemsโ€)))โ€™

IF, and maybe a big if, you have multiple people adding Orders at the same time, because this expression simply picks the top returned row it could mistakenly associate the list of line items with the wrong Order record.

I feel there might be a way to prevent that, short of locking users out of the function, but havenโ€™t thought of it yet.

I love your solution, as I think its the best option right now and I also believe there is enough need that this be made a feature and then its just a matter of setting a switch on the child column!!

Thanks @WillowMobileSystems! Since building the sample, I have started using a [Trigger] that stores a list of parameters to avoid the multi-user conflicts. I just didnโ€™t update the sample app.

I usually use something like this for the [Trigger] value:
{"CreateLineItems", USEREMAIL(), NOW()}

And I will use the same [Trigger] column for various workflows, each with a different keyword as the first parameter.

Very smart approach! I like it!

Oh hey! There was one thing I was curious about and want to ask.

When I create apps I typically use a workbook with several sheets in them and then point the tables to the desired sheet.

I noticed in your sample app when I copied it, there was a workbook with a single sheet in it for each table. Is that how you normally setup the data for your apps? If so, is there some benefit to doing it that way we can all learn of?

GreenFlux
Participant V

I made the sample using Start with an Idea tool so it would auto-generate the data and icons for my sample. It creates a new workbook for each table for some reason.

I usually use the same workbook for all sheets. But there are definitely reasons not to, in certain cases.

On larger apps with lots of users and different UserTypes, Iโ€™ll split the sheets based on who needs access. E.g. All shared sheets in one workbook, and AdminOnly tables in another. It makes it easy to share the spreadsheet with different users, and keep the lower-level users from seeing too much data.

And if I have several Read-Only tables, Iโ€™ll split them into a different workbook so the whole workbook can be cached separately from the tables with write access.

Top Labels in this Space