Вернуться   AXForum > Microsoft Dynamics CRM > Dynamics CRM: Blogs
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

Опции темы Поиск в этой теме Опции просмотра
Старый 17.02.2021, 15:12   #1  
Blog bot is offline
Blog bot
25,526 / 847 (80) +++++++
Регистрация: 28.10.2006
crmtipoftheday: Tip #1402: Why you should not use Microsoft Lists/SharePoint Lists for business-critical Power Apps

SharePoint lists (and now Microsoft Lists) is an easy way to quickly create lists of data for use in a Power App. Makers can quickly create lists, add fields, and populate data for canvas apps.

However, not all apps are equal from a complexity perspective.

If the app is simple and contains data that is not sensitive, Microsoft Lists can be a good choice for data storage for canvas apps.

However, if your app contains many different lists, large amounts of data, complex relationships between tables, and sensitive data for which all of the users of your ap should not have access, then you should consider using alternative data sources for you canvas app.

Here are the top 5 reasons why you should not use SharePoint lists for high-criticality Power Apps:
  1. It is not a relational database. Each list is independent and SharePoint lists were never intended to be used as a relational database. While SharePoint does have a field type called Lookup, it does not serve as a true relational database. Lookup fields in SharePoint lists are very difficult to work with in canvas apps, and performance with many lists in the same app will be slower than if you have a true relational database.
  2. Common formulas are not delegatable to Sharepoint: With canvas apps, heavy processing of data is delegated to the data connection. Common functions like if, Collect/ClearCollect are not delegatable in Sharepoint, while they are in other data sources like Dataverse. This means that if you need to return more than 500-2,000 records at a time, it is very difficult to do so with Sharepoint lists. With other connections like Microsoft Dataverse, Collect is delegatable, allowing for a much higher number of records.
  3. Security: if you share an app built on SharePoint with a user, you also need to share the underlying lists with them. This means if the user should not be able to see all of the records in the table (or update all of the records in the table), they could open up the underlying list and view or modify any of the records, even if you are obscuring the records inside of your app. Sure you can hide the list, but obscurity != security.
  4. SharePoint lists have limits in how they can be filtered in Power Apps: for example, filtering on yes/no fields does not work. Microsoft Dataverse based apps support complex filtering via views, which can include multiple tables.
  5. If your app exceeds the capabilities of SharePoint Lists, you need to start over—many apps begin as personal productivity but over time become more critical to an organization. Before you build your app, think through the potential roadmap—if there is a potential that it will increase in data, security sensitivity, or number of users in the future, build it on something other than SharePoint lists.
What is the alternative?

If you want to start with the benefits and ease of use of Microsoft lists without having to purchase premium licenses, start with Dataverse for Teams. Dataverse for Teams is included in the standard licensing for Office and Microsoft Teams.

In Microsoft Teams, click Apps and search for Power Apps, then click Open

Click New App

Select the name of the Team where you want the app to be used, then click Create

This will open the Power Apps Studio inside of Microsoft Teams.

Give your app a name

Click Create new table

Give your table a name

Define your columns in a Microsoft List like experience.

Dataverse for teams table creation has all of the things that are great about Microsoft Lists, without the major downsides.
  • It is included in the standard licensing
  • It’s easy to use to create and modify tables
  • It’s a real relational database—if you choose lookup for field type, it creates a real database relationship between the two tables
  • It supports more advanced delegation and filtering.
  • It supports real record ownership and security. You can specify different table permissions for users based on their role in the Team
It supports more advanced filtering via Dataverse views

  • If you exceed the capabilities of Dataverse for Teams you can upgrade your environment to a full Dataverse environment without having to rebuild your app.
Limitations of Dataverse for Teams

Dataverse for Teams environments are limited to 2 GB of data. For larger environments with more complex security requirements, I recommend Microsoft Dataverse. For a full comparison of Dataverse for Teams vs. Dataverse, see Dataverse for Teams vs. Dataverse – Power Apps | Microsoft Docs.

Cover photo by Donald Giannatti on Unsplash.

Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
emeadaxsupport: Translated User Help on TechNet and downloadable New Features lists available! Blog bot DAX Blogs 0 31.01.2013 05:11
crminthefield: Podcast and Overview: Microsoft Dynamics CRM 2011 Update Rollup 11 Blog bot Dynamics CRM: Blogs 0 06.10.2012 05:27
Platform updates overview - 3.70.B - NAV2009 R2 Blog bot Dynamics CRM: Blogs 0 07.02.2011 22:06
CRM DE LA CREME! Configuring Microsoft Dynamics CRM 4.0 for Internet-facing deployment Blog bot Dynamics CRM: Blogs 0 18.08.2009 11:05
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Часовой пояс GMT +3, время: 00:07.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.