In this episode, we break down the myth that “SharePoint lists are a database for Power Apps” and show why that belief quietly kills performance, scalability, and data integrity. You’ll learn exactly where SharePoint list–backed Power Apps fall apart: delegation limits (500/2,000 record caps), the 5,000-item list view threshold, non-delegable filters, item-level permissions at scale, and complex queries that push all the heavy lifting to the client.

We contrast this with Dataverse as the native data engine for Power Apps: server-side query execution, rich relational modeling, row and field-level security, auditing, better offline behavior, and clean integration with Power BI, Data Lake, and AI workloads. Instead of workarounds, throttled flows, and blue delegation banners, you get reliable performance and honest record counts.

The episode gives IT leaders and makers a decision framework: clear thresholds for when to move from SharePoint to Dataverse (record volumes, compound filters, multiple lookups, granular security), red flags that predict an inevitable rewrite, and a practical migration path covering schema mapping, security design, data loads, flow refactoring, and delegation testing.

If you’re building serious, data-centric Power Apps and want to avoid “free” solutions that become your most expensive line item, this episode shows why choosing Dataverse early is the scalable, governable, and cost-realistic move.

Many users fall for the sharepoint lie that it can seamlessly integrate with Power Apps. This illusion stems from the belief that SharePoint lists can function as robust databases. In reality, SharePoint was designed for collaboration, not for complex data transactions. As a result, you may encounter significant challenges like delegation failures and performance issues when trying to scale applications built on SharePoint lists. Furthermore, the ease of creating apps directly from these lists often misleads users into thinking they can develop effective business solutions independently. This misconception can lead to frustration and a lack of trust in the applications you create.

Key Takeaways

SharePoint is not a robust database. It was designed for collaboration, not complex data transactions.
Expect performance issues when using SharePoint with Power Apps. Limitations on data handling can lead to slow response times.
Beware of delegation warnings in Power Apps. Ignoring them can result in incomplete data retrieval and performance problems.
Consider the hidden costs of SharePoint. Licensing and maintenance fees can add up as your organization grows.
Evaluate your data management needs regularly. This practice helps ensure your applications remain effective as your business evolves.
Explore alternatives like Dataverse for better scalability and performance. Dataverse supports complex data relationships and faster querying.
Implement strong governance practices. Role-based access control and regular audits can enhance data security and integrity.
Stay informed about updates and best practices. Consulting experts can help you keep your apps efficient and secure.

Easy App Creation Myths

Misconceptions About SharePoint

Common Assumptions

Many users believe in the illusion of easy app creation with SharePoint. They often assume that SharePoint can serve as a seamless solution for building Power Apps. This belief stems from the user-friendly interface and the perception that SharePoint lists can function like robust databases. However, this assumption overlooks significant limitations that can hinder your development experience.

Benefit	Description
User-Friendly Interface	Enhances data management by providing a structured way to interact with SharePoint’s data.
Workflow Automation	Streamlines business processes by allowing PowerApps to trigger actions in SharePoint.
Improved User Experience	Offers a single point of access to data and applications, boosting productivity and reducing learning curves.

Realities of SharePoint Limitations

The reality is that SharePoint has inherent limitations that can impact your Power Apps. For instance, users often expect unlimited data handling capabilities. In truth, document libraries impose strict limits on the number of documents you can manage. Additionally, complex structures can lead to performance degradation, which contradicts the initial expectations of smooth app functionality.

PowerApps supports a maximum of 600 requests per minute per user.
There are limits on concurrent calls, capped at 30 per user.

User Experience Challenges

Frustration in Development

When you attempt to build applications using SharePoint, you may encounter various frustrations. The sharepoint lie can lead to a disconnection between your expectations and the actual development experience. You might find yourself grappling with delegation warnings, slow response times, and incomplete data retrieval. These challenges can create a sense of helplessness, making it difficult to trust the applications you develop.

Impact on End Users

The impact of these limitations extends beyond developers. End users often face a subpar user experience when interacting with apps built on SharePoint. Slow load times and incomplete data can lead to frustration and decreased productivity. When users cannot rely on the applications to perform as expected, it undermines their confidence in the tools provided by your organization.

Hidden Costs of SharePoint

Licensing and Subscription Fees

Unexpected Expenses

When you choose SharePoint for your Power Apps, you may encounter unexpected expenses. Many users overlook the costs associated with licensing and subscriptions. While SharePoint may seem like a cost-effective solution at first, the reality can be quite different. You might find yourself paying for additional features or higher-tier plans to access essential functionalities.

Basic Plan Limitations: The basic plan often lacks critical features, forcing you to upgrade.
Add-Ons: You may need to purchase add-ons for enhanced capabilities, which can quickly add up.

Long-term Financial Implications

The long-term financial implications of using SharePoint can be significant. As your organization grows, so do your data needs. You may find that the initial savings you thought you had evaporate as you scale. The hidden costs of SharePoint can include:

Increased Licensing Fees: As your user base expands, your licensing fees will increase.
Training Costs: You may need to invest in training for your team to effectively use SharePoint, adding to your overall expenses.

Maintenance and Support Costs

Resource Allocation

Maintaining a SharePoint environment requires ongoing resource allocation. You must dedicate time and personnel to manage updates, troubleshoot issues, and ensure optimal performance. This commitment can divert resources from other critical projects.

IT Staff Time: Your IT staff may spend significant time managing SharePoint, which could be better spent on strategic initiatives.
External Support: You might need to hire external consultants for specialized support, leading to additional costs.

Technical Debt

Using SharePoint can also lead to technical debt. As you build applications, you may implement quick fixes to work around limitations. These shortcuts can create long-term problems that require more resources to resolve later.

Performance Issues: Over time, these fixes can lead to performance degradation, requiring costly upgrades or migrations.
Complexity: As your applications grow, the complexity can make them harder to maintain, increasing your overall costs.

Delegation Issues in Power Apps

Data Delegation Limits

Understanding Delegation Warnings

When you work with Power Apps and SharePoint, you may encounter delegation warnings. These warnings indicate that your queries may not retrieve all the necessary data. In Power Apps, the default limit for data delegation is set at 500 records, which can be increased to a maximum of 2,000 records. If your query uses nondelegable functions, only the first 500 or 2,000 records are processed. This limitation can lead to incomplete data retrieval from large SharePoint lists.

Tip: Always check for delegation warnings in Power Apps Studio. Ignoring these warnings can lead to performance issues and inaccurate data in your apps.

Workarounds and Their Drawbacks

To address delegation issues, many users implement workarounds. Here are some common strategies:

Always Design for Delegation First
Push Logic to the Data Layer
Validate Delegation Warnings as Governance Requirement
Avoid Local Collections for Large Datasets
Implement Pagination-Friendly Query Design

While these workarounds can help, they often come with drawbacks. For instance, using local collections for large datasets can lead to incomplete data retrieval and incorrect analytics. Additionally, relying on non-delegable functions can result in performance degradation and increased network overhead.

Performance Bottlenecks

Slow App Response Times

As you build applications with SharePoint as a data source, you may notice slow app response times. This issue often arises when dealing with large datasets. When Power Apps reaches delegation limits, it may require additional processing on the client side. This can significantly slow down your application and degrade the user experience.

Performance Bottleneck	Description
Collect / ClearCollect with Filtering	Triggers client-side data retrieval when used improperly with large datasets.
CountRows (in some connectors)	Counting rows locally leads to incorrect totals when datasets exceed delegation limits.
ForAll Over Large Tables	Iterative client-side loops cause performance bottlenecks and partial execution.

User Frustration

The impact of these performance bottlenecks extends to your end users. When they experience slow load times and incomplete data, their frustration grows. This can lead to decreased productivity and a lack of trust in the applications you provide. Users expect reliable performance, and when they encounter issues, it undermines their confidence in your tools.

Note: Always use delegable functions like Filter() and StartsWith() for large lists. This practice helps ensure that your applications perform reliably and efficiently.

When you ignore delegation limits, you risk creating an integration nightmare. Users may miss critical data, leading to incorrect analytics and operational decision inaccuracies. To maintain a positive user experience, prioritize designing your applications with delegation in mind.

