Immovable object meets irresistible force. In other words, business requirements meet IT Department policies. I want to discuss this law of technology in the context of custom SharePoint list forms using PowerApps.
Background
A business unit is using a SharePoint list to capture information from departments across the globe. The data elements are quite voluminous (over 25 fields) and there is some value-dependent validation required during entry. To ensure that users follow the rules, the business unit would like to customize the SharePoint list forms with PowerApps. (Plus, the project owner wants to make the data entry easier than the built-in list forms in the hope of reducing user friction.) These requirements are very common.
On the other hand, the IT Department knows that they will eventually be tasked with maintaining the PowerApp form. Whether it is advanced techniques for performing validation, creating connections to back-end systems, or even writing custom connectors; IT is convinced they will be involved and they want their long-standing quality control procedures to apply. PowerApps does support multiple environments for Dev/Test/Prod, but apps created to extend SharePoint lists do you use those environments.
A possible solution
To meet these conflicting requirements, I recently built a combination of PowerApps. The first was a stand-alone app which is in the Dev environment. This app has all the business requirements included and can be exported and imported as necessary by IT Admins.
Specifically, the app has a search/review form, in which a user can identify an item to edit. A typical gallery-based form in PowerApps. Selecting an item navigates to a detail form, with controls for each column and validation/update logic. (I didn't use a PowerApp form control because the requirements call for a more complex display of information than the wizard supports.)
I extended the browse screen with a Timer control. The timer is configured with a Duration property of 1000 (one second) and the Auto start property is true. The OnTimerEnd property uses the Param function to read a parameter that is passed to the app. (In this scenario, I'm using the Timer control like a document.ready() event.) This parameter is expected to be a list item id, and if present, the function navigates to the detail form.
If(
!IsBlank(Param("itemId")),
If(
IsNumeric(Param("itemId")),
Navigate(Edit,ScreenTransition.None,{ ctxItemId: Value(Param("itemId")) })
)
)
With the stand-alone app updated to process a parameter, the list-based app can be updated to pass the current item id as a parameter. First, I deleted the generated form, and all the events on the SharePointIntegration connector. Then, I added a label to tell the user what is happening:
Next, I'm using a label control to ensure that a list item id is passed, and the id is numeric. I used the label to visualize the value of the SharePointIntegration connector, and then changed the label to Visible=false. It is not strictly necessary. (If the item id is not valid, I'm defaulting to the first item in the list. You should use an appropriate default for your scenario.) The Text property of the label:
If(
IsBlank(SharePointIntegration.Selected) || IsEmpty(SharePointIntegration.Selected),
Text(First(InputList).ID),
Text(SharePointIntegration.Selected.ID)
)
Then, a Timer control on the form (to ensure everything is loaded) uses the Launch function to open the stand-alone app. (There is a second "overload" of the Launch function that takes the app id to launch instead of a web address. Do not use it! This technique only works with a web address.)
Launch("https://web.powerapps.com/apps/19c2557b-c5e7-4dcd-wxyz-18da05da8820?itemId=" & Label1.Text)
Summary
We have a compromise that works for all. The business is assured that users will update data using the PowerApp, with its validation rules and IT can implement its QA policies on environments. There is an added benefit that the end-users can even use the stand-alone PowerApp directly if the wish for an immersive experience.
Notes:
- The Launch function will attempt to open a new tab/window. A browser pop-up blocker will cause the operation to fail.
- I did not test on mobile. While the stand-alone PowerApp should work fine on mobile, I don't know if the Launch function works inside the SharePoint/PowerApp mobile versions.