How can I send single email when changes made in a Parent with Children record?

[WillowMobileSys]

Similar questions have been asked about delaying workflows for similar reason - prevent duplicate emails. I have not seen a promising solution that can solve my problem.

In my case, I have a Parent record with three children. When a change is made i want to send an updated document reflecting the changes. As we all know, when saving a record with this structure, the Parent record is saved first and then the children.

I can’t trigger a Workflow email from the Parent changes because the children haven’t been saved and their changes are not reflected in the generated document.

I can assume Parent changes have been made when a child change triggers a Workflow BUT there is no guarantee of child order so its likely the other children have not yet been saved and the generated doc does not reflect those other child changes.

So I am looking to the community…again…for suggestions. Ideally I would be able to trigger a workflow only after ALL parent and child changes are saved. We do not (yet) have that capability. Alternatively, it would be nice to send off some kind of delay that triggers the Workflow after some time allowing all Saves to have occurred. Last ditch solution is to just send the updated document through user action (button tap) once all changes are verified as saved. This is not very user friendly.

It is not acceptable to just allow multiple emails and the last one wins. Thats the quickest way to lose customers/users.

I have been working on this for a while and would appreciate any help in trying to get to a work around/solution.

Thanks in advance!

(BTW - If i could assume that the children were all saved when the Parent changes are saved, then I could trigger this off the Parent changes and problem solved.)

[Phil]

See topic " Sending Email After Adding a Parent Record and All of Its Children" in this article https://help.appsheet.com/en/articles/961707-workflow

[Aleksi]

Or check this sample app ParentWorkflow from https://www.appsheet.com/portfolio/531778

[WillowMobileSys]

@Phil and @Aleksi Oh my gosh!! I feel so dumb! I originally coded exactly this and over time it was coded out bringing me right back to my original (but long forgotten) problem. I am my own worse enemy!! Thanks guys!!

[Phil]

HI John,
It happens to us all! Glad you are back on track.

[Aleksi]

As Phil mentioned, it happens

[WillowMobileSys]

Thanks to both of you!

BTW @Aleksi, I reviewed your sample ParentChild app. The supplied Workflow contains no conditions. Wouldn’t this mean that the Workflow would trigger twice for any actual Parent changes.

For example, you have Parent Name in the parent record. If I saved a record with a name and later realized it was mis-spelled, edited the record, changed the name and saved, I would get an Update trigger for the name change but also a second update trigger after the Save for when PDF_Sent is updated. Both of these would cause an email generated. Do I have that right?

[Eso_Surveyors]

Hi, all. in my case, i need a solution for when a parent and children are created for the very first time. we do not do updates. our users only ever create unique parent+children records. can someone help, please?

[Eso_Surveyors]

Aleksi and Phil both kindly showed me that the Workflow ran before the children records were written so i always get the email without children. in both the solutions mentioned here, the Workflow is tied to the parent record for updates. despite implementing exactly as the solution describes, in my case the children, the children are still written after the Workflow has happened. please note we never do updates, only ever create new records with children. i appreciate in advance any help you can provide.

[Bellave_Jayaram]

Check the sample app “Parent Workflow” from @Aleksi ‘s portfolio here - www.appsheet.com/portfolio/531778

[Eso_Surveyors]

thank you. i have. it follows the same logic as https://help.appsheet.com/en/articles/961707-workflow in its section “Sending Email After Adding a Parent Record and All of Its Children” i’ve implemented meticulously. i am only ever creating parent+child, never updating. So, UPDATES_ONLY never fires the Workflow. ADDS or ALL_CHANGES do. However, the child records are always written after the Workflow (when it fires)

[WillowMobileSys]

Currently, the only way to trigger additional processing AFTER the Parent and ALL children are written is to apply an update in some way after the initial save.

In your case, you will need to:

1. Add a flag to the parent record, e.g. Send Email?
2. Create two actions - 1) Set Flag - sets the the flag to a true value 2) Unset Flag - sets flag to false value.
3. Modify the entry Form view to add the Set Flag action on Form Save.
4. Set your Workflow to run on a Parent UPDATE and test for the flag = TRUE.
5. Add a step to the Workflow that calls the action to Unset flag.

What Happens?

