Managing Public SharePoint Documents for Power Apps Portal and Internal Documents Using Cloud Flow (Part 8 of 8)
This is the eighth post in a series of Automating SharePoint Integration with
Dataverse using Power Automate. You can check out the other posts via these
links (Part 1,
Part 2,
Part 3,
Part 4,
Part 5,
Part 6,
Part 7)
Power Apps portal has the
capability to upload and display documents to and from SharePoint
directly to the Document Library related to a record. But sometimes, there is
a requirement to manage two types of documents, one for the public documents
visible to the portal user and the private documents which are supposed to be
visible only for the internal Dynamics 365/Power Apps users. This can be
achieved by uploading the public documents for the portal user to the
Document Location which is created first and the private documents for
the internal users can be uploaded to the second Document Location.
(Special thanks to Gus Gonzalez
for sharing this solution by
Nicholas Hayduk.)
We can automate this solution by automatically creating the x2
Document Locations with a cloud flow as soon as the record is created.
In the Part 1 post, I have explained how to automatically create SharePoint
Document Location OnCreate of the record. This is the extension the
previous solution with the additional steps to create the second
Document Location.
These are all the steps included in the cloud flow for this solution. The
following cloud flow is triggered on create of the Contact and creates the
public Document Location for the portal user as in
the Part 1 post and then, creates the private Document Location for the internal users.
The first part of the cloud flow is almost the same as the the Part 1 post except the SharePoint folder path and Relative URL with
"_Public" postfix (as highlighted in the screenshot above).
The user can see the documents from both location by manually selecting "All
Locations" from the Document Location menu but that selection cannot be
default. When the internal user opens the Documents tab, the
Document Location in the first menu item is shown (e.g. Private
Documents in this case when the Document Location name is sorted
alphabetically).
Summary
When the SharePoint integration from Power Apps portals is enabled,
the users can see all the SharePoint documents related to the record
but we can upload the documents for internal purpose to the
secondary Document Location and keep those hidden from
the Portal user.
I am following almost the same steps in our application and came across to issues (bugs ? )
ReplyDelete1. The Automatic Integration kicks in and creates an additional location sometimes (so there are 2 document locations on Power apps, bot pointing to same Sharepoint folder)
2. The Location based on Default Site does not always come as default on the powr apps form (i.e. Sometimes Internal location is loaded by default and sometimes Non Default comes as default).
What we observed is that whichever location is "Modified" later, comes on the top as default.
MS Identified 2nd as "By Design"
Hi Swapnil Kocheta
DeleteWhen you mentioned "Power Apps form", does it mean the "model-driven app form"? For the Documents tab in the "model-driven app form", I believe the Document Location is sorted by "modifiedon desc" (probably "by design" as MS mentioned)
As a workaround, what you can do is create a cloud flow which triggers on create of the Document Location. And if the Document Location is the additional location created by the Automatic Integration (and not the Location based on Default Site), the cloud flow can find the Location based on Default Site for the same Regarding record and do a dummy update just to change the "Modified On" as the latest value.
What would you recommend for a scenario that requires 3 levels of document locations/permission needs for something like this?
ReplyDelete1. Documents that are visible to the contact record that is logged into the portal
2. Documents that are visible to the parent of the contact record but not the contact record
3. Documents that are only visible to internal users of the system