Hello,
Is there any way to run a logic block when a row is deleted on a subtable? I can’t seem to use any of the event actions to properly configure this. It works on field value change of a specific field but I need to be able to run logic when a line is deleted from a subtable. Thank you!
There is not currently an event action that will run as a result of deleting a subtable record. There are means of detecting this, like a pre-delete trigger (only applicable if the subtable is of type Main), before save logic, or change detection in the action block or update trigger for the main table. You can also use a different type of event action and check if a subtable has had a row deleted.
If you would like to workshop some other approaches, feel free to provide some additional context and we can discuss.
If you are a customer or partner and would like to request a new feature, please work with support to create a feature request.
Okay but if it was a change specifically needed for the application UI lets say there wouldn’t be a way to change the UI dynamically based on a pre-delete? Specifically, we have a toggle that is switched on based on an entry being present in a subtable. If that entry is deleted in the subtable, the toggle is still switched on because the logic can’t run again. And there is no way to prevent this right?
I believe that’s correct; if you have a checkbox selected in the UI, there won’t be a way of unselecting the toggle on the action of deleting a subtable row. It might be possible to attach a Field Value Changed action to the subtable itself, but this will likely trigger when the subtable is created or deleted, not during action of an individual row.
For your specific use case, what action is selecting the toggle in the first place? It might be possible to use another event action or save to reevaluate the state of the record, but it might also be more fitting to use a header-detail application and table structure or a parent record and separate table record with an inline application rather than a subtable. With either of those, you would be able to handle the delete action through standard Row Deleted actions or `Common Context.
Its a bit of a niche situation. I have a mini app that pops open that shows a subtable, which is a list of people on a commission.
There are different commission internal types, primary, secondary, manager etc. There is the ability we have to split the unit count, but only primary and secondary people can use it. We have a checkbox toggle called Split Deal that automatically will split the deal between a primary and secondary person.
The idea is that IF the subtable has a PrimarySalesperson, the Split Deal toggle box is enabled. However, IF the subtable does not have a PrimarySalesperson, the Split Deal toggle box is disabled, indicating to the user they can’t split the deal. This is just for ease of understanding on the user side.
However, if the user has a Manager and PrimarySalesperson line, the Split Deal box is enabled. Then, they delete the PrimarySalesperson line and the split deal box is still enabled. They won’t be able to Split the Deal in actuality but the UI is experience is a bit more confusing to the user now. Does that make sense?
That scenario does make sense. I’ll see if someone else weighs in here with an idea, but I’m not sure that can be accomplished without either an enhancement for subtable row actions or a change to the data model.
Is there a reason in this case that a Primary Salesperson isn’t required? I don’t fully understand the context, but it does sound like lack of a Primary prevents the user from being able to split the deal. Is splitting the deal something that happens automatically when Split Deal is selected and the user saves the record, or is there an action associated with it like a row action?
It could make some sense to include a dedicated field for Primary Salesperson outside the bounds of the subtable, but that is again a data model change that might not be desirable.
The Primary Salesperson isn’t required all the time because sometimes there is someone with a different role who would make the sale but they will never have a split deal, which is why we are limiting it.
When Split deal is selected and a primary salesperson is there, a secondary salesperson is automatically added to the subtable and the unit count is automatically divided and set to 0.5 for the primary salesperson and secondary salesperson. If its un-clicked, the unit count goes back to 1.0 for primary salesperson and 0.0 for secondary salesperson.
Split Deal is a true/false selection button above the subtable.
Thanks for the clarifications. It sounds like this scenario will not work without an enhancement or architectural change - there are a variety of other ways of getting the Split Deal and subtable values into the right state (like field actions titled Split Deal and Unsplit Deal / Merge Deal instead of field value changed logic), but in order to preserve the desired user experience, you’d need to implement a more significant change like converting to a Header-Detail or using Inline applications.
If you do want to go forward with an enhancement request, please work with support to file a ticket!
Sounds good thank you Ross for the confirmation.