web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

News and Announcements icon
Community site session details

Community site session details

Session Id :
Power Platform Community / Forums / Power Apps / Patch Defaults randoml...
Power Apps
Answered

Patch Defaults randomly creates multiple duplicate entries

(0) ShareShare
ReportReport
Posted on by 61

Hello,

 

I have a multi-screen form made into an App to submit vendor data for new vendor creation.

The idea is, at the end of the App, upon hitting submit that a new record is created on SharePoint, containing the request data.

This has ran fine for over 300 instances with colleagues from 12+ countries/regions.

 

The "Submit" button has the following syntax:

 

Notify("Please wait - Do not refresh or click again",NotificationType.Information,2000);
Patch('202201 VMD Proper',
Defaults('202201 VMD Proper'),
'Opening Questions'.Updates,'Conflict Declaration'.Updates,'Company Code Form 1'.Updates,'Generic Vendor Data 1'.Updates,'Bank Data Input 1'.Updates,'Company Code Form 1_1'.Updates,'Registration Details'.Updates,'Purchasing Data 1'.Updates,'Secondary Attachments'.Updates);
Navigate('Closure Screen')

 

No other element anywhere contains a Patch or any other such command. This is the only instance.

 

However, every now and again, this action will result in the creation of multiple instances of the same data. This is completely random both in terms of when it happens as well as how many duplicates are produced. Sometimes it's 2 sometimes 1 and once it even produced 6! duplicates:

metrognome_0-1663764364671.png

Things I have tried:

  • Added the notification you see in the code above, to tell users not to spam-click
  • Added a routine in the "Visible" property of the Submit Button to basically make it invisible for 3 seconds after each press to avoid double clicking.

 

And yet, this latest one with the 6 duplicates still occurred despite all the above and while I was (luckily) watching the process and no multi-clicking or anything else happened.

 

Now, the incidence is very rare (2-3%) so a simple cloud flow to identify and quarantine duplicates limits any operational fallout. But the problem is still there and I can't find an easy way to replicate or troubleshoot. Only to mitigate its effects - which was simple enough.

 

Any ideas?

 

 

P.S. Upon hitting Submit, users are taken to a closure screen with one button to EXIT() the app and one to Make Another Request. The syntax of the OnSelect of the New Request button is as follows (Basically a bunch of ResetForms and NewForms with a Navigate to start at the end):

ResetForm('Opening Questions');ResetForm('Conflict Declaration');ResetForm('Company Code Form 1');ResetForm('Generic Vendor Data 1');ResetForm('Bank Data Input 1');ResetForm('Company Code Form 1_1');ResetForm('Registration Details');ResetForm('Purchasing Data 1');ResetForm('Secondary Attachments');
NewForm('Opening Questions');NewForm('Generic Vendor Data 1');NewForm('Conflict Declaration');NewForm('Company Code Form 1');NewForm('Bank Data Input 1');NewForm('Company Code Form 1_1');NewForm('Registration Details');NewForm('Purchasing Data 1');NewForm('Secondary Attachments'); Navigate('Checklist 1', ScreenTransition.Fade)

 There is nothing else that could possibly interfere with the submission/item creation.