On Form Save, the Parent record is saved first and then all of the children. Next the action runs to set the flag but this is an update to the parent record. This action triggers the workflow to run all your assigned steps, send email and etc, as well as reset the flag.

In the AppSheet document on processing after the parent and all children are written, it describes an alternative where the set and unset flag are done together like in a grouped action. This actually has the same processing effect. The grouped action is run on the device and sent to the server as two updates. When the server processes the first update, the Workflow is immediately triggered and runs. The second update would happen after the Workflow completes.

I like the first option only because it feels more intuitive to me.

I hope this helps!!

[Phil]

I have confirmed that the mechanism described in topic “Sending Email Only After Adding a Parent Record and All of Its Children” of this article works. See https://help.appsheet.com/en/articles/961707-workflow

However, the article did not say that you need to set “Is a part of” in the Ref field of the child record to “On”. That is important because that allows you to add child records at the same time you add the parent record. I have updated the article to explain that.

I also made the steps in the article more explicit.

Please try following the steps in the updated article and see if that resolves the problem. It worked for me. If you are still having problems, please let me know. I thought this problem was resolved earlier this week.

[WillowMobileSys]

@Phil I apologize if my response created more work for you in verifying the doc steps. I actually was trying to support the doc - at least secondarily. It is what I based my implementation on except I like using a “switch” (or boolean flag) instead of verbose status field.

I think the main confusion, and what I was trying to drive home, is that you simply cannot perform the requested action (Send email after ALL Parent and Children updates) triggering the Workflow upon an ADD. The Parent/Children must be saved first, then an UPDATE must be made that triggers the Workflow.

Again I apologize and will make sure I post in support of the documentation in the future.

[Phil]

Hi John,

Your response did not cause any additional work.

I had been working with Eso Surveyors earlier in the week and thought his problem had been resolved. I am still not certain why the procedure described in the original article did not solve his problem. When I saw this post, I realized Eso Surveyors’ original problem was not resolved. I wondered if the technique described in the article still worked. When I tried it, I ran into the “Is a part of” issue, and thought that might be why the technique listed in the article did not work for Eso Surveyors. As a result, I updated the article to clarify that point.

I am still uncertain why the technique was not working for Eso Surveyors. Hopefully the updated article content will help.

Your idea of using a Bool rather than a Text field is a good one.

Please keep posting. Your post are excellent. You are saving me work by doing so.

[Eso_Surveyors]

thank you all very much for your input. I am now OK for the moment, catching child records in the workflow emails. probably i missed the “between the lines” or maybe obvious in your lines. what i ended up doing: created a first action to change a parent field to “FIRE” and a second (hidden) action to change it to “EMAILED”. Created a Workflow to to check on UPDATE_ONLY the parent field = “FIRE” if so send the email then change the field to “EMAILED”. I made the app start in a DETAIL view so the surveyor could see a button of the 2nd action labelled SEND EMAIL. when the surveyor saves the FORM with parent and child records, children are saved AFTER the parent, and nothing is expected to happen. only when the surveyor taps the SEND EMAIL button the parent gets updated to FIRE, the Workflow checks its condition is true, sends email and then changes the trigger to EMAILED. but wait, there is more in the next post.

[Eso_Surveyors]

Eso_Surveyors:

I made the app start in a DETAIL view so the surveyor could see a button of the 2nd action labelled SEND EMAIL.

typo here. i meant to say “I made the app start in a DETAIL view so the surveyor could see a button of the 1st action labelled SEND EMAIL.” (which changed the trigger to FIRE.

[Eso_Surveyors]

even though all 3 APPS are copy/pasted the Conditions, APP TESO will properly resolve TRIGGER=“FIRE” is TRUE, but EXPENSES and PPE will NEVER resolve TRUE, always stubbornly resolve FALSE. so for EXPENSES and PPE i am forced to evaluate TRIGGER<>“EMAILED” and fortunately works. i do not know what to make of this.

[WillowMobileSys]

I assume you have confirmed that your trigger value is set to “FIRE” when the Workflow evaluates? You can test this by temporarily removing the Action that sets the “EMAILED” value. Either the value “FIRED” is not getting set OR it is misspelled is some way - maybe has spaces in it?

Depending on your future plans, it might be worth investigating. Keep in mind you are using an Enum field. If you start using it for other statuses, you’ll start generating unwanted emails with TRIGGER <> “EMAILED”.