Scalability Challenges with SharePoint

Data Volume Limitations

Performance Degradation

SharePoint struggles with large datasets, which can lead to performance degradation. When you exceed the maximum number of items for operations, which is 5,000, you may notice significant slowdowns. This limit can hinder your ability to retrieve and manipulate data efficiently. As your data grows, you might experience longer load times and increased frustration.

Description	Limit
Maximum number of items for operations	5,000

When you reach this threshold, SharePoint may not perform as expected. You could face issues like incomplete data retrieval and slow response times. These challenges can severely impact your user experience, making it difficult to trust the applications you develop.

User Experience Impact

The limitations of SharePoint can lead to a negative user experience. Users expect quick access to data and seamless interactions with applications. However, when performance issues arise, their productivity suffers. Slow applications can frustrate users, causing them to lose confidence in the tools provided by your organization.

Growth Challenges

Adapting to Business Needs

As your organization grows, your data needs will evolve. SharePoint may not adapt well to these changes. You might find that it lacks the flexibility required to handle complex data relationships. This limitation can hinder your ability to scale applications effectively.

When you need to implement new features or expand existing ones, SharePoint's constraints can become apparent. You may find yourself spending more time on workarounds than on actual development. This inefficiency can slow down your response to changing business needs.

Future-proofing Your Apps

To future-proof your applications, consider the scalability of your data management solution. SharePoint may not be the best choice for long-term growth. In contrast, platforms like Dataverse can handle larger datasets and complex queries more efficiently.

Feature	SharePoint	Dataverse
Max List Items	30 million	30 million
Performance Degradation	Beyond 100,000 records	Efficiently handles millions of records
Primary Use Case	Document management & simple lists	Structured relational data
API Request Limits	600 requests per minute	6,000 requests per 5 minutes

When you choose a platform that can grow with your organization, you set yourself up for success. By selecting a solution that meets your current and future data needs, you can avoid the pitfalls of scalability challenges.

Tip: Evaluate your data management needs regularly. This practice helps ensure that your applications remain effective as your organization grows.

Governance Gaps in SharePoint

Compliance and Security Risks

Data Governance Challenges

When using SharePoint for Power Apps, you face significant data governance challenges. Mismatched permissions between Power Apps and SharePoint lists can lead to unauthorized data access. This situation creates legal and regulatory compliance issues, such as data residency violations. You may also experience accidental data leakage due to improper connector usage or weak access controls.

To mitigate these risks, consider implementing role-based access control. Regular permission reviews can help ensure that only authorized users access sensitive data. Establishing Data Loss Prevention (DLP) policies and governance practices is also crucial. Aligning your integrations with industry-specific regulations, such as HIPAA and GDPR, can further enhance your security posture.

Security Vulnerabilities

SharePoint's governance gaps can expose your organization to security vulnerabilities. Without proper oversight, apps may access sensitive data without adequate controls. This lack of oversight increases compliance risks and can lead to potential legal and reputational consequences.

You should implement conditional access policies in Entra ID to secure SharePoint Online. These policies enforce access conditions, such as blocking access from unmanaged devices. By doing so, you can better protect your data and maintain compliance with industry standards.

Lack of Control Over Data

Managing User Access

The lack of control over data in SharePoint can complicate user access management. Overlapping datasets across multiple applications can lead to conflicting information. This situation can create confusion and reduce data accuracy. Additionally, apps may pull from outdated or sensitive data sources, increasing compliance risks.

To improve user access management, ensure that you have clear visibility into app ownership and function. This clarity helps prevent multiple versions of the same solution from existing across teams, which can fracture user experiences.

Data Integrity Concerns

Data integrity is another critical concern when using SharePoint. The absence of robust governance can lead to increased compliance risks when apps access sensitive data without proper controls. You may face challenges in maintaining data accuracy, which can impact decision-making processes.

To address these concerns, establish clear governance practices. Regular audits can help identify and rectify issues related to data integrity. By prioritizing governance, you can enhance the overall reliability of your applications and ensure that your data remains accurate and trustworthy.

Transitioning to Dataverse

Benefits of Dataverse

Enhanced Performance

When you transition to Dataverse, you unlock enhanced performance for your Power Apps. Dataverse provides advanced governance and performance capabilities essential for business-critical applications. Unlike SharePoint, which relies on list-based storage, Dataverse uses true relational data storage. This structure allows for faster querying and better handling of thousands of records.

Feature	Dataverse	SharePoint
Data Storage Type	True relational data storage	List-based storage
Performance for Large Datasets	Optimized for large datasets	Slower performance
Querying Speed	Faster querying	Slower querying
Scalability	High scalability	Limited scalability

With Dataverse, you can create complex relationships between tables, such as one-to-many and many-to-many. This capability allows for structured and scalable data management, which is crucial as your organization grows.

Better Scalability

Scalability is another significant advantage of Dataverse. As your data needs expand, Dataverse can efficiently manage larger datasets without performance degradation. SharePoint often struggles with scalability, especially when dealing with complex data relationships. In contrast, Dataverse supports real relationships and provides a centralized data store, reducing data silos.

Centralized data store reduces data silos.
Supports complex automation scenarios and real-time data exchange.
Extensive customization capabilities.

Migration Considerations

Steps to Migrate

Migrating from SharePoint to Dataverse requires careful planning. Here are key steps to ensure a smooth transition:

Identify all elements involved in your solution.
Map relationships between SharePoint lists and plan how to recreate them in Dataverse.
For Lookup Columns (Single Value), migrate data as text and create a Lookup column in Dataverse.
For Lookup Columns (Multi-Value), use Power Automate flows to establish proper Many-to-Many relationships.
Consider security configurations needed in Dataverse, mimicking existing role-based access control from SharePoint.
Explore third-party solutions to facilitate the transition.

Best Practices for Implementation

To maximize the success of your migration, follow these best practices:

Conduct a thorough assessment of your current SharePoint environment.
Engage stakeholders early in the process to gather requirements and expectations.
Test the migrated data in Dataverse to ensure accuracy and integrity.
Provide training for users to familiarize them with the new system.
Monitor performance post-migration to identify and address any issues promptly.

By following these steps and best practices, you can effectively transition to Dataverse, ensuring that your Power Apps perform optimally and scale with your business needs.

You must recognize the sharepoint lie to avoid costly mistakes in your Power Apps development. SharePoint limits your app’s performance, restricts data retrieval to 500–2,000 items, and complicates integration with external systems. These issues hurt your user experience and slow development.

Consider alternatives like Dataverse, which offer better scalability, flexible backends, and modern design options. Prioritize platforms that fit your business needs and provide transparent pricing.

Stay informed by consulting experts and monitoring updates to keep your apps efficient and secure.

FAQ

What is the main limitation of using SharePoint with Power Apps?

SharePoint struggles with large datasets and complex queries. This limitation can lead to slow performance and incomplete data retrieval in your applications.

How does Dataverse improve Power Apps performance?

Dataverse offers true relational data storage, enabling faster querying and better handling of large datasets. This structure enhances overall app performance.

What are delegation warnings in Power Apps?

Delegation warnings indicate that your queries may not retrieve all necessary data. Ignoring these warnings can result in incomplete data and performance issues.

Why should I consider migrating to Dataverse?

Migrating to Dataverse allows for better scalability, improved performance, and enhanced data governance. It supports complex data relationships, making it ideal for growing businesses.

How can I ensure a smooth migration to Dataverse?

To ensure a smooth migration, assess your current SharePoint environment, map relationships, and test migrated data for accuracy. Engage stakeholders early in the process.

What are the hidden costs of using SharePoint?

Hidden costs include unexpected licensing fees, maintenance expenses, and potential training costs. These can accumulate as your organization grows and data needs evolve.

How can I improve user experience in Power Apps?

To enhance user experience, prioritize delegation in your app design, use efficient querying methods, and regularly monitor app performance to address any issues.

What security measures should I implement with SharePoint?

Implement role-based access control and conduct regular permission reviews. Establish Data Loss Prevention (DLP) policies to protect sensitive data and ensure compliance.

