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.)
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
Or check this sample app ParentWorkflow from https://www.appsheet.com/portfolio/531778
HI John,
It happens to us all! Glad you are back on track.
As Phil mentioned, it happens
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?
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?
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.
Check the sample app โParent Workflowโ from @Aleksi โs portfolio here - www.appsheet.com/portfolio/531778
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)
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:
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!!
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.
@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.
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.
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.
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.
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.
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โ.
User | Count |
---|---|
18 | |
9 | |
8 | |
5 | |
5 |