Understanding Licensing Constraints

1. The Licensing Trigger: Standard vs. Premium Features

The first and most fundamental licensing consideration is the distinction between standard and premium capabilities. Your choice of connectors and data sources is often the primary factor that determines the required license for your app or flow users.

• Standard Connectors: These connect to services included within a Microsoft 365 license (e.g., SharePoint, Outlook, Excel).
• Premium Connectors: These connect to services that require a standalone Power Apps or Power Automate license. This category includes connectors to external systems (like Salesforce or Twitter), enterprise databases (like SQL Server), and, most importantly for us, Microsoft Dataverse.
• Custom Connectors: Any custom connector you build is automatically considered a premium feature.

The moment your solution uses a premium feature, every user of that app or every flow run will require a premium license.

To understand the core Power Apps licensing models that are unlocked by these premium licenses, the following video provides a clear overview.

Similarly, Power Automate has its own licensing tied to the use of premium connectors.

As a developer, this is your first architectural checkpoint. If a business requirement can be met with a SharePoint list (standard) versus a Dataverse table (premium), you must be aware of the licensing impact of that decision.

2. Constraint #1: Power Platform Request Limits (Daily Entitlements)

Once you're in the premium world, the next major constraint is API usage. The Power Platform allocates a certain number of API requests per user over a 24-hour period based on their license. Think of this as a "daily budget" of actions.

What counts as a request? It's not just Dataverse API calls. It includes almost every action across the platform:

• CRUD operations in Dataverse from any client.
• API requests to any connector in Power Apps or Power Automate.
• Every single action in a Power Automate flow, even initializing a variable or a compose action. Retries and pagination also count.

The official documentation provides the most accurate and detailed information on these limits.

Key Developer Takeaways:

• Licensed vs. Non-Licensed Limits:

  • Licensed Users: Each user with a premium license gets their own daily request pool (e.g., 40,000 for a Power Apps/Automate Premium license).
  • Non-Licensed Identities (Application Users): For your backend integrations using service principals (Application Users), there is a separate, tenant-wide pool. The size of this pool depends on the licenses purchased for the tenant (e.g., a Dynamics 365 Enterprise license provides a base of 500,000 requests).

• Flow Ownership and Triggers Matter: The identity whose API "budget" is consumed depends on the flow type.

  • Automated/Scheduled Flows: Requests are counted against the flow owner's limit.
  • Instant/Manual Flows: Requests are counted against the invoking user's limit.
  • Process License (Per-Flow): Assigning a Process license gives the flow its own large, dedicated pool of requests (250,000 per 24 hours), independent of any user. This is the best practice for critical, high-volume business processes.

Your experience with C# integrations is directly relevant here. When designing a system-to-system integration, choosing to run it under an Application User identity means you are drawing from the shared non-licensed pool, which must be managed carefully across all such integrations in the tenant.

3. Constraint #2: Service Protection API Limits (Throttling)

Distinct from the daily entitlement limits are the service protection limits. These are not about a daily budget but about protecting the platform's health and performance from "noisy neighbors"—applications that send an overwhelming number of requests in a short period.

These limits are evaluated over a 5-minute sliding window and are based on three factors:

1. Number of requests: A high volume of calls.
2. Combined execution time: The total server computation time used by your calls.
3. Number of concurrent requests: How many parallel requests you are sending.

When these limits are exceeded, Dataverse returns a 429 Too Many Requests error. This is not a failure; it's the platform telling your application to slow down.

Architectural Implications for Developers:

• Retry Logic is Mandatory: Any professional application that performs bulk operations (data migrations, large updates) must implement a retry mechanism. When you receive a 429 error, your code should:

  1. Read the Retry-After header from the HTTP response.
  2. Pause execution for the specified duration.
  3. Retry the request.
     Your background in C# and .NET makes you well-equipped to implement this using libraries like Polly, as shown in the documentation.

• Plugins vs. Flows: Dataverse operations originating from within a plugin or custom workflow activity do not count towards the service protection API limits (though the extra computation time they add to the initial request does). An external client (like a Power Automate flow or a C# console app) making thousands of calls is far more likely to be throttled than a single plugin performing the same number of internal operations. This is a critical factor when choosing between an on-platform (plugin) or off-platform (flow, Azure Function) automation strategy.

4. Constraint #3: Dataverse Capacity

The final constraint is storage. Your Power Platform tenant has a finite amount of Dataverse capacity, which is broken down into three types:

• Database Capacity: For storing your table data (records).
• File Capacity: For storing file attachments, notes, and images.
• Log Capacity: For audit logs and other system logs.

This capacity comes from a default amount provided per tenant, plus an accrued amount for each full premium license purchased.

Why this matters for your architecture:

• Data Model Design: A poorly designed data model with redundant data can consume database capacity unnecessarily.
• File Storage Strategy: For solutions that handle many large files (e.g., a document management system), storing them directly in Dataverse File storage can be expensive. A common architectural pattern is to use Azure Blob Storage for the files and store only the URL in Dataverse, which consumes minimal database capacity. This is a key design decision with significant cost and licensing implications.

Conclusion

Today we've moved from the "how" of building to the "how to build responsibly" within the platform's rules. For a developer, these are not just administrative details; they are core architectural principles.

Key Takeaways:

• Premium is a Gateway: Using Dataverse or a premium/custom connector is the trigger that requires a premium license for your users or flows.
• Daily API Budget: Power Platform Request limits are a daily entitlement per user or process. Design efficient flows and integrations to stay within these limits. Use Process/Per-flow licenses for critical automations.
• Handle Throttling Gracefully: Service Protection API limits are a fact of life for high-volume applications. Your code must include retry logic based on the Retry-After header to be considered production-ready.
• Storage is an Architectural Choice: Dataverse capacity is a finite resource. Plan your data and file storage strategy to be both cost-effective and scalable.

In our next lesson, we will continue our journey through solution architecture by looking at Application Lifecycle Management (ALM). We'll compare and contrast the use of unmanaged and managed solutions, a foundational concept for moving your work from a development environment to testing and production professionally.