🚀 Want to be part of m365.fm?

Then stop just listening… and start showing up.

👉 Connect with me on LinkedIn and let’s make something happen:

🎙️ Be a podcast guest and share your story
🎧 Host your own episode (yes, seriously)
💡 Pitch topics the community actually wants to hear
🌍 Build your personal brand in the Microsoft 365 space

This isn’t just a podcast — it’s a platform for people who take action.

🔥 Most people wait. The best ones don’t.

👉 Connect with me on LinkedIn and send me a message:
"I want in"

Let’s build something awesome 👊

1
00:00:00,000 --> 00:00:02,660
SharePoint lists are a database for Power Apps.

2
00:00:02,660 --> 00:00:03,600
Incorrect.

3
00:00:03,600 --> 00:00:07,700
That belief is why your apps stall at 2,000 records, choke on filters,

4
00:00:07,700 --> 00:00:10,540
and die behind a friendly blue delegation banner.

5
00:00:10,540 --> 00:00:12,940
Most teams discover the cliff at 5,000 items

6
00:00:12,940 --> 00:00:14,860
and then spend weeks patching symptoms.

7
00:00:14,860 --> 00:00:15,940
Here's the promise.

8
00:00:15,940 --> 00:00:18,540
You'll see the architectural why behind those failures,

9
00:00:18,540 --> 00:00:20,960
the measurable breakdowns, delegation warnings,

10
00:00:20,960 --> 00:00:23,620
load times record counts, and the decision thresholds

11
00:00:23,620 --> 00:00:26,100
that separate toy apps from production systems.

12
00:00:26,100 --> 00:00:27,900
I'll give you the red flag that predicts collapse

13
00:00:27,900 --> 00:00:29,460
before you write a single formula.

14
00:00:29,460 --> 00:00:32,180
And yes, we'll talk cost, governance, and migration,

15
00:00:32,180 --> 00:00:35,460
so IT leaders can justify data verse without glitter.

16
00:00:35,460 --> 00:00:38,740
The architectural mismatch, why SharePoint breaks at scale?

17
00:00:38,740 --> 00:00:41,380
SharePoint was built for content and collaboration.

18
00:00:41,380 --> 00:00:43,900
Documents, pages, conversations, basic lists.

19
00:00:43,900 --> 00:00:45,140
It's excellent at that.

20
00:00:45,140 --> 00:00:47,180
But a Power App is a data application.

21
00:00:47,180 --> 00:00:49,540
It needs a data platform that speaks relationships,

22
00:00:49,540 --> 00:00:51,660
delegation, and server-side execution.

23
00:00:51,660 --> 00:00:53,700
The truth, SharePoint isn't that platform.

24
00:00:53,700 --> 00:00:55,140
Let's state the stakes.

25
00:00:55,140 --> 00:00:57,620
When Power Apps can't delegate a query,

26
00:00:57,620 --> 00:01:00,060
it pulls data to the client and evaluates locally.

27
00:01:00,060 --> 00:01:02,220
That's fast in demos and catastrophic at scale.

28
00:01:02,220 --> 00:01:04,300
SharePoint's delegation surface is narrow.

29
00:01:04,300 --> 00:01:06,740
Simple filter and sort on index columns, sure.

30
00:01:06,740 --> 00:01:09,540
But the moment you stack conditions, search multiple columns,

31
00:01:09,540 --> 00:01:11,700
or try distinct group-by-look-upchains

32
00:01:11,700 --> 00:01:13,460
you fall off the delegation cliff.

33
00:01:13,460 --> 00:01:16,260
Your app silently caps results at 500 by default,

34
00:01:16,260 --> 00:01:18,020
2000 if you stretch the setting.

35
00:01:18,020 --> 00:01:19,180
Everything passed that?

36
00:01:19,180 --> 00:01:19,980
Invisible.

37
00:01:19,980 --> 00:01:22,660
Not filtered, not counted, gone.

38
00:01:22,660 --> 00:01:24,180
Compare that to data verse.

39
00:01:24,180 --> 00:01:26,980
Data verse is designed for structured relational data

40
00:01:26,980 --> 00:01:29,300
with server-side query execution.

41
00:01:29,300 --> 00:01:32,180
Filters, joins via relationships, aggregates,

42
00:01:32,180 --> 00:01:34,180
processed where the data lives.

43
00:01:34,180 --> 00:01:37,020
You get results for 200,000 rows the same way you do

44
00:01:37,020 --> 00:01:39,460
for 2000 because the server does the work.

45
00:01:39,460 --> 00:01:40,580
It's not just a database.

46
00:01:40,580 --> 00:01:43,500
It's the spine of the Power Platform's data model.

47
00:01:43,500 --> 00:01:44,940
Now the flat list problem.

48
00:01:44,940 --> 00:01:46,940
SharePoint gives you a list with limited lookups.

49
00:01:46,940 --> 00:01:49,940
You can't model rich relationships without hacks.

50
00:01:49,940 --> 00:01:52,580
The thing most people miss is that every work around

51
00:01:52,580 --> 00:01:54,620
denormalizing data into giant columns,

52
00:01:54,620 --> 00:01:58,340
duplicating text keys using Power Automate to stitch records,

53
00:01:58,340 --> 00:02:00,700
magnifies maintenance and erodes integrity.

54
00:02:00,700 --> 00:02:02,740
And once you join across lists with lookups,

55
00:02:02,740 --> 00:02:04,460
you invite non-delagable patterns.

56
00:02:04,460 --> 00:02:07,540
The price isn't just complexity, it's performance collapse.

57
00:02:07,540 --> 00:02:09,860
Let me show you exactly how the list view threshold

58
00:02:09,860 --> 00:02:11,300
and forces behavior.

59
00:02:11,300 --> 00:02:13,820
SharePoint can technically store up to tens of millions

60
00:02:13,820 --> 00:02:16,140
of items in a list, but the practical guardrail

61
00:02:16,140 --> 00:02:17,380
is 5,000 per query.

62
00:02:17,380 --> 00:02:20,220
Pass that unindexed filter's block, grouping's time out.

63
00:02:20,220 --> 00:02:22,500
Sorting on non-indexed fields fails.

64
00:02:22,500 --> 00:02:24,780
You can index some columns yes, but not your way out

65
00:02:24,780 --> 00:02:26,540
of combinatorial filters.

66
00:02:26,540 --> 00:02:28,340
The platform is protecting the shared service,

67
00:02:28,340 --> 00:02:29,580
not optimizing your app.

68
00:02:29,580 --> 00:02:31,100
You don't beat the threshold.

69
00:02:31,100 --> 00:02:33,420
You root around it until your logic buckles.

70
00:02:33,420 --> 00:02:34,900
Security makes it worse.

71
00:02:34,900 --> 00:02:36,500
Item level permissions sound helpful

72
00:02:36,500 --> 00:02:38,300
until you apply them at scale.

73
00:02:38,300 --> 00:02:41,700
SharePoint must evaluate access for each item in a view.

74
00:02:41,700 --> 00:02:44,580
That's extra work on every query view and app screen.

75
00:02:44,580 --> 00:02:46,580
In Dataverse, Row and Field Level Security

76
00:02:46,580 --> 00:02:49,460
are evaluated as part of the Data Engine's plan.

77
00:02:49,460 --> 00:02:51,740
Business units, security roles, auditing,

78
00:02:51,740 --> 00:02:53,260
all native, all performant.

79
00:02:53,260 --> 00:02:54,860
The reason this matters is simple.

80
00:02:54,860 --> 00:02:56,620
Security filtering is still filtering.

81
00:02:56,620 --> 00:03:00,180
If it's not efficient, your app pays the tax every tap.

82
00:03:00,180 --> 00:03:01,340
And now load time.

83
00:03:01,340 --> 00:03:02,860
Power apps does a lot under the hood.

84
00:03:02,860 --> 00:03:05,100
Metadata retrieval, control initialization,

85
00:03:05,100 --> 00:03:06,300
data source negotiation.

86
00:03:06,300 --> 00:03:08,340
In 2025, runtime improvements reduced

