This is now a thing and it works. But it also is klunky as it is still in pre-release and we've seen things disappear previously that worked reasonably well (i.e. classic datatable control). But I did configure this and it works after a few key things that aren't well documented. So follow along and this might get you past a very basic roadblock
I do this so often that I never considered this to be something I would write up, but I had a question on it last week so I felt maybe I should at least explain the Q&D on how to make this work reliably with minimal hassle.
When you are doing certain applications it occasionally requires more elaborate security settings that lock down the data by row versus by list or site. This walks through one of the simplest ways to complete the task with minimal risk.
So I have done a lot of document processing and merging processes for our HR team recently. It applies to many teams who have default documents they want to do "something" with that can be dynamic. Documents like invoices, estimates, part lists, etc.
In many cases, you don't control the documents or the business wants some ability to manage these on their own. This leads to inevitable problems w/ typos, errors, etc. that can come up. Therefore, you wind up doing some troubleshooting on individual documents much more than you might like. This led me to building out a larger solution for managing documents as part of some processes. Parts of which I'll share below.
So, as the Generative Pages marketing push and dollars spill out into the hot little hands of the various Microsoft Consultants out there who don't work for Microsoft but become their mouthpieces. This is all so very tiring.
A coworker sent me over this today and...yeah...this is pure Microsoft Fan Fiction.
The PowerApps platform as a whole does a reasonable job w/ sharing of applications and restricts things down to a degree that I'm mostly happy about. However, there are exceptions to this rule and sometimes it is easier to share applications with the entire organization and then trim down from there.
Sometimes it is also helpful to make the approval process a little more "business friendly" for allowing people to have access to the application vs. training them on anything relating to the Power Platform as a whole.
This walks through an example of how to set up an app where you can share it with your entire organization and then trim down from there. The entire thing is managed from several SharePoint lists or honestly, whatever you decide to do within your Power Automate script to assess if someone's allowed to use the app or not.
NOTE: If you do this for an app that has PREMIUM connectors, then this would require users to have such licenses even to determine that they cannot use the app.
Soooo, Reza just published out this: https://www.youtube.com/watch?v=CVjh8uaNCNI
If you haven't watched it, go ahead and then come back. It's an overview of the upcoming "Generative Pages" feature that will use AI to build out actual pages within a Model app for you. It literally builds out all the React code to create the web pages to alter the interactions within Model Apps for PowerApps.
That last sentence might start some of you already scratching your head, but this is a much deeper question of the future of this platform than just: do I now need to learn React? No. You don't. At least not yet unless you're bored.
If you are a developer and are thinking about how powerful/efficient these tools will make you, then it is important to understand that this specific tech is intended to replace the need for you, not to make you more powerful. YMMV
Adoption of this path leads to a near-term impact most likely resulting in reduced employee salaries and paths for advancement for anyone currently utilizing the platform for non-Model applications, increased spend/opportunities for contractors and consultants using this approach.
NOTE: I will update this article probably several times as I learn more about this since this is all in pre-release right now. But I doubt my general perception of this will change.
NOTE: While is is about Generative Pages, most of the same problems apply to "Code Apps" that are the ability to connect your own non-Power Platform code into the platform in some ways. The licensing, design, and complexity issues all exist in that same scenario. Plus, you probably generated your code w/ AI anyway so it's essentially 100% the same problem.
Several years ago I had a very enthusiastic person join our organization. He clearly had incredible intelligence, drive, and an almost manic need to learn/apply technology. The more I was willing to share, the more he would consume my time. While this can always be a problem when done to excess, he also was very aware and very thankful of me allowing him to consume my time/knowledge when I had availability.
He passed away just over a year ago in his 30's. Cancer. Brutal, sudden, and without notice. I only became aware of it because I had emailed and texted him a few times over several months and finally his mother answered a text and informed me.
EJ posted a comment here on my blog two years ago. I had this comment in my moderation folder for years and finally just let it through. It of course has his personal email and such (which is why I didn't share it originally), but something about that message sitting in my inbox for all these years kept nagging at me and I finally published it.
When attempting to access large datasets from Power Apps and sometimes querying APIs or Power Automate queries to retrieve information concurrently, it is helpful to use the Concurrent() function to retrieve multiple items at the same time. However, Concurrent() cannot exist within a ForAll() and when processing groups of items it may be required to chunk them up to avoid overloading a datasource (can you really query 1000 rows simultaneously from Excel or your APIs without breaking something?)
This post walks through how to process chunks of data simultaneously while also giving a nod to the limitations of certain back-office platforms.
In my own scenario, this process is querying either an API (if it is working) or an Excel export from the same ERP. As we have ~45,000 records in one of those Excel files and roughly ~200,000 in another, these queries can take up to 30 seconds to retrieve a value from one of those files per user. So splitting up these tasks to take place concurrently is essential.
There are of course many ways to approach how to detect if somebody changed a value in a field and set a flag to know if something needs to be "saved". However, it can get complex if you are doing this for many MANY fields or also for a gallery of items where changes could be made to many of them at once.
This is an example of several ways to approach the problem so you can have some standardized code to make updates back to your datasource much easier and more efficient (and not throw errors).
