InfoPath Dev

Link to webinar here: https://www.youtube.com/watch?v=drewttus35Q

Hi, this is a question for @Hilary Stoupa, but if anyone has a solution I would greatly appreciate some feedback! I've been following the parent/child webinar quite closely to set up a enquiry/quote app for our sales team. An enquiry is logged, and quotes are made against those enquiries as they come in. Everything runs from SharePoint lists. Everything works wonderfully except for a couple of key things:

1: When submitting an enquiry (parent) without any quotes (children) the app will fail to fall back to the detailscreen, instead saving data and staying in the editscreen. This doesn't happen if there is a child attached. This isn't game-breaking exactly, but I can see it being a nuisance in future and would like to figure it out before I release this into the wild.

Formula for the confirm button is:
Set(SubmitDateTime, Now());SubmitForm(EditForm1);If(CountRows(Filter(QuoteCollection, SAR_ID = 0)) > 0, UpdateIf(QuoteCollection, !IsEmpty(EditForm1.LastSubmit.ID), {SAR_ID: EditForm1.LastSubmit.ID})); Patch('Sales Quotes', QuoteCollection); Clear(QuoteCollection); If(EditForm1.Mode= New, Navigate(BrowseScreen1, ScreenTransition.None), Navigate(DetailScreen1, ScreenTransition.None))

It may be worth noting that after attempting to submit a form with no quotes, the Patch('Sales Quotes', QuoteCollection) section underlines red with the error "Modified: The specified column is read-only and can't be modified".

2. This is a little more damaging. Adding quotes (children) is fine and dandy, works a treat. Unfortunately, if I edit a quote and submit that, rather than editing the quote it will create a new one, leaving the "edited" child in there.

The formula for the submit button on the EditQuote screen is:
Collect(QuoteCollection, EditForm2.Updates); ResetForm(EditForm2);Navigate(EditScreen1, ScreenTransition.None)

I am a huge fan of your video webinars and have learnt a great deal from them, thank you very much for making them.


Kind regards
Chris

Hey, Chris - glad the webinars have been helpful. I just noticed this question, and I'll take a look a little later today & see if I can be of any assistance. :)

Thanks Hilary! I appreciate you looking into it for me. I can't seem to wrap my head around the problem.

 So - it's been a year since I did that webinar, and it isn't terribly fresh in my mind - but here are a few thoughts.

1. Since the parent submit is a form, I'd probably take everything after SubmitForm(EditForm1) and move it to the OnSuccess property of EditForm1 - that way those actions only run if the form successfully submits. Then you don't have to check if the LastSubmit.ID is empty, which will simplify things a bit. I'd guess after submit, the EditForm Mode may be reset, so you might want to instead create a variable to track which screen the user arrived from and just leverage that for your navigation. https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/functions/function-form says that on successful form submit "If the form was in FormMode.New mode, it is returned to FormMode.Edit mode."
2. I'm wondering if you may want to put your Patch in an if so you don't patch if the Quote Collection is empty?
3. For the child quote edits - is the quote already in the quote collection? I'd guess you want an UpdateIf here too, right? So that you are updating the child in the quote collection, and when you patch, that is only in the collection one time?
4. You can see what all is in your collection in the web designer, under File > Collections - this usually helps me debug.

Hope this helps & let me know if something doesn't make sense...

Hi Hilary,

I only had time last week to do the most basic thing. I feel very stupid. Turns out the OnSuccess bit had back() in there, so it would complete, finish the checkmark button's command, then go back to where it was. So that's fixed now.

I didn't have to do much except put the whole lot into the OnSuccess part, which is easy and I'm happy with that.

Now I'm just having trouble with editing things in the collection saving whole new records instead of modifying existing ones. I found a few people with the same issue online but I don't think I understand Patch/Collections enough to properly wrap my head around it. Some more theory for me, I think.


Thanks again, Hilary. You've been a huge help here and in your seminars.

Brief update on this.

I've managed to resolve all the issues I was having, your input has been invaluable in getting me there. Thanks so much for popping in and giving me that advice, Hilary.

I'm not sure if these threads need closing when everything is resolved, but now would be a fantastic time to do that!

I'm glad to hear this is resolved - do you mind recapping the issue you were having with dupes being created?

I actually ended up removing the collection and patch stuff which I think was causing me some trouble, as I was getting that red underline that we've all come to know and love. The system I was building didn't necessarily require that the quotes created and edited weren't saved when the form wasn't, which was the big reason for using that method I assume.

Instead I used an embedded editform without any special effects that when creating a new quote would, by default, set the Enquiry_ID column to the saved enquiry_id variable that was created when the enquiry was opened, creating that parent/child relationship. The view form on the details screen is still filtering the same stuff as before, but instead of looking in a collection, it's searching a data source. I've never seen a single enquiry gather more than 10 quotes, so this won't be a problem in future (delegation limits, etc!). Changing to this method of doing things was mostly because my understanding of these systems are miles ahead of collections and patching!

It's something I'd like to go back to one day as I can 100% see the merits of using collections instead of several forms linking straight to data, but for now things seem to be working and I reckon the system as it is now has at least a couple of years in it, plenty of time to get my head around it all.

Makes sense - yah, I go back and forth on the right approach. In general, I love the simplicity of using forms, and would rather just use those. I'm always concerned about user intent tho - if I hit cancel at the parent level, I'd expect my child changes to be cancelled as well! But if the simpler approach is going to work for your users, I'm all for it. :-)