87
00:03:08,340 --> 00:03:10,660
unnecessary parallel queries and sped up rendering,

88
00:03:10,660 --> 00:03:13,020
which helps everyone, but it doesn't fix a source

89
00:03:13,020 --> 00:03:15,100
that demands client-side evaluation.

90
00:03:15,100 --> 00:03:17,980
If your first screen opens with filter search,

91
00:03:17,980 --> 00:03:20,300
against the SharePoint list that won't delegate,

92
00:03:20,300 --> 00:03:22,300
you're shipping a spinner, not a screen.

93
00:03:22,300 --> 00:03:25,180
Dataverse benefits most from those optimizations

94
00:03:25,180 --> 00:03:26,860
because the platform cooperates.

95
00:03:26,860 --> 00:03:30,460
Fewer round trips, more server execution, cleaner payloads.

96
00:03:30,460 --> 00:03:31,860
The game changer nobody talks about

97
00:03:31,860 --> 00:03:34,260
is how relational intent changes everything.

98
00:03:34,260 --> 00:03:36,300
In Dataverse, relationships are first class.

99
00:03:36,300 --> 00:03:39,220
You can traverse them, query across them, and secure them.

100
00:03:39,220 --> 00:03:42,060
In SharePoint, relationships are lookups with training wheels.

101
00:03:42,060 --> 00:03:43,620
That's fine for a project tracker.

102
00:03:43,620 --> 00:03:46,500
It's fragile for ticketing, assets, orders, inspections,

103
00:03:46,500 --> 00:03:49,180
or anything with multi-table joins and lifecycle rules.

104
00:03:49,180 --> 00:03:51,060
If you remember nothing else, remember this.

105
00:03:51,060 --> 00:03:53,500
SharePoint lists are excellent content shelves.

106
00:03:53,500 --> 00:03:55,220
Power apps need a data engine.

107
00:03:55,220 --> 00:03:57,980
For simple, flat scenarios, SharePoint is fine.

108
00:03:57,980 --> 00:04:00,740
The moment you need multi-lookup joins, compound filters,

109
00:04:00,740 --> 00:04:03,780
or more than trivial record counts, the platform fights you.

110
00:04:03,780 --> 00:04:05,100
And you will lose.

111
00:04:05,100 --> 00:04:06,420
The failure modes.

112
00:04:06,420 --> 00:04:09,820
You can measure delegation, load time, record counts.

113
00:04:09,820 --> 00:04:11,060
Let's quantify the pain.

114
00:04:11,060 --> 00:04:13,260
You don't need a hunch, you need artifacts.

115
00:04:13,260 --> 00:04:15,900
Power apps gives you three delegation warnings,

116
00:04:15,900 --> 00:04:18,300
load time behavior, and record count realities.

117
00:04:18,300 --> 00:04:21,500
If you ignore them, your users will provide a fourth artifact,

118
00:04:21,500 --> 00:04:24,460
abandonment, delegation first.

119
00:04:24,460 --> 00:04:26,980
That cheerful blue banner is not advice.

120
00:04:26,980 --> 00:04:28,100
It's a stop sign.

121
00:04:28,100 --> 00:04:29,780
When you see this formula might not be fully

122
00:04:29,780 --> 00:04:32,660
delegable, translation, power apps will evaluate locally

123
00:04:32,660 --> 00:04:33,940
and cap your results.

124
00:04:33,940 --> 00:04:36,940
Default cap 500, stretch setting 2000.

125
00:04:36,940 --> 00:04:39,140
The truth, you've just limited your apps' eyesight

126
00:04:39,140 --> 00:04:40,860
to a tiny slice of reality.

127
00:04:40,860 --> 00:04:42,660
Anything past that window doesn't exist

128
00:04:42,660 --> 00:04:44,220
as far as your formulas can tell.

129
00:04:44,220 --> 00:04:46,700
Filters, mismatches, counts under report,

130
00:04:46,700 --> 00:04:50,340
and no results found becomes a regular comedy bit.

131
00:04:50,340 --> 00:04:52,620
Which operations trigger this collapse in SharePoint?

132
00:04:52,620 --> 00:04:54,380
The usual suspects, chaining filter

133
00:04:54,380 --> 00:04:57,020
with or across multiple columns, using search

134
00:04:57,020 --> 00:04:59,180
on more than one field, distinct for deduplication,

135
00:04:59,180 --> 00:05:01,540
group buy for rollups, lookup chains across lists,

136
00:05:01,540 --> 00:05:03,220
and certain sort by columns, scenarios

137
00:05:03,220 --> 00:05:05,300
when the sort column isn't indexed.

138
00:05:05,300 --> 00:05:07,540
Add a multi-lookup join, and you're basically choosing

139
00:05:07,540 --> 00:05:09,100
the non-deligible path on purpose.

140
00:05:09,100 --> 00:05:11,780
Compare that to dataverse, where those same filters,

141
00:05:11,780 --> 00:05:15,020
sorts, and relationship traversals run server side.

142
00:05:15,020 --> 00:05:18,700
You request intent, the engine executes the plan efficiently.

143
00:05:18,700 --> 00:05:20,460
Now load time, the spinner text.

144
00:05:20,460 --> 00:05:23,220
Three mechanics matter, metadata fetch, control rendering,

145
00:05:23,220 --> 00:05:24,700
and query execution.

146
00:05:24,700 --> 00:05:26,780
The 2025 runtime optimizations helped

147
00:05:26,780 --> 00:05:28,620
with caching and deferred control loading,

148
00:05:28,620 --> 00:05:30,580
plus a smoother UI pipeline.

149
00:05:30,580 --> 00:05:31,140
Good.

150
00:05:31,140 --> 00:05:33,820
But if your first interaction is a non-deluggable query

151
00:05:33,820 --> 00:05:36,460
against SharePoint, you force the client to pull what it can

152
00:05:36,460 --> 00:05:37,300
then process.

153
00:05:37,300 --> 00:05:40,180
That means chatty network calls, inflated payloads,

154
00:05:40,180 --> 00:05:42,620
and a device doing work the server should have handled.

155
00:05:42,620 --> 00:05:45,340
You feel it as screens that take seconds to render,

156
00:05:45,340 --> 00:05:48,300
and galleries that pop in results unpredictably.

157
00:05:48,300 --> 00:05:50,060
A micro story, since you enjoy pain,

158
00:05:50,060 --> 00:05:52,700
a field service app with 120,000 tickets,

159
00:05:52,700 --> 00:05:55,460
three lookups per ticket, and user-scoped views.

160
00:05:55,460 --> 00:05:57,860
SharePoint worked, until it didn't.

161
00:05:57,860 --> 00:06:00,460
Delegation banners everywhere, views timing out

162
00:06:00,460 --> 00:06:02,460
when item-level permission scaled up,

163
00:06:02,460 --> 00:06:05,340
and a home screen that loaded in eight seconds on Wi-Fi,

164
00:06:05,340 --> 00:06:07,780
and whenever it felt like it, on cellular.

165
00:06:07,780 --> 00:06:09,740
Migration to dataverse dropped the home screen

166
00:06:09,740 --> 00:06:11,780
to under two seconds because the filters ran

167
00:06:11,780 --> 00:06:14,780
at the source and security-trimmed rows server side.

168
00:06:14,780 --> 00:06:17,420
No heroics, just using the right engine.

169
00:06:17,420 --> 00:06:20,820
Record counts next, the myth of its stores 30 million.

170
00:06:20,820 --> 00:06:22,900
Yes, a list can hold that many items.

171
00:06:22,900 --> 00:06:24,540
No, your app can't use them meaningfully

172
00:06:24,540 --> 00:06:26,060
if you need complex filtering.

173
00:06:26,060 --> 00:06:28,420
The list view threshold of 5,000 isn't negotiable.

174
00:06:28,420 --> 00:06:30,820
It's a guardrail that blocks unindexed queries,

175
00:06:30,820 --> 00:06:33,180
grouping, and certain sorts once your operations

176
00:06:33,180 --> 00:06:34,340
threaten the service.

