Verify? Nah - this is about your data model design. Views are extremely powerful - they let you consolidate information and manage it as a unified collection of records. Then, when you need a certain filtered view of those records and with specific fields, views allow you to virtualize the outcome instead of having separate physical silos.
This is a common challenge - how do you know if you laid out the data structures to meet the emerging requirements as you continue to shape the solution? It’s a moving target in most Airtable systems.
I don’t have a simple answer for this, but no one else does either because they don’t know your business, nor are there any forward-looking written requirements that can guide us. But I know that early data model choices tend to dictate (often constrain) what’s possible in the future. Also, know that in most cases, early experiences with Airtable typically miss two key capabilities that, if fully understood, invariably change the data model approach. A clear understanding of synching and views may cause you to reshape your data and your workflows.
As a matter of practice, I avoid engaging in data model design, and especially through community conversations because there are so many unknowns in this exchange, and it’s really easy to provide bad advice.
It is possible to build the automation with this data model. However, that is a different (but related) issue from whether or not the data model is a good way of storing and representing the data.
However, even if you get this automation to work the way you want, you may still be reinforcing a base design that will not serve you well in the long run.
Whether this approach works depends a lot on how the table is used. For example, if people ever create a record in Table B manually, you run the risk of a newly created record being deleted before data entry is completed, because it might not have a value in the linked record field. The same issue exists if a record ever needs to change which record it is linked to. In between unlinking the old record and linking the new record, the record will be briefly an orphan.
Depending on the relationship and the mechanism for deleting the child records, it can also mean more automation runs compared with a scripting solution.