Power Community

Power Community

Upcoming deprecations in Power Apps portals

Headshot of article author Nagesh Bhat

This is an exciting time for Power Apps portals customers with lots of new capabilities being released and especially the announcement of Power Pages. 
However, this is also the time, when we look at our current platform capabilities and find optimizations which helps us keep moving in the direction of security, simplicity and modernization. In order to achieve that, we will be deprecating few existing functionality in lieu of their modern equivalent. From June 2022, features listed below will be considered deprecated.
One important thing to note here is that deprecation doesn’t mean that features would be immediately removed and will stop working, these fetaures will continue working and would be removed at a future date which is specified in Important upcoming changes and deprecations in Power Apps portals. However, we do encourage customers to migrate to the modern equiavelnt of these features as soon as possible to leverage Power Apps portals platform in the best way possible.

Following are the features which will be deprecated starting June 2022 –

  1. Changes to OAuth 2.0 implicit grant flow 2.0 -> This feature allows developers to integrate external API with your Portal by securing these API calls through a OAuth token for the logged in user. More details about how this feature works can be found here. As part of the upcoming changes, we are making few changes to this functionality to make it more secure and simple to use
    • Deprecation of GET method to connect to token endpoint -> After this change, developers would be required to use POST method to get the auth token from token endpoint. This change makes this functionality more secure as POST method is better secured against CORS and CSRF functionality.
    • Deprecation of authorize endpoint -> After this change, authorize endpoint would be removed and only token endpoint would be supported.
    • Default certificate for signing the auth token  -> Currently as part of this functionality, all the auth tokens are signed using default certificate provided by Microsoft. As part of this change, developers would be required to use their own certificate which will then be used to sign the auth token. This will allow developers to align to the certificate lifetime and rotation policies of their organization.
    • More details about these changes along with their removal date can be found here. 
  2. Entity List OData Feed Option -> When Odata feed enabled on website you can interact with table data via Restful webservice. However, the existing Odata feeds are based on odata 3.0 which is obsolete and offers limited functionality. With the launch of Power Apps portal Web API to interact with table data, we will be retiring entity list odata feed option. More details about these changes along with their removal date can be found here. 
  3. Portals Runtime content editor ->  Users with suitable permissions can add, modify, or delete webpages and their content using portal runtime content editor.  This functionality has existed since very first version of Portals. However, with the launch of Power Apps portals design studio and most recently Power Pages Design studio, we have moved towards a better cohesive design experience for creating Portal content. More details about these changes along with their removal date can be found here. 
  4. Yahoo auth provider support -> Power apps portals supports variety of  commercial auth providers like Microsoft accounts, Google, Facebook, Linkedin etc. However, based on the provider usage and some significant changes to Yahoo auth provider, we will be discontinuing the support for Yahoo auth provider from Power Apps portals. Customers will still be able to use other auth providers as it is.
  5. Lucene.net based Search -> Power Apps Portals provides a global search functionality based on a custom implementation of lucene.net which allows users to search within OOB and custom dataverse tables. However, this search comes with limited functionality and intelligence capabilities which modern websites demand. To support this, we had launched Dataverse search support for Power Apps portals sometime back which is generally available now. Dataverse search provides all the capabilities of current global search and augments it with new intelligent search capabilities as well. Hence, we are deprecating our current search capabilities and would be completely standardizing Portals global search on Dataverse search. More details about these changes along with their removal date can be found here. 
- Advertisement -spot_img

LEAVE A REPLY

Please enter your comment!
Please enter your name here

- Advertisement -spot_img
- Advertisement - Advertisement

Latest News

Power Fx: Error handling graduates to preview

We are thrilled to announce that the long-time experimental feature Formula-level error handling has moved forward to preview. As a result, you and your end users will enjoy higher reliability and more transparency about what is happening in your apps. It’s a huge step. Adding error handling to an existing language turned out to be a very tall order, touching almost everything, from data types, to functions, to the runtime. Thank you for all of your support, feedback, and patience as we got this done. What does it mean for you? Your apps will more reliably detect and report errors.You can write blank/null values to a database.You can detect and replace errors with the IsError, IsErrorOrBlank, and IfError functions.You can control error reporting and logging at a central location with App.OnError.You can create and throw your own custom errors with the Error function. Error handling is a big change in behavior. By entering preview, we are signaling that we believe we are done, that we anticipate no further significant changes from here. Many of you already use error handling in production and this move to preview should only embolden more of you to do so. If significant changes are needed from here, we will treat them as a separate feature. We are rolling this out slowly as it is such a big change. All of you will soon see that the Formula-level error handling switch has moved from experimental to preview in the settings (as of version 3.22082). It will still be default to off for most tenants. Over the coming weeks we will slowly change the default for new apps only to on across the tenants. Makers can still disable this feature and will be able to do so for a long time. I say again: we are changing the default for new apps only. Existing apps will continue running as they always have. We have no plans at this time to turn this on for existing apps, and as this is such a big change, we may never do this and make this a permanently available switch. Your feedback will guide us. The documentation for Error, IfError, IsError, IsErrorOrBlank functions and the App.OnError property covers these changes. IfError and IsError are very similar to their Excel counterparts. We are also working on overview docs that will be released shortly. But before that, let’s take a brief tour. Let’s start with what Excel does, the inspiration for Power Fx. For an error like division by zero, Excel is very clear that something has gone wrong with a # error message that shows right in the cell. This error will propagate to other cell formulas if A1 is used in a formula: Today, without error handling, Power Apps won’t report anything in this scenario, instead treating the division by zero error as a blank value. That’s not good, as the maker and the end user of the app have no idea something may have gone wrong: Errors happen. Unexpected data flows in, networks go down, storage fills up, to name just a few situations that an app may encounter in the real world. Makers don’t often think through all the ways that things can go sideways which makes default error handling even more important. Returning a blank for an error is also a problem because blank is a legitimate value in our type system and in many databases. Without error handling, Power Apps won’t allow you to write a blank to a database instead thinking it is an error. So, instead of returning an easy to ignore or misinterpret blank value, with error handling turned on we now report an error to the end user (the error banner) and show the formula as having an error to the maker (the red filled in circle on the control): Further, if you look at the value of the formula, it is not a blank but an error value. Just as any formula can result in a blank, now any formula can also result in an error: Now, we still aren’t showing an error in the label control itself as Excel does. We couldn’t do this generically because, unlike Excel, the error could be on a property of a control for which there is no way to display the error. For example, where should an error on a slider control? Where should an error be shown for an imperative operation in the middle of a button’s OnSelect formula? We settled on showing the end user banner and flagging the control in the design experience. That’s not to say you can’t detect and display an error in that label control. Error handling provides a wealth of mechanisms to control how errors are handled and reported. For example in this case, we can wrap the division by zero with an IfError function to return a custom message in the label: The Text function call is required for type compatibility. Or we can use IfError to throw a different, more specific error with the Error function: Or we can have a catchall for all errors in the app with App.OnError. For example, we can log the error and present a different message to the end user: If we look at the log, we see the details of the captured error from FirstError (and there is also an AllErrors), including where it happened and when it was detected: The possibilities are endless! You now have all the tools you need to detect, replace, report, and log errors, including a good default behavior if you never take advantage of these tools. And, bonus, you can also now write blank (or null) values to databases. Please let us know what you think in the Power Apps community forum. There is a dedicated and active space for error handling discussions at Error Handling – Power Platform Community (microsoft.com).

More Articles Like This

- Advertisement -spot_img