177
00:06:34,340 --> 00:06:36,220
You can index columns, and you should,

178
00:06:36,220 --> 00:06:38,820
but you can't index your way out of combinatorial filters

179
00:06:38,820 --> 00:06:41,420
or ad hoc user searches across multiple fields.

180
00:06:41,420 --> 00:06:43,740
Practically, SharePoint list-backed apps

181
00:06:43,740 --> 00:06:47,140
stay sane below 100,000 items with disciplined views

182
00:06:47,140 --> 00:06:48,380
and strict patterns.

183
00:06:48,380 --> 00:06:50,380
Beyond that, the workaround tax compounds,

184
00:06:50,380 --> 00:06:52,060
extra flows, calculated columns,

185
00:06:52,060 --> 00:06:55,260
denormalized tax copies, and nightly jobs to fake rollups.

186
00:06:55,260 --> 00:06:58,180
Security-induced slowness is the stealth killer.

187
00:06:58,180 --> 00:07:00,500
Item-level permissions feel enterprise.

188
00:07:00,500 --> 00:07:03,660
In practice, every view and query pays a per item evaluation

189
00:07:03,660 --> 00:07:06,940
cost, performance drops, especially as unique permissions climb.

190
00:07:06,940 --> 00:07:09,620
Dataverse applies, row-level, and field-level rules

191
00:07:09,620 --> 00:07:12,260
within the engine's plan so the filter is part of the query,

192
00:07:12,260 --> 00:07:13,540
not a separate gauntlet.

193
00:07:13,540 --> 00:07:17,220
Result, less thrash more throughput, consistent response times,

194
00:07:17,220 --> 00:07:19,140
as complexity grows.

195
00:07:19,140 --> 00:07:21,700
Let's talk query complexity tax in practical terms.

196
00:07:21,700 --> 00:07:24,140
You want a gallery filtered by status, date range,

197
00:07:24,140 --> 00:07:26,660
and a free text search across title and description

198
00:07:26,660 --> 00:07:27,980
then sorted by priority.

199
00:07:27,980 --> 00:07:30,940
In SharePoint, parts of that stack are non-delagable or brittle

200
00:07:30,940 --> 00:07:33,700
unless you pre-index exactly the combination users hit.

201
00:07:33,700 --> 00:07:36,580
In Dataverse, it's delegable and runs on the server,

202
00:07:36,580 --> 00:07:39,300
so the client receives only the right rows in the right order.

203
00:07:39,300 --> 00:07:42,500
You save network, CPU, and your dignity.

204
00:07:42,500 --> 00:07:44,180
Quick win you can do today.

205
00:07:44,180 --> 00:07:46,740
Audit your app for blue banners, count of indexed columns

206
00:07:46,740 --> 00:07:48,180
versus filters in use.

207
00:07:48,180 --> 00:07:51,460
First screen load time on cold start and effective record window,

208
00:07:51,460 --> 00:07:53,900
500, 2000, or truly delegable.

209
00:07:53,900 --> 00:07:56,420
If any core screen relies on non-delagable filters,

210
00:07:56,420 --> 00:07:58,180
you already have silent data loss.

211
00:07:58,180 --> 00:07:59,780
Not theoretical, current.

212
00:07:59,780 --> 00:08:01,300
The takeaway is painfully simple.

213
00:08:01,300 --> 00:08:03,300
Delegation warnings predict wrong results.

214
00:08:03,300 --> 00:08:05,620
Load time patterns reveal where you force the client

215
00:08:05,620 --> 00:08:06,900
to do server work.

216
00:08:06,900 --> 00:08:08,860
Record counts expose the difference between can

217
00:08:08,860 --> 00:08:10,340
store and can query.

218
00:08:10,340 --> 00:08:12,580
When all three line up, you don't have a performance problem.

219
00:08:12,580 --> 00:08:14,740
You have an architectural mismatch.

220
00:08:14,740 --> 00:08:16,500
Dataverse isn't premium flair.

221
00:08:16,500 --> 00:08:18,660
It's the minimum viable data engine for apps that

222
00:08:18,660 --> 00:08:22,220
must scale, stay honest, and avoid the blue banner lottery.

223
00:08:22,220 --> 00:08:24,780
The dataverse advantage, performance, delegation,

224
00:08:24,780 --> 00:08:26,740
security, integration, now that you've

225
00:08:26,740 --> 00:08:30,220
seen where SharePoint collapses, enter dataverse.

226
00:08:30,220 --> 00:08:32,260
The data engine that actually speaks power

227
00:08:32,260 --> 00:08:33,700
apps native language.

228
00:08:33,700 --> 00:08:35,140
The truth, you're not buying features,

229
00:08:35,140 --> 00:08:36,780
you're buying the right physics.

230
00:08:36,780 --> 00:08:38,900
Server side execution, proper relationships,

231
00:08:38,900 --> 00:08:40,740
and security baked into the query plan.

232
00:08:40,740 --> 00:08:42,060
That's why it feels faster.

233
00:08:42,060 --> 00:08:42,900
It is faster.

234
00:08:42,900 --> 00:08:44,060
Performance first.

235
00:08:44,060 --> 00:08:47,340
Dataverse executes filters, sorts, and joins on the server

236
00:08:47,340 --> 00:08:48,180
close to the data.

237
00:08:48,180 --> 00:08:49,980
You're not dragging thousands of rows to a phone

238
00:08:49,980 --> 00:08:52,260
and hoping JavaScript performs miracles.

239
00:08:52,260 --> 00:08:55,180
With the 2025 runtime improvements, better metadata

240
00:08:55,180 --> 00:08:58,620
caching, deferred control loading, reduce chatty calls.

241
00:08:58,620 --> 00:09:00,900
Dataverse gains more because it cooperates.

242
00:09:00,900 --> 00:09:04,740
One intent, one efficient plan, one clean payload.

243
00:09:04,740 --> 00:09:06,860
Screens render predictably because the server sends

244
00:09:06,860 --> 00:09:09,700
exactly what the UI needs, not a haystack for the client

245
00:09:09,700 --> 00:09:10,460
to come.

246
00:09:10,460 --> 00:09:12,380
Delegation coverage is the headline act.

247
00:09:12,380 --> 00:09:14,660
The thing most people miss is that dataverse wasn't

248
00:09:14,660 --> 00:09:16,260
retrofitted for delegation.

249
00:09:16,260 --> 00:09:17,380
It was designed that way.

250
00:09:17,380 --> 00:09:20,020
Multi-column filters, relationship traversals, sorted

251
00:09:20,020 --> 00:09:22,460
results sets, distinks, even aggregations,

252
00:09:22,460 --> 00:09:23,300
delegable.

253
00:09:23,300 --> 00:09:25,860
You describe the slice the platform cuts its server side.

254
00:09:25,860 --> 00:09:27,660
That's why the 2000 record setting stops

255
00:09:27,660 --> 00:09:28,740
mattering.

256
00:09:28,740 --> 00:09:30,420
You're no longer appearing through a keyhole.

257
00:09:30,420 --> 00:09:33,260
You're looking at the full data set with a proper lens.

258
00:09:33,260 --> 00:09:36,260
And if you remember, nothing else, dataverse turns maybe

259
00:09:36,260 --> 00:09:38,620
delegable into yes by default.

260
00:09:38,620 --> 00:09:41,260
Let me show you exactly how relationships change the game.

261
00:09:41,260 --> 00:09:43,820
In Dataverse, tables relate via defined lookups

262
00:09:43,820 --> 00:09:47,020
with referential integrity, query across account orders,

263
00:09:47,020 --> 00:09:48,380
order lines, normal.

264
00:09:48,380 --> 00:09:50,740
Security across those joins included.

265
00:09:50,740 --> 00:09:53,300
In SharePoint, that's duct tape and non-delagable chains.

266
00:09:53,300 --> 00:09:55,020
In Dataverse, it's the plan.

267
00:09:55,020 --> 00:09:57,580
You get consistent response times because the engine knows

268
00:09:57,580 --> 00:10:00,060
how to optimize across normalized structures.

269
00:10:00,060 --> 00:10:02,980
You also stop duplicating columns just in case, which

