…A long time ago in an app far far away, some folks built a mechanism to handle “variable depth row creation” for parent-child objects. This solution pattern required the Appsheet API at first, and then there were solutions for doing the same without the Rest API. The concept was to have a library of structures to then allow creation of instances of those structures. Several folks were working on this including @tsuji_koichi , @Grant_Stead and others.
Here is the post that required the Rest API:
[Copy Row along with child records](https://community.appsheet.com/t/copy-row-along-with-child-records/18045) Tips & Tricks ?
It should have been recognized that the coping row including the child table/rows are currently not supported and possible. However, I did find one way to do it. It works perfectly. Before you read this post, make sure a prerequisite to use this tip is that you are on the business plan holder where you have access to Appsheet API. What is behind the trick? Basically, the trick is to retain the row ID of the original row and keep this id within the new row which was generated after the actio…
And here was the post that did the same thing but without the Rest API:
[Copy parent record together with child records ; Action Only, No API, No workflow](https://community.appsheet.com/t/copy-parent-record-together-with-child-records-action-only-no-api-no-workflow/27619) Tips & Tricks ?
After introducing a trick how to copy the related child records along with parent record through the post of Quite a few people have been asking me how to manage it without API, but actions only. Sharing this trick may get the Appsheet sales team angry with me, so I m bit reluctant to do so, as it may reduce the sales opportunities for business subscriptions … , but let me put it aside now, This is what I managed to achieve the same task, “copy parent record together with child …
Anyway, since then, I was mulling over any improvements that could be made to this idea of generating instances of variable-depth “things” using actions, but also include support for multiple users and even sequential, ordered tasks, and this is what I came up with:
(The title is misleading, this is not a medical app per se)
Imagine you want a customizable workflow engine, but instead of using our workflows and field values, you want the data itself to be the workflow. New row = new task. But you don’t want a fixed type of workflow process. You want your audience to create NN types of workflows with variable numbers of steps. This is the “variable depth child record problem”. And, to make it even more complex, workflow steps might require predecessor steps, so you need to let your audience specify those as well. You want your workflows to run in series, in sequence.
Some of the design pillars of this app include:
Creating the workflow types
These are parent child relations using tables “Template Library” and “Template Library Steps”: if you study these tables, you’ll see that things are pretty appsheet-normal here. Typical stuff.
We provide a UX view called “Requests”.
Each end user will get only 1 row of data here, so the UX shows a detail view. I have to admit, this part of the solution feels incomplete and janky. But this single row of data has all of the information the operator has selected from the Template Library, plus whatever optional fields a designer wants to add. This data and view is at the very heart of this solution. You select from your template library and then click the red button “Create New Instance” (an action), which triggers the next part:
“Create New Instance” is a grouped action which simply calls two other actions:
** Action “Add New Order from Request” - Copy the template parent to the instance parent (“work orders”) - we have all of our info on our “request” page already, per previous step. We synthesize the Key/UniqueID for “Work Order” at runtime:
any(Work Order Request[TemplateLibraryID]) & "-" & any(Work Order Request[UniqueID])
** Action “Copy Children from Template to Work Order” - Copy the template children to the instance children (“step”). Same basic premise as the previous step, but this one is a bit more complex, and involves a) executing an action of a a set of rows, and then the copy command for the children. Again, we synthesize the Key.
That’s pretty much it. Copy as desired if you would like to study it. We threw in some usual extras like a menu system, users, and such. Hopefully this app can be “pre a porter” for all of your workflow needs.
As always, improvements, errors, ommissions always welcome.