Categories:
I have the same question (0)
  • Verified answer
    AaronKnox Profile Picture
    514 Super User 2024 Season 1 on at

    I've not done a series of .Updates in a Patch so curious if that has something to do with the issue here.  The 'AttachmentsOnlyControlForm'.Updates is a nice pattern I use occasionally when I need to Patch attachments.

     

    Some thoughts:

    The notification or hiding of the button for a few seconds works but I prefer to use a semi-transparent label, lblProcessing, covering the entire screen, placed at the top level of controls for that screen, so when visible all you see is a 'Processing' message: 

    In lblProcessing.Text: 

    locProcessingText

    and in lblProcessing.Visible:

    If(IsBlank(locProcessingText),false,true)

    Then at the beginning of the btnSubmit.OnSelect, add

    UpdateContext({locProcessingText:"Processing..."});

    Likewise, after the Patch, add

    UpdateContext({locProcessingText:""});

    This prevents subsequent clicks, gives the user a bigger indication that something is happening, and if you have a complex patch formula that takes a while or has several stages, you can simply update locProcessing to let the user know things like "Saving to SharePoint..." or "Sending Email...", etc.

     

    Further, you should always add error handling with a Patch.  I have several mobile apps where this is critical and if you allow the user to submit again, after an error, it almost always works a second time.  Putting all this together:

    UpdateContext({locProcessingText:"Please wait - Do not refresh or click again"});
    
    Patch('202201 VMD Proper',
    Defaults('202201 VMD Proper'),
    'Opening Questions'.Updates,'Conflict Declaration'.Updates,'Company Code Form 1'.Updates,'Generic Vendor Data 1'.Updates,'Bank Data Input 1'.Updates,'Company Code Form 1_1'.Updates,'Registration Details'.Updates,'Purchasing Data 1'.Updates,'Secondary Attachments'.Updates);
    
    UpdateContext({locProcessingText:""});
    
    If( 
     // check if there were any errors when the patch was submitted 
     !IsEmpty(Errors('202201 VMD Proper')), 
     // if true, show concatted error messages 
     Notify( 
     Concat(Errors('202201 VMD Proper'), Column&": "&Message), 
     NotificationType.Error 
     ); 
     Navigate('Fail Screen'), 
    
     // else nav to success screen 
     Navigate('Closure Screen') 
    ); 

     

    In the 'Fail Screen' add a label asking them to go back to try to submit again.  Add a 'Back' btnBack.Onselect with Back() so you can reuse this screen for all error handling.

     

     

  • metrognome Profile Picture
    61 on at

    Very very interesting and exactly what I was looking for.

    As you could tell, I was spitballing on how to prevent peeps from click-spamming and this is a way more elegant way to handle it.

    I find the bit about failure mode handling intriguing. I do this in power automate flows all the time but it didn't occur to me to incorporate in the app as I never got any failures in the Analytics section. Furthermore, no user ever flagged a failure when the App took them to the success screen. There are multiple failure modes in earlier steps but all of them prevent progress to submission and the success screen. But then, absence of evidence of failure isn't necessarily absence of failure itself so is there a way to check prior runs or analytics for errors? 

  • AaronKnox Profile Picture
    514 Super User 2024 Season 1 on at

    @metrognome wrote:

    But then, absence of evidence of failure isn't necessarily absence of failure itself so is there a way to check prior runs or analytics for errors? 


    That is a great question and I hope someone chimes in on this topic.  There is the Monitor that you can 'Start a new session' to gather app info.  I believe the Analytics (preview) is only performance and usage metrics, not necessarily error capturing.

  • Verified answer
    RandyHayes Profile Picture
    76,299 Super User 2024 Season 1 on at

    @metrognome 

    In general you can avoid those type of scenarios if you SubmitForm your form instead of using a weaker Patch function on them.

     

    You have NO error checking or success/failure control in your formulas.  The forms automatically provide that ability, but if you use Patch on them, you lose all that functionality.

     

    General rule...if you have a Form, then the only function you should be applying to it is SubmitForm

     

    I would suggest splitting your forms properly so you don't lose the features and functions of the Form.  

    You can learn the process of doing form splitting in this video.

     

    Once you have them set up properly, you can use the OnSuccess action of the master form to determine success and to navigate and perform other actions there.

     

    I hope this is helpful for you.

     

  • metrognome Profile Picture
    61 on at

    Hello and thanks.

     

    This looks a good idea for any new project. This present app though is a form that comprises of 80+ fields which are sometimes populated with items from other lists, subject to complex validations, and even the required or visible fields are not constant but change depending on prior inputs (e.g. if country is in EU, then IBAN is mandatory but if country is US and currency is USD, IBAN becomes non-mandatory and hidden).

    So, while I see the merit in this, it's almost as big a job as re-writing the whole thing.

  • RandyHayes Profile Picture
    76,299 Super User 2024 Season 1 on at

    @metrognome 

    None of what you mentioned is complex for the scenario of doing the forms right and not wasting all the functionality and features of what you use a form for in the first place!!  When you use Patch against the form, it is then just an Input control and will give you nothing else.

     

    The only thing I can suggest is that it is well worth the effort to make the switch.  And, it is MUCH quicker than you think!

     

    It requires a master form with all your fields...that can be any of the forms you already have (if you are working with attachments, then the attachment form should be the master).  So, the change there...adding the fields to the master form.

     

    All of your "sub forms" remain the same.  So - no change in any list populating formulas or validations or visibility of controls.  The only change there is that the sub form gets included in the Item property of the master form.  Pretty simple!

     

    You will gain all of the error handling, form validation, change indication, success/failure handling, and more.  

     

    Your choice obviously, but I can only say - I would do it!!  The use of Patch on Form Updates is just a very bad Pattern as it completely breaks feature and function of the forms that you have made the effort of putting in the app. 

    Unfortunately, there are a lot of "videos" and blogs out there that demonstrate clearly how NOT to do it properly.  It's just not worth wasting the Form - it is one of the most powerful controls in the PowerApps suite of tools!

     

  • metrognome Profile Picture
    61 on at

    Well, I have a copy of the live App in a sandbox and some limited data to play with so I'll give it a go to see.

    Indeed I do have a master form and I actually have a "View" of it across 3 screens (with different visible fields in each screen) which acts like a visual summary of all the data prior to a user pressing submit.

    So I understand using a master form, just haven't mapped in my head how to do the validations, the importing of data from other lists etc.

    Besides, my main issue right now is the random multi-creations and I'm not sure we are too clear on root cause or whether, indeed, this would mitigate for it. Worth a try, for sure.

  • RandyHayes Profile Picture
    76,299 Super User 2024 Season 1 on at

    @metrognome 

    Worth a try for sure!  The video should show the basics of how to do the process.  It is all hinged on a common record variable (in the video - glbCurrentRecord).  

    I can't say for certain your validations because I am not familiar with how you are currently doing them, but they really shouldn't change in any way.  

    If your master form you mention is only a View form, then it will not be much help.  If it is an EditForm in view mode, that is fine.  It will need its mode changed during the process though.

     

    In the meantime, you might also work with disabling the button to submit once you submit if you feel it is being hit multiple times.  Although it could not be during the formula evaluation...so it would have to be happening after the formula is performed.  This can be seeing in your list in that the times are separated by a couple seconds each...a Patch should not take that long, so it would have had to already complete.

     

    AND, since your formula is specifically creating a new record, it will create new records over and over for each press of the button.

     

    Another plus on the split form design - one of the main things that happens in the OnSuccess of the master form submit it that it immediately updates the glbCurrentRecord with the one just submitted...SO, if the user hits the Submit many times, the first will create and any subsequent will just update that record.  No possibility to duplicate new records!

     

    Lots of things to tray and play with!!

     

     

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Season of Sharing Community Challenge Winners!

Congratulations to our community stars!

Kudos to our 2025 Community Spotlight Honorees

Expanding mentorship, skilling, and AI innovation

Congratulations to the June Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > Power Apps

#1
WarrenBelz Profile Picture

WarrenBelz 325 Most Valuable Professional

#2
11manish Profile Picture

11manish 165

#3
MS.Ragavendar Profile Picture

MS.Ragavendar 88 Super User 2026 Season 1

Last 30 days Overall leaderboard