270
00:10:02,980 --> 00:10:05,660
is where SharePoint apps quietly go to die.

271
00:10:05,660 --> 00:10:07,860
Security is where Dataverse stops being premium

272
00:10:07,860 --> 00:10:09,780
and becomes non-negotiable.

273
00:10:09,780 --> 00:10:12,140
Row level, field level, and business unit

274
00:10:12,140 --> 00:10:13,900
scoping run in the data engine.

275
00:10:13,900 --> 00:10:15,580
These privilege isn't a suggestion.

276
00:10:15,580 --> 00:10:18,220
It's enforceable without wrecking performance.

277
00:10:18,220 --> 00:10:20,940
Auditing is built in so you can answer who viewed or changed

278
00:10:20,940 --> 00:10:23,140
what without bolting on spreadsheets and prayers.

279
00:10:23,140 --> 00:10:25,980
And yes, it rides on enter ID, TLS, and transit encryption

280
00:10:25,980 --> 00:10:28,180
address, the enterprise basics you'd expect.

281
00:10:28,180 --> 00:10:31,620
SharePoint's item level security tries, Dataverse governs.

282
00:10:31,620 --> 00:10:34,340
Integration is not a bullet point, it's the runway.

283
00:10:34,340 --> 00:10:37,140
Dataverse is the hub for power platform, power BI,

284
00:10:37,140 --> 00:10:38,780
and AI workloads.

285
00:10:38,780 --> 00:10:39,900
Want analytics?

286
00:10:39,900 --> 00:10:41,580
Directly query or export to DataLake,

287
00:10:41,580 --> 00:10:42,980
no CSV gymnastics.

288
00:10:42,980 --> 00:10:44,700
Want AI or automation?

289
00:10:44,700 --> 00:10:47,100
You're already sitting on a structured govern store.

290
00:10:47,100 --> 00:10:49,100
And when you need external data virtualization,

291
00:10:49,100 --> 00:10:51,260
lets you project sources like PostgreSQL

292
00:10:51,260 --> 00:10:53,540
into Dataverse without copying every byte.

293
00:10:53,540 --> 00:10:56,620
You build one model, one app, one security story,

294
00:10:56,620 --> 00:10:59,140
minus the mass duplication that turns governance

295
00:10:59,140 --> 00:10:59,980
into folklore.

296
00:10:59,980 --> 00:11:01,580
Offline and mobile, this is where

297
00:11:01,580 --> 00:11:03,380
the delegation and sync meet.

298
00:11:03,380 --> 00:11:04,740
Because Dataverse query is delegate,

299
00:11:04,740 --> 00:11:07,180
you can define, compact, userscope data sets

300
00:11:07,180 --> 00:11:08,420
and actually sync them.

301
00:11:08,420 --> 00:11:10,620
The client isn't pretending to be a database,

302
00:11:10,620 --> 00:11:12,380
it's holding a curated cache.

303
00:11:12,380 --> 00:11:15,020
That's why grids feel responsive on weak connections

304
00:11:15,020 --> 00:11:17,660
and why updates reconcile rather than collide.

305
00:11:17,660 --> 00:11:21,060
SharePoint's offline story is, try not to breathe on it.

306
00:11:21,060 --> 00:11:22,860
One more signal you should not ignore.

307
00:11:22,860 --> 00:11:25,660
Microsoft's modern workloads are moving to Dataverse.

308
00:11:25,660 --> 00:11:27,020
Planner premium built on Dataverse

309
00:11:27,020 --> 00:11:29,420
wasn't a cute experiment, it's a declaration.

310
00:11:29,420 --> 00:11:31,540
When the vendor builds its own data heavy services

311
00:11:31,540 --> 00:11:34,220
on a platform, they're telling you where the road is paved.

312
00:11:34,220 --> 00:11:36,180
Common mistake to avoid treating Dataverse

313
00:11:36,180 --> 00:11:38,420
like SharePoint but expensive.

314
00:11:38,420 --> 00:11:39,740
You don't buy it to store rows.

315
00:11:39,740 --> 00:11:42,620
You buy it to execute intended scale, secure data correctly

316
00:11:42,620 --> 00:11:44,140
and integrate without heroics.

317
00:11:44,140 --> 00:11:45,260
That's the ROI.

318
00:11:45,260 --> 00:11:47,820
Fewer workarounds, fewer throttling meltdowns,

319
00:11:47,820 --> 00:11:49,820
fewer blue banner debates in standups.

320
00:11:49,820 --> 00:11:51,020
So yes, Dataverse costs.

321
00:11:51,020 --> 00:11:54,300
And yet, compared to weeks of power-automate crutches,

322
00:11:54,300 --> 00:11:56,300
denomalized hacks and governance nightmares,

323
00:11:56,300 --> 00:11:57,460
is the cheaper choice.

324
00:11:57,460 --> 00:11:59,620
The efficient choice, the adult choice,

325
00:11:59,620 --> 00:12:02,100
the cost reality, licensing, hidden workarounds

326
00:12:02,100 --> 00:12:03,700
and total cost of ownership.

327
00:12:03,700 --> 00:12:05,500
Let's talk money without the glitter.

328
00:12:05,500 --> 00:12:07,540
SharePoint looks free because it's bundled

329
00:12:07,540 --> 00:12:09,380
with Microsoft 365.

330
00:12:09,380 --> 00:12:10,820
Dataverse is premium.

331
00:12:10,820 --> 00:12:13,380
The average user stops there and congratulates themselves

332
00:12:13,380 --> 00:12:15,300
on frugality, fascinating.

333
00:12:15,300 --> 00:12:17,340
Now let's add the parts they never cost it.

334
00:12:17,340 --> 00:12:20,740
Workarounds, reliability losses, security compensations

335
00:12:20,740 --> 00:12:22,100
and migration rework.

336
00:12:22,100 --> 00:12:22,940
The truth?

337
00:12:22,940 --> 00:12:24,860
Free becomes your most expensive line item.

338
00:12:24,860 --> 00:12:25,740
Licensing first.

339
00:12:25,740 --> 00:12:28,580
Yes, Dataverse requires premium licensing and storage.

340
00:12:28,580 --> 00:12:30,620
You pay predictable, budgetable dollars

341
00:12:30,620 --> 00:12:33,900
for a platform that delegates scales and secures correctly.

342
00:12:33,900 --> 00:12:36,180
With SharePoint, you pay in people hours.

343
00:12:36,180 --> 00:12:37,940
Days building power, automate crutches

344
00:12:37,940 --> 00:12:39,700
to replace missing relationships,

345
00:12:39,700 --> 00:12:42,100
hours debugging, non-delagable formulas,

346
00:12:42,100 --> 00:12:43,820
nights rerunning, failed flows,

347
00:12:43,820 --> 00:12:45,340
weekends explaining to auditors

348
00:12:45,340 --> 00:12:48,100
why you can't produce field-level access logs.

349
00:12:48,100 --> 00:12:48,940
Those aren't features.

350
00:12:48,940 --> 00:12:51,900
Their payroll burning, hidden SharePoint costs are everywhere.

351
00:12:51,900 --> 00:12:53,460
Denomalization to dodge lookups.

352
00:12:53,460 --> 00:12:55,660
Now you maintain duplicate values across lists

353
00:12:55,660 --> 00:12:58,180
and pray someone remembers to keep them in sync.

354
00:12:58,180 --> 00:13:00,260
Calculated columns to fake rollups?

355
00:13:00,260 --> 00:13:02,540
Welcome to recalculation delays and brittle logic

356
00:13:02,540 --> 00:13:04,900
that explodes when the list crosses thresholds.

357
00:13:04,900 --> 00:13:06,580
Power automated to simulate joins.

358
00:13:06,580 --> 00:13:08,340
That's a pipeline of async band aids,

359
00:13:08,340 --> 00:13:10,300
throttling, retries, partial failures

360
00:13:10,300 --> 00:13:11,780
and reconciliation scripts.

361
00:13:11,780 --> 00:13:13,940
Each new workaround increases complexity,

