The pattern: pick the right primary, scope filters tightly, exclude attachments by default, iterate on size until under 500 MB, pilot with real users. The Builder's visual feedback makes iteration cheap; use it.
- Identify the user role and the offline workflow
Document what the technician (or mobile user) needs to do offline. The list drives the primary object, filters, and related objects.
- Open Briefcase Builder and pick the primary object
Setup, Briefcase Builder, New. Pick the primary object. Service Appointment or Work Order for Field Service; Account or Opportunity for sales mobile.
- Set the primary filter to assigned-to-current-user with date range
The combination scopes to records the user actually owns plus a reasonable time window. Today plus next 7 days is the common starting filter for Field Service.
- Add related objects with their own filters
Contact, Account, Asset depending on workflow. Each related object should have a tight filter (Active only, Primary role only) to avoid pulling unnecessary records.
- Check the size estimate and tighten the largest contributor
The right rail shows estimated size. If above 500 MB, identify the branch contributing most and tighten it. Iterate until under target.
- Publish and assign via permission set
Publish the Briefcase Definition. Assign the matching permission set to the user role. The Briefcase ships on the user's next sync.
- Pilot with two or three users for a week
Real field conditions surface issues lab testing misses. Two to three users, explicit feedback, then broader rollout.
The root of the Briefcase tree. Service Appointment, Work Order, Account, Opportunity depending on workflow.
Scopes which records of the primary object are included. Usually assigned-to-current-user plus date range.
Per-Briefcase list of related objects with their own filters and depth.
Permission sets or profiles that receive the Briefcase. Per-role assignment is the common pattern.
Real-time size and record count shown in the Builder. The primary feedback mechanism for tuning.
- Picking the wrong primary object cascades through the whole Briefcase. The primary should be the record type the user starts their offline session looking at.
- Deep related-object trees produce large Briefcases. Most Briefcases should stay at depth 2 to 3; deeper trees usually mean on-demand fetching is the better pattern.
- The Builder estimates are real-time but rely on current data. A Briefcase that estimates 300 MB today can grow to 600 MB in six months as record volume increases.
- Unpublishing does not immediately clear the device. The next sync clears the data; users may have outdated data in the interim.
- Filter expressions support $User context (current user, current user's territory) but not arbitrary Apex. Complex filtering may need to happen upstream through custom fields the Briefcase filters on.