Sync optimization checklist

This page is a practitioner's checklist for keeping synchronization fast and healthy. The same advice applies whether you are designing a new project or troubleshooting an existing one — the levers are the same, and they are ordered here by how much impact they have on sync performance.

If you're troubleshooting a slow sync, start at the top. Even if you're convinced the problem is somewhere else, the levers near the top of this page have outsized influence on everything below. A well-tuned download phase cannot rescue a bloated data model, but a leaner data model makes every downstream optimization more effective.

Mobile data model

The biggest lever, both at design time and during troubleshooting. Every entity and column that's part of the mobile data model is data the sync engine has to evaluate, transfer, and reconcile on every sync. Removing it is the single most effective optimization available.

Recommendations:

• Review projects with more than 100 entities, or more than 30 columns per entity, with skepticism. Most large models contain things added years ago and never removed.
• Drop unneeded columns — especially lookup columns, which carry client-side index cost.
• Omit unused entities. Each enabled entity costs extra API calls with each sync, even when nothing changed.
• Check server table sizes for each enabled entity. Use Resco Agents' dataverse_get_table_stats or server-side reporting (Power Platform Admin Center > Licensing > Capacity > Dataverse > environment details). Server-side growth and archiving policy is part of the sync story.

See Data model in mobile apps.

Sync filter design

For entities you do enable, sync filters determine which records users get. Good filters reduce both the data on each device and the work required per sync (server, network, device).

Recommendations:

• No filter is often the right answer. For small entities (up to ~10 MB on the server), the cost of evaluating a filter every sync outweighs the savings. Don't add filters where they won't pay off. See entity size and filter strategy.
• Avoid moving time windows. A filter like "scheduled for the next 14 days" changes its result set on every sync, even when no records change. Prefer on-or-after with no upper bound where the use case allows it.
• Keep filter logic consistent across linked entities. If a parent's filter excludes inactive accounts but the child's filter doesn't, the sync downloads child records whose parent will be cleaned up on the device. Match the logic.
• Be cautious about complex filter conditions. OR across columns and LIKE with wildcards prevent the SQL server from using indexes efficiently — the cost grows with the underlying table size.

For situations where chained filters across multiple entities are creating problems, see Deep dive: Sync filters in Field Service for techniques specific to booking-centric data models.

See Sync Filter and Sync Filter examples.

Incremental sync strategy

For each entity, four incremental sync strategies are available, with different trade-offs between sync time, completeness, and risk of stale data. The default (standard incremental sync) is right for most entities; the other three are optimizations for specific situations.

Quick guidance:

• Standard incremental sync — the default. Use unless one of the alternatives clearly fits.
• Incremental with Sync Filter — for entities whose records are effectively immutable, or only created by the mobile user.
• Incremental Linked SyncFilter — to catch changes that happen on related records rather than the target record (e.g., a parent becomes active, so the child should appear).
• Always Full Sync — for small or medium entities where a dynamic filter makes incremental bookkeeping not worth the complexity.

See Sync Filter and incremental sync for the full technical treatment with worked examples, and Incremental sync strategies for the risk profile of each.

Attachments and questionnaires

Attachments and questionnaire data are often the largest contributors to local storage and to per-sync data transfer — disproportionate to their role in user workflows.

Recommendations:

• Let Resco auto-downscale JPEG and PNG images. Don't disable this unless full resolution is a hard requirement.
• Restrict attachment downloads with Document filters — size limits, file-type filters, and per-entity rules.
• Use the current questionnaire storage model (templates and answers stored separately) rather than legacy approaches.
• Keep question identifiers short. Long names bloat every questionnaire response record.
• Enforce data retention. Old completed questionnaires that no one will read again are pure storage cost.

SmartSync configuration

SmartSync runs targeted partial syncs that update only selected entities. It complements regular sync — it doesn't replace it.

Recommendations:

• Exclude stable entities from SmartSync profiles (auto exclusions). Entities that change rarely (configuration tables, product catalogs) don't benefit from frequent partial sync.
• Run a regular sync periodically. SmartSync only refreshes the entities it's configured for; without an occasional regular sync, deletions and entities outside the SmartSync profile drift out of date.
• Verify related entities are included. A profile that updates orders but not the customers those orders reference will produce dangling references on the device.

FetchXML and security cost

When a specific sync query is slow, the issue is often the cost of the underlying FetchXML — particularly when the filter uses linked entities or operates against a complex security model and big data.

Key concepts:

• Reverse links (lookup pointing from the linked entity back to the base) traverse data as a branching tree. They are fundamentally more expensive than forward links and often produce duplicates that require DISTINCT.
• Outer links pay the join and security cost without reducing the base dataset. Use inner links where the related record is required to exist.
• IN/EXISTS link types (available since release 18.0) can replace expensive inner links over reverse lookups with subqueries. Particularly effective for small subquery result sets such as the MyBookings pattern in Field Service.
• Server-side security checks run on every linked entity in a fetch, not just the base entity. Reducing link count, role complexity, and the number of shares all reduce sync cost. Give overall read access to insensitive child entities where business policy allows.

See Deep dive: Linked entities in FetchXML for the full treatment. For Field Service-specific patterns, see Deep dive: Sync filters in Field Service.

Download phase tuning

When the sync log shows that the download phase is slow despite the levers above, the Advanced sync setup configuration can be tuned: number of download threads, download cache size, per-entity page size, entity priority. These don't change what gets synced — they change how efficiently the sync engine moves it.

This is the area where data drives the answer. The sync log records per-entity download statistics; the right tuning depends on those numbers. See Deep dive: Sync download optimization for how to read the log and which knobs to turn.

Sync hygiene

Operational practices that prevent small problems from becoming large ones.

Recommendations:

• Train users not to ignore upload errors. Records that fail to upload (validation errors, permission changes, server-side constraints) accumulate in the SyncErrors form and are retried at every sync. Left unresolved, they slow every subsequent sync.
• Audit regularly. Sync performance is not a "set and forget" property. Use the Sync Dashboard and SyncStats analyzer to spot trends — sync times that grow gradually, error counts that creep up, entities whose download time has shifted. SyncStats analyzer is great for providing an overview at a glance. Resco Agents' AI, connected to sync statistics, can answer questions in natural language, and its role is likely to grow.
• When something goes wrong, troubleshoot systematically. Start with Synchronization troubleshooting.