362
00:13:13,940 --> 00:13:16,340
fragility and the blast radius of small changes.

363
00:13:16,340 --> 00:13:17,900
Reliability is its own ledger.

364
00:13:17,900 --> 00:13:21,300
Delegation warnings don't just slow you down, they make you wrong.

365
00:13:21,300 --> 00:13:23,500
Undercounted records, missed matches

366
00:13:23,500 --> 00:13:26,500
and views that silently exclude data are not performance issues,

367
00:13:26,500 --> 00:13:27,820
they're integrity failures.

368
00:13:27,820 --> 00:13:29,340
Users learn the app can't be trusted

369
00:13:29,340 --> 00:13:30,740
and defect to spreadsheets.

370
00:13:30,740 --> 00:13:33,500
Meanwhile, you're paying for triage meetings, quick fixes

371
00:13:33,500 --> 00:13:35,620
that add even more non-delagable logic

372
00:13:35,620 --> 00:13:38,460
and the reputational tax of shipping tools that lie.

373
00:13:38,460 --> 00:13:40,420
Security governance has a price tag too.

374
00:13:40,420 --> 00:13:41,900
SharePoint's item-level permissions

375
00:13:41,900 --> 00:13:43,260
look cheap until you scale.

376
00:13:43,260 --> 00:13:45,260
Evaluation per item drags performance,

377
00:13:45,260 --> 00:13:48,980
unique permissions multiply and reporting becomes archaeology.

378
00:13:48,980 --> 00:13:51,380
To reach parity with data versus built-in auditing

379
00:13:51,380 --> 00:13:52,460
and role models,

380
00:13:52,460 --> 00:13:54,100
you assemble logs, manual reviews

381
00:13:54,100 --> 00:13:56,020
and after the fact detective controls.

382
00:13:56,020 --> 00:13:58,660
In data verse, row and field level security, auditing

383
00:13:58,660 --> 00:14:00,220
and business units are native,

384
00:14:00,220 --> 00:14:01,820
aligned with least privilege,

385
00:14:01,820 --> 00:14:04,300
enforced in the query plan and measurable.

386
00:14:04,300 --> 00:14:07,540
That alignment saves both hours and incidents.

387
00:14:07,540 --> 00:14:11,380
Risk-adjusted math is where the free fallacy collapses.

388
00:14:11,380 --> 00:14:13,900
Count the cost of throttled flows causing stale data,

389
00:14:13,900 --> 00:14:15,940
blue banner bugs producing wrong decisions

390
00:14:15,940 --> 00:14:18,700
and slow screens that waste minutes per user per day.

391
00:14:18,700 --> 00:14:20,660
Multiply by head count and months,

392
00:14:20,660 --> 00:14:23,180
add one compliance event or an app abandonment cycle

393
00:14:23,180 --> 00:14:24,340
that triggers a rewrite.

394
00:14:24,340 --> 00:14:26,340
That total dwarfs the premium license

395
00:14:26,340 --> 00:14:28,820
and yes, the 2025 platform optimizations

396
00:14:28,820 --> 00:14:30,420
better caching fewer chatty calls,

397
00:14:30,420 --> 00:14:31,660
improve everyone's baseline

398
00:14:31,660 --> 00:14:33,340
but data verse converts those gains

399
00:14:33,340 --> 00:14:35,060
into sustained throughput,

400
00:14:35,060 --> 00:14:37,260
while SharePoint still funnels complex logic

401
00:14:37,260 --> 00:14:38,700
into the client.

402
00:14:38,700 --> 00:14:40,620
Budget framing for IT leaders is simple.

403
00:14:40,620 --> 00:14:42,540
Premium spend by scale, governance

404
00:14:42,540 --> 00:14:44,580
and fewer engineering fire drills.

405
00:14:44,580 --> 00:14:46,140
It buys delegable queries,

406
00:14:46,140 --> 00:14:48,460
so your dev stop playing formula Wacomoll.

407
00:14:48,460 --> 00:14:50,580
It buys auditing that satisfies auditors

408
00:14:50,580 --> 00:14:52,060
without a scavenger hunt.

409
00:14:52,060 --> 00:14:54,020
It buys security that performs

410
00:14:54,020 --> 00:14:56,420
and a model that integrates with Power BI and AI

411
00:14:56,420 --> 00:14:58,940
without exporting CSVs like it's 2009.

412
00:14:58,940 --> 00:15:00,860
Essentially, you're trading capricious maintenance

413
00:15:00,860 --> 00:15:02,260
for predictable operations.

414
00:15:02,260 --> 00:15:04,220
Migration effort belongs in the ROI too.

415
00:15:04,220 --> 00:15:06,820
Moving a data centric app from SharePoint to Dataverse,

416
00:15:06,820 --> 00:15:09,140
schema mapping, relationships, roles, data loads,

417
00:15:09,140 --> 00:15:11,060
refactoring flows and swapping connectors

418
00:15:11,060 --> 00:15:13,580
cost real time, but it's a one time project

419
00:15:13,580 --> 00:15:15,820
that retires a recurring tax.

420
00:15:15,820 --> 00:15:18,140
After migration, new features accrue faster

421
00:15:18,140 --> 00:15:19,860
because you're building on a platform designed

422
00:15:19,860 --> 00:15:22,100
for your use case, not battling thresholds

423
00:15:22,100 --> 00:15:23,540
and non-delicable landmines.

424
00:15:23,540 --> 00:15:25,540
If you remember nothing else, remember this.

425
00:15:25,540 --> 00:15:28,340
Dataverse is a line item, SharePoint workarounds

426
00:15:28,340 --> 00:15:29,460
are in a newety.

427
00:15:29,460 --> 00:15:31,780
One you approve once, the other you pay forever.

428
00:15:31,780 --> 00:15:34,020
Choose the expense that stops the bleeding.

429
00:15:34,020 --> 00:15:35,740
Decision framework, thresholds,

430
00:15:35,740 --> 00:15:37,460
red flags and migration paths.

431
00:15:37,460 --> 00:15:39,500
You want a line you can defend in a design review.

432
00:15:39,500 --> 00:15:40,380
Here it is.

433
00:15:40,380 --> 00:15:42,900
Choose Dataverse when any of the following are true.

434
00:15:42,900 --> 00:15:45,180
Your list will exceed 100,000 items.

435
00:15:45,180 --> 00:15:47,860
Users need compound filters or multicolumn search.

436
00:15:47,860 --> 00:15:49,940
You have more than one or two lookups per record.

437
00:15:49,940 --> 00:15:52,220
Offline is required or security must be granular

438
00:15:52,220 --> 00:15:54,460
at the row or field level with auditing.

439
00:15:54,460 --> 00:15:57,460
Cross any one threshold and SharePoint stops being included

440
00:15:57,460 --> 00:15:59,180
and starts being expensive.

441
00:15:59,180 --> 00:16:00,900
Now the red flags that predict collapse

442
00:16:00,900 --> 00:16:02,980
before you write a single formula.

443
00:16:02,980 --> 00:16:05,980
Persistent blue delegation banners anywhere in core user flows.

444
00:16:05,980 --> 00:16:08,140
Repeated use of non-delagable functions.

445
00:16:08,140 --> 00:16:10,580
Search across multiple fields, group by,

446
00:16:10,580 --> 00:16:13,940
distinct, chain lookup, filter with or across columns.

447
00:16:13,940 --> 00:16:16,860
Lists with item level permissions applied broadly.

448
00:16:16,860 --> 00:16:18,660
Views that intermittently time out

449
00:16:18,660 --> 00:16:21,220
or refuse to sort unless perfectly indexed.

450
00:16:21,220 --> 00:16:24,460
Threatening or cannot complete this operation messages

451
00:16:24,460 --> 00:16:26,420
near the 5,000 item mark.

452
00:16:26,420 --> 00:16:28,940
If you see two or more red flags during prototyping,

453
00:16:28,940 --> 00:16:30,900
you're already in rewrite territory.

454
00:16:30,900 --> 00:16:33,060
Governance triggers are straightforward.

455
00:16:33,060 --> 00:16:35,900
Do you need auditing that answers who saw or changed what?

456
00:16:35,900 --> 00:16:37,420
Do you need least privilege access

457
00:16:37,420 --> 00:16:39,540
by business unit, role and field?

458
00:16:39,540 --> 00:16:41,500
Do you have segregation of duties constraints

459
00:16:41,500 --> 00:16:42,740
or regulated data classes?

460
00:16:42,740 --> 00:16:44,060
Those are dataverse native.

461
00:16:44,060 --> 00:16:46,540
Trying to bolt them onto SharePoint guarantees performance

462
00:16:46,540 --> 00:16:48,100
drag and compliance busy work.

463
00:16:48,100 --> 00:16:50,340
Performance triggers are the user facing tells.

464
00:16:50,340 --> 00:16:53,460
First screen code starts exceeds three seconds on Wi-Fi.

465
00:16:53,460 --> 00:16:55,700
Gallery interaction stutter when filters stack.

466
00:16:55,700 --> 00:16:58,300
Search latency varies wildly across users.

467
00:16:58,300 --> 00:17:01,500
View operations fail unless you micromanage indexes weekly.

468
00:17:01,500 --> 00:17:04,380
The truth, you've offloaded data work to the client.

469
00:17:04,380 --> 00:17:06,740
Dataverse fixes that by executing intent

470
00:17:06,740 --> 00:17:07,860
where the data lives.

471
00:17:07,860 --> 00:17:09,580
Decision path succinct.

472
00:17:09,580 --> 00:17:12,620
If the app is simple, flat and disposable,

473
00:17:12,620 --> 00:17:15,620
think small trackers, light task boards, contact lists,

474
00:17:15,620 --> 00:17:18,620
keep it on SharePoint and enforce strict patterns.

475
00:17:18,620 --> 00:17:21,940
Indexed filters, single field search, minimal lookups,

476
00:17:21,940 --> 00:17:23,740
no item level security.

477
00:17:23,740 --> 00:17:25,540
Everything else, especially data centric apps

478
00:17:25,540 --> 00:17:28,300
with life cycles, moves to dataverse proactively,

479
00:17:28,300 --> 00:17:31,140
don't wait for the blue banner to become a help desk legend.

480
00:17:31,140 --> 00:17:32,860
Migration isn't mystical, it's methodical.

481
00:17:32,860 --> 00:17:34,060
Start with schema mapping.

482
00:17:34,060 --> 00:17:36,020
Identify lists, columns and lookups,

483
00:17:36,020 --> 00:17:37,780
then normalize into dataverse tables

484
00:17:37,780 --> 00:17:39,340
with relationships you actually want.

485
00:17:39,340 --> 00:17:41,300
Define primary keys and alternate keys

486
00:17:41,300 --> 00:17:44,180
where you previously faked uniqueness with text columns.

487
00:17:44,180 --> 00:17:46,460
Next, design security roles and business units

488
00:17:46,460 --> 00:17:49,460
to match how access should work, not how it evolved.

489
00:17:49,460 --> 00:17:52,740
Translate item level hacks into proper row and field permissions.

490
00:17:52,740 --> 00:17:54,100
Data load comes next.

491
00:17:54,100 --> 00:17:57,260
Export clean, de-duplicated data from SharePoint.

492
00:17:57,260 --> 00:17:59,300
Load parent tables first, then children,

493
00:17:59,300 --> 00:18:02,860
respecting relationships, validate counts and spot check joints.

494
00:18:02,860 --> 00:18:05,660
While data moves, refactor power automate flows,

495
00:18:05,660 --> 00:18:08,700
replace list actions with dataverse triggers and actions,

496
00:18:08,700 --> 00:18:10,780
drop any compensating steps that existed

497
00:18:10,780 --> 00:18:12,260
only to work around missing joints

498
00:18:12,260 --> 00:18:14,260
and consolidate error handling.

499
00:18:14,260 --> 00:18:16,580
In the app, swap connectors, rewrite

500
00:18:16,580 --> 00:18:19,180
non-delegable formulas into delegate queries

501
00:18:19,180 --> 00:18:22,020
and remove calculated column crutches you no longer need,

502
00:18:22,020 --> 00:18:24,140
where you previously copied text to denormalize,

503
00:18:24,140 --> 00:18:25,860
use relationships and views.

504
00:18:25,860 --> 00:18:27,780
Then test for delegation at every screen.

505
00:18:27,780 --> 00:18:29,740
No blue banners allowed if you see one,

506
00:18:29,740 --> 00:18:32,180
change the formula or adjust the data model.

507
00:18:32,180 --> 00:18:34,260
Don't ship, mostly, delegateable.

508
00:18:34,260 --> 00:18:35,820
That's just sometimes wrong.

509
00:18:35,820 --> 00:18:38,340
Risk controls during migration keep your weekends quiet,

510
00:18:38,340 --> 00:18:41,340
segment environments, dev, test, prod.

511
00:18:41,340 --> 00:18:44,420
So data and security can be validated without surprises.

512
00:18:44,420 --> 00:18:47,940
Run a face cut over, pilot a user group on the dataverse version

513
00:18:47,940 --> 00:18:50,980
while SharePoint remains read only as the interim source

514
00:18:50,980 --> 00:18:53,820
of truth, then flip one's parity is proven.

515
00:18:53,820 --> 00:18:56,620
Monitor with telemetry, track load times query counts

516
00:18:56,620 --> 00:18:58,180
and delegation status.

517
00:18:58,180 --> 00:19:01,260
Establish rollback only for catastrophic issues.

518
00:19:01,260 --> 00:19:03,380
Otherwise, fix forward.

519
00:19:03,380 --> 00:19:05,060
On the platform built to scale,

520
00:19:05,060 --> 00:19:06,940
a final threshold many miss if you're

521
00:19:06,940 --> 00:19:08,900
authoring flows to pre-compute rollups

522
00:19:08,900 --> 00:19:11,780
joining lists with power automate or exporting to CSV

523
00:19:11,780 --> 00:19:12,740
for analytics.

524
00:19:12,740 --> 00:19:15,780
You've already paid more in workarounds than a premium license.

525
00:19:15,780 --> 00:19:19,380
The adult move is to stop paying that annuity and migrate.

526
00:19:19,380 --> 00:19:20,180
Key takeaway.

527
00:19:20,180 --> 00:19:22,260
SharePoint lists are content shelves.

528
00:19:22,260 --> 00:19:24,460
Dataverse is a data engine that delegates,

529
00:19:24,460 --> 00:19:25,740
secures and scales.

530
00:19:25,740 --> 00:19:28,220
Use the right tool once your app needs relationships,

531
00:19:28,220 --> 00:19:30,500
complex filters or honest counts.

532
00:19:30,500 --> 00:19:32,660
Adopt the thresholds and red flags you heard,

533
00:19:32,660 --> 00:19:35,300
audit your apps this week, and escalate migrations

534
00:19:35,300 --> 00:19:36,980
before users feel the spinner tags.

535
00:19:36,980 --> 00:19:38,660
If you want the schema mapping walkthrough

536
00:19:38,660 --> 00:19:42,020
and a delegation deep dive, subscribe and turn on notifications.

537
00:19:42,020 --> 00:19:43,620
Choose structure over entropy.

538
00:19:43,620 --> 00:19:47,220
Move the data to dataverse and stop arguing with blue banners.

Mirko Peters

Founder of m365.fm, m365.show and m365con.net

Mirko Peters is a Microsoft 365 expert, content creator, and founder of m365.fm, a platform dedicated to sharing practical insights on modern workplace technologies. His work focuses on Microsoft 365 governance, security, collaboration, and real-world implementation strategies.

Through his podcast and written content, Mirko provides hands-on guidance for IT professionals, architects, and business leaders navigating the complexities of Microsoft 365. He is known for translating complex topics into clear, actionable advice, often highlighting common mistakes and overlooked risks in real-world environments.

With a strong emphasis on community contribution and knowledge sharing, Mirko is actively building a platform that connects experts, shares experiences, and helps organizations get the most out of their Microsoft 365 investments.

Item-level permissions killing your app speed? A better way with Dataverse