Hi Shane, You miss One Big Issue in your PowerAutomate Upadte Step. In this Sharepoint list you have two columns with Default Value, one is Choice column (Project Type) and second is Yes/No column (Was this a referral?). When you updated records you want only to update the "Who send..." but probably you also update those two columns by default value of those fields.
That's why I can't wait to sign up for your paid services Shane. You're such a nice person and it would be my pleasure to not only learn more from you but to support such a nice person. ;) Soon!@@ShanesCows
Hi Shane, working on Production data is unnerving. I don't know about SharePoint lists or Dataverse, but with normal databases, I would start with getting downtime on the Production database so I can take a clean backup. Then, I would proceed with your steps. If I mess up, I can always go back to where I was before I started and I don't have people working on the database as I am trying to fix things. I, therefore, never feel nervous working on Production data. Oh, I almost forgot, YOU MUST test doing backups, recoveries and validations before attempting these kinds of maneuvers.
Thank you so much for this great video. The pagination is also essential when using excel as a data source (NB: though excel as a data source is not advisable)
Hey Shane - you'll actually get much better performance and not suffer from the time it takes to do a patch with a ForAll if you use the ForAll as it was designed - as a table creating function. You're trying to use it like a For Loop in some development language (which PowerApps is not). When you try to do a patch in a backward ForAll, it will have to instantiate each patch action over and over and it will be miserable. The Patch function takes an entire table as a parameter, so if you use the ForAll like it was designed (as a function to return a table) and supply that as your second parameter to the patch, then Patch will only need to instantiate once and it will then take the entire table and make the updates: Patch('Leads List', ForAll('Leads List', {ID: ID, 'Who sent the quote / SOW and is responsible for follow up?': {Value: Trim('Who sent the quote / SOW and is responsible for follow up?'.Value)} } ) ) This will execute hundreds of times faster. In the above the ForAll is used properly to generate a table of records. Those records contain the ID (primary key) and the column value wanted. That table is provided to Patch which will instantiate once and then iterate on the provided change table. Also to emphasize this, remember that the Patch function returns a record - it has to get that record each time. If you instantiate it over and over in a backward ForAll, then it will not only suffer the performance of doing that, but it will use the return record as part of the ForAll table creation - which is then wasted if used by itself backward. So, using backward not only is poor performance, but also consumes memory during the creation process that is then discarded. Just thought I would mention as it is all too common to see the ForAll used backward and people end up hating it because it performs so poorly as a For Loop...well, it wasn't make to be that, so when used right, it is one of the more powerful functions in the PowerApp platform.
What about performance of such structure? ClearCollect(colSPData, SPData); UpdateIf(colSPData, Condition, {ModifiedField: ModifiedValue}); Patch(SPData, colSPData);
Hi Shane, thanks for sharing your way of solving it. When I was thinking about it, I would probably do one step more - I would try to filter data, so that I update only wrong ones, both in Power Apps and in Power Automate. If the odata query ignores the empty space, I would use Select and Filter actions to filter it out (if it's possible). I was surprised when I saw that Power App Filter ignored the empty space, but it could be filtered from gallery later I guess. I hope you could fix those overridden fields by Power Automate. That is another topic and I guess a bit more complex.
I don't think I have done one on the Operator. The idea is it lets you name the table you are looping through. docs.microsoft.com/en-us/power-apps/maker/canvas-apps/functions/operators#thisitem-thisrecord-and-as-operators
Thank you. I like the way you thought through the process twin 14:17 and 17:07 vis a vis option for forAll that become available on the basis of a carefully matched collection and the pros and cons that come with that. Looking forward to the next segment of video’s power automate work around as it perhaps will indeed be just the step I need right now to solve an update problem at work.
I appreciate the work Shane did in putting together this video. However, a product intended for use by citizen developers should make it as easy as possible to do basic things like updating records. The PowerApps syntax should be something like "Update Tablename Itemname = Trim(Itemname)". Just my two cents.
And if you need to routinely update something like 10,000 or more records, then you can check out SharePoint batch updates in Power Automate: ruclips.net/video/l0NuYtXdcrQ/видео.html
Hi Shane, You miss One Big Issue in your PowerAutomate Upadte Step. In this Sharepoint list you have two columns with Default Value, one is Choice column (Project Type) and second is Yes/No column (Was this a referral?). When you updated records you want only to update the "Who send..." but probably you also update those two columns by default value of those fields.
Came to say the same but you beat me to it! This got me in trouble very early in my career, and it only takes once...
Well isn't that interesting. I was so focused on the video I didn't think about the other fields. You are correct. Thanks for sharing!
Shane, you always manage to make this stuff so easy to understand. Thanks again and great info.
My pleasure!
That's why I can't wait to sign up for your paid services Shane. You're such a nice person and it would be my pleasure to not only learn more from you but to support such a nice person. ;) Soon!@@ShanesCows
This is literally the exact business problem that I need to solve and have been dithering on. It's like mana from heaven!
Glad to help.
Hi Shane, working on Production data is unnerving. I don't know about SharePoint lists or Dataverse, but with normal databases, I would start with getting downtime on the Production database so I can take a clean backup. Then, I would proceed with your steps. If I mess up, I can always go back to where I was before I started and I don't have people working on the database as I am trying to fix things. I, therefore, never feel nervous working on Production data. Oh, I almost forgot, YOU MUST test doing backups, recoveries and validations before attempting these kinds of maneuvers.
Thank you so much for this great video. The pagination is also essential when using excel as a data source (NB: though excel as a data source is not advisable)
Hey Shane - you'll actually get much better performance and not suffer from the time it takes to do a patch with a ForAll if you use the ForAll as it was designed - as a table creating function. You're trying to use it like a For Loop in some development language (which PowerApps is not). When you try to do a patch in a backward ForAll, it will have to instantiate each patch action over and over and it will be miserable. The Patch function takes an entire table as a parameter, so if you use the ForAll like it was designed (as a function to return a table) and supply that as your second parameter to the patch, then Patch will only need to instantiate once and it will then take the entire table and make the updates:
Patch('Leads List', ForAll('Leads List', {ID: ID, 'Who sent the quote / SOW and is responsible for follow up?': {Value: Trim('Who sent the quote / SOW and is responsible for follow up?'.Value)} } ) )
This will execute hundreds of times faster. In the above the ForAll is used properly to generate a table of records. Those records contain the ID (primary key) and the column value wanted. That table is provided to Patch which will instantiate once and then iterate on the provided change table.
Also to emphasize this, remember that the Patch function returns a record - it has to get that record each time. If you instantiate it over and over in a backward ForAll, then it will not only suffer the performance of doing that, but it will use the return record as part of the ForAll table creation - which is then wasted if used by itself backward. So, using backward not only is poor performance, but also consumes memory during the creation process that is then discarded.
Just thought I would mention as it is all too common to see the ForAll used backward and people end up hating it because it performs so poorly as a For Loop...well, it wasn't make to be that, so when used right, it is one of the more powerful functions in the PowerApp platform.
What about performance of such structure?
ClearCollect(colSPData, SPData);
UpdateIf(colSPData, Condition, {ModifiedField: ModifiedValue});
Patch(SPData, colSPData);
Hi Shane, thanks for sharing your way of solving it. When I was thinking about it, I would probably do one step more - I would try to filter data, so that I update only wrong ones, both in Power Apps and in Power Automate. If the odata query ignores the empty space, I would use Select and Filter actions to filter it out (if it's possible). I was surprised when I saw that Power App Filter ignored the empty space, but it could be filtered from gallery later I guess.
I hope you could fix those overridden fields by Power Automate. That is another topic and I guess a bit more complex.
Pls, is there a video link for any teaching on the As function? (As SPDATA etc as per 13:14 minute part of this video?) Thx!
I don't think I have done one on the Operator. The idea is it lets you name the table you are looping through. docs.microsoft.com/en-us/power-apps/maker/canvas-apps/functions/operators#thisitem-thisrecord-and-as-operators
Thank you. I like the way you thought through the process twin 14:17 and 17:07 vis a vis option for forAll that become available on the basis of a carefully matched collection and the pros and cons that come with that. Looking forward to the next segment of video’s power automate work around as it perhaps will indeed be just the step I need right now to solve an update problem at work.
I appreciate the work Shane did in putting together this video. However, a product intended for use by citizen developers should make it as easy as possible to do basic things like updating records. The PowerApps syntax should be something like "Update Tablename Itemname = Trim(Itemname)". Just my two cents.
And if you need to routinely update something like 10,000 or more records, then you can check out SharePoint batch updates in Power Automate:
ruclips.net/video/l0NuYtXdcrQ/видео.html
Nice job!