You've hit a really important point about understanding how system users and their actions contribute to Power Platform request limits. The documentation can sometimes be a bit nuanced, especially when dealing with internal system processes. Let's break down your questions:
Understanding System Users and Request Limits
A System User in Dynamics 365 (Dataverse) without a specific Caller ID assigned is generally performing actions on behalf of the system itself or internal processes, rather than a specific licensed user. These actions do consume Power Platform request entitlements for the tenant.
Why They Count Towards Limits:
The Power Platform request limits are designed to manage the overall consumption of resources within the tenant, regardless of whether the initiator is a licensed user or an internal system process. Actions performed by system users still utilize the platform's services and infrastructure.
Addressing Your Questions:
1. Is this row counted in any (general) limitations?
Yes, absolutely. Actions performed by the "System" user (without a specific Caller ID) are counted towards your tenant's overall Power Platform request entitlements. These requests fall under the general, non-interactive request limits for the tenant.
2. If yes, then how can I spot, monitor, and follow its actions to be able to make fewer requests by this Caller Type? What actions in general are executed by this System object?
This is the more challenging part, as direct monitoring of the "System" user's actions isn't always straightforward through standard user-centric audit logs. However, here's a breakdown of how you can approach this:
How to Spot and Monitor System User Actions:
- Audit Logs (Key but Not Always Granular):
- Go to Settings > Audit Log Management.
- You can filter the audit logs by "Changed By" and look for entries where the user is "# CRM Service" or similar system-level accounts. This often represents actions performed by the "System" user.
- While the audit log will show what actions were performed (e.g., Create, Update, Delete on specific records), it might not always clearly indicate why the "System" user performed them.
- Background Processes and Workflows:
- Review System Jobs (Settings > System Jobs): Many automated tasks and background processes run under the context of the "System" user. Monitor successful and failed system jobs. Look for recurring jobs that might be making a high number of requests. Analyze their steps to understand the actions being performed.
- Examine Workflows (Settings > Processes): Identify any automated workflows (especially background workflows) that are owned by the "SYSTEM" user. Analyze their steps and execution frequency to understand the requests they generate.
- Business Process Flows (BPFs): While initiated by users, BPF stage transitions and actions can sometimes trigger system-level updates. Review your BPFs for automated steps.
- Plugins and Custom Code:
- Review Registered Plugins (XrmToolBox or Plugin Registration Tool): Plugins execute server-side logic and can be triggered by various events. If a plugin is registered to run under the "System" user context (often the default for synchronous plugins), its operations will contribute to the limits. Analyze your plugin code to understand the number and type of Dataverse operations it performs.
- Examine Custom Workflow Activities: Similar to plugins, custom workflow activities execute server-side logic. Review their implementation.
- Integrations:
- If you have any external systems integrating with Dynamics 365, these integrations often use a service principal or a dedicated integration user. However, if the integration is poorly configured or makes excessive calls, it could indirectly lead to more internal "System" user activity. Monitor your integration logs and patterns.
- Power Automate Flows (Run As System):
- If you have Power Automate flows that are configured to "Run as System", their actions will consume tenant request limits under the system context. Review the connection details and actions of your flows.
How to Make Fewer Requests by the "System" User:
Reducing requests made by the "System" user involves optimizing the underlying processes that trigger these actions:
- Optimize Background Processes and Workflows:
- Reduce Frequency: If possible, decrease the frequency of recurring workflows and system jobs.
- Optimize Steps: Ensure workflows and system jobs are efficient and only perform necessary actions. Avoid redundant reads or writes.
- Conditional Logic: Implement conditions to prevent unnecessary execution of steps.
- Bulk Operations: Use bulk update or delete operations where appropriate to reduce the number of individual requests.
- Optimize Plugins and Custom Code:
- Efficient Queries: Ensure your code uses efficient FetchXML or Web API queries, selecting only the necessary attributes.
- Bulk Operations: Use
ExecuteMultiple for performing multiple create, update, or delete operations in a single request.
- Asynchronous Operations: Where appropriate, use asynchronous plugins or workflows to avoid blocking user interfaces and potentially improve performance.
- Careful Event Registration: Ensure plugins are only registered for the necessary events and stages.
- Optimize Integrations:
- Efficient Data Retrieval: Ensure integrations are retrieving only the required data.
- Batching: Implement batching mechanisms in your integrations to reduce the number of API calls.
- Caching: Consider caching frequently accessed data to reduce redundant requests.
- Review Power Automate Flows:
- Follow best practices for efficient flow design, such as minimizing loops and using efficient connectors.
Key Takeaway:
You can't directly "throttle" the "System" user. Instead, you need to identify the underlying automated processes (workflows, system jobs, plugins, integrations, Power Automate flows running as system) that are causing the "System" user to make requests and optimize those processes for efficiency. Monitoring the audit logs and system jobs is your primary way to understand the what, and then you need to investigate the why by looking at your automation configurations and custom code.
Share
Report
45
All responses (
Answers (
