What is best approach for Parent Updates in UI when making Child Add/Edit/Deletes?

[WillowMobileSys]

This post is a bit long but is an important topic probably for all of us, if not now then in the future.

Several threads have discussed it but with no real conclusion on best approach. The reason, I have discovered, is that there are trade-offs depending on developer needs. The intent here is to gather all the info and issues with these particularly common use cases and discuss different workaround approaches until enhancements can be made to improve on these needs. This way we all can benefit and hopefully newcomers will find this in the future to help them.

When we want to see changes to Parent values in the UI after editing the Children there are 6 main use cases to consider

A) 3 for Add/Edit/Delete of the Children when in Edit mode of the Parent.
B) 3 for Add/Edit/Delete of a Child row directly - e.g. selecting child from Parent Detail view.

Consider Add and Edits Only for a Moment

When making Child changes in situation A), to see changes to the Parent immediately, summary functions need to be implemented in the Parent columns. Saving a child change triggers the recalculation of the summary functions upon return to the Parent Edit form.

When making Child changes in situation B), the UI flow never takes you to the Parent Form so summary functions will not trigger and the Parent summary fields will be out of sync. This can be corrected by implementing an Event Action on the Child Form Save. The action computes the summary fields.

Problem 1 - You cannot have both a summary function in the App Formula of the Parent field AND an Action that computes the same Parent field value. When in situation A), changing a Child from Parent Edit mode, an Event Action on the Child Form Save does not fire, it is ignored.

So, if we need to see Edit/Add changes in the UI, developers cannot support both situation A) and B) described above. You have to choose one or the other.

Now add Deletes to the Picture

In situation A) above, the UI currently does NOT have a Delete capability. When editing the Parent, no Inline or Overlay Actions are shown for the Children.

So if you need to support Delete you are kind of forced into situation B), support Direct Edit of Children and would likely want to include an Event Action. This means when editing Children from Parent Edit mode, you will not see the impact of the Child change to the parent in the UI.

Best Approach?

There are a number of workarounds I can think of but none give a great UX experience. So, keeping in mind that the goal is to support all 6 of the use cases described above, let’s discuss as a community ideas for workaround solutions…until AppSheet can provide an enhancement that eliminates the need to make these trade-offs.

[Marc_Dillon]

I have also struggled with this issue. Virtual columns will update in either of the situations. However sometimes you want the values actually in the spreadsheet, for whatever reason. I’ve attempted to use add/update permissions to disallow adding or updating a child from the parent’s detail, and only from the parent’s form. I can’t seem to remember at this time what issue I had with that approach, but I did not end up using it.

[WillowMobileSys]

With persistence and few hours of trial, I have created a way to workaround the shortcomings identified above and allow for Add/Edit/Delete changes to Children, regardless of how you access them (well not quite with Delete) and still apply updates to the Parent summary fields.

Adds/Edits

The idea is when any Adds/Edits are made to the children directly, force the Parent Form to show so summary functions there can be executed. This navigation is accomplished by adding an Action on the Child Form Save that sends the UI to the Parent Form where summary fields are updated and a second Save will apply any Parent field updates.

Delete Action

Delete was a little more tricky. I made use of an Inline Action, attached to a Virtual Column for display. But I needed to force the Action to end up on the Parent Form so those summary fields are properly updated. I tried creating a custom “Remove” action to use inline but no matter how I arranged the action I could not get the system Delete and “navigate to Parent Form” to work together.

I ended up with a custom action that “marks” the row to be deleted but also sets the Child value, included in the Parent summary field, to Zero. I then navigate to the Parent Form where the summary field is effectively calculated as if the row was removed. Your custom “Remove” set of Actions may need to do something other than just set to Zero.

Lastly, I created a Workflow that identifies the marked row and Deletes it after the updates have been made.

This left a little issue where the row to be deleted is still left in the view for some time before the Workflow can remove it. To help identify this in the UI, I used a Format Rule to highlight the row in Red and then use the Strikethrough property. This is a good visual indicator the row is being removed.

After all is done, Deletes must be performed from the Parent Detail view which is the only place the Inline Action shows… Not ideal but in my case Delete should not be used often so I think it is acceptable. By the way, I included Edit as an Inline Action as well and it works just fine with the above mentioned changes.

Minor Residual Issues

If you have any suggestions/solutions for the below, I would like to hear them.

1. Inline Actions are not shown on Forms but the column they are attached to IS shown. Since these are inline tables, I have tried using a Show If condition like that below to only show the Virtual Column in the inline table on the Detail view but it still shows on the Form as well.

     CONTEXT(View) = "My System Parent Detail View Name"
   

Edit: One way to reduce impact, if we can’t remove this Inline Action column, is to use a Color type column and set the App Formula = “”. These do not have headings and when Inline Actiona are not shown, they reduce to a very narrow column - also like they are not there.

2. When Direct Edits are made to the Children and they navigate to the Parent Form to update the summary fields, Save MUST be tapped to apply the Parent changes. If a user taps Cancel instead, they will be left with added/edited children but a Parent record that is has summary fields out of sync. To correct a record in this state its as easy as opening the Parent in Edit again and Saving. I’d like to eliminate this potential issue by removing the Cancel option but do not see a way to do that.

Conclusion

This is an ok workaround with some minor deficiencies and I consider it only temporary until the UI can be enhanced so that all these use cases function as expected without the heavy-handed development efforts.

[Fabian_Weller]

WillowMobileSystems:

I’d like to eliminate this potential issue by removing the Cancel option but do not see a way to do that.

Hi @WillowMobileSystems thank you for this nice article.
Here is a hack:
In Localize you can enter an expression like:
IF(CONTEXT("View") = "My Parent Form" , " " , "Cancel")