Briefcase Builder
Briefcase Builder is the Salesforce Setup tool where administrators design and publish Briefcase Definitions: the offline data packages mobile users download to work without network connectivity.
Definition
Briefcase Builder is the Salesforce Setup tool where administrators design and publish Briefcase Definitions: the offline data packages mobile users download to work without network connectivity. Each Briefcase Definition specifies a primary object, a set of filters that scope which records of that object are included, a list of related objects with their own filters, and a target permission set or profile that determines which users receive the Briefcase on their device. The Builder produces a visual tree of the data scope and an estimated size before the definition is published.
Briefcase Builder is the admin counterpart to the Briefcase feature itself. The runtime (Briefcase on the device) consumes whatever the Builder configured. Admins who design Briefcase Definitions carefully end up with field-service mobile experiences that work reliably offline at reasonable sync times. Admins who skip the design and ship over-broad Briefcases end up with bloated devices and 20-minute syncs.
Why Briefcase Builder rewards deliberate design over default shipping
Where Briefcase Builder lives in setup
Setup, Briefcase Builder. The page lists every Briefcase Definition in the org, its primary object, target audience (permission set or profile), and publish status. Click New Briefcase to open the visual builder. Click into an existing Briefcase to edit, clone, or unpublish. The Builder is feature-flagged in some editions; if it does not appear in your Setup tree, confirm the Field Service or Mobile add-on SKU coverage with your AE.
The visual tree and the scope preview
The Builder shows the Briefcase scope as a tree: the primary object at the root, related objects branching off, each with their own filters. The right rail shows the estimated record count and storage size per branch. Admins can drill into any branch to refine filters; the estimates update in real time. The visual feedback is the part of the tool that most reduces over-scoping mistakes; admins see immediately when a branch contributes 80 percent of the size and can tighten it.
Primary object selection and the scope anchor
The primary object is the entry point for the Briefcase. For Field Service, it is typically Service Appointment or Work Order. For sales mobile workflows, it might be Account or Opportunity. The choice anchors which records are included; related objects branch off the primary. Picking the wrong primary leads to Briefcases that miss key data or include too much; the primary should be the record type the user starts their offline session looking at.
Filters and the assignment-aware scope
Filters scope which records of each object are included. The most common primary filter is "assigned to current user" (the technician sees only their own appointments). Other filters: status in a list (Active, Confirmed), date range (this week's appointments), record type (only Repair Work Orders). Related object filters apply the same way (only Contacts where Type equals Primary). Filters can reference user attributes through the $User context (assigned to me, in my territory), which keeps the same Briefcase Definition useful across many users with different data.
Related objects and the depth-of-relationship question
Each related object can include its own related objects up to a depth limit. A Work Order Briefcase might include related Contact, then related Account on the Contact, then related Asset on the Account. Each additional level adds data; deep trees produce large Briefcases. Most Briefcases stay at depth 2 to 3; deeper trees usually mean the user could fetch the data on-demand instead. The Builder enforces a depth cap (typically 4 or 5 depending on edition) to prevent runaway scoping.
Publish, audience assignment, and the activation step
After designing, the admin publishes the Briefcase Definition. Publishing makes the Briefcase available; assignment via permission set determines which users actually receive it. Multiple Briefcase Definitions can be assigned to the same user; the union ships to the device. Unpublishing a Briefcase Definition stops new syncs but does not immediately remove the existing data from the device; the next sync clears it. Plan for the user-visible transition window when migrating from one Briefcase Definition to another.
Size tuning and the iterative pattern
Size tuning is iterative. First pass: include everything that seems useful. Estimate: 1.2 GB (too big). Second pass: exclude attachments. Estimate: 400 MB. Third pass: narrow the historical activity window from one year to 30 days. Estimate: 250 MB. The pattern is build wide, look at the estimate, tighten the largest contributors, re-estimate. Most Briefcases reach a workable size within three or four iterations. Admins who skip the iteration and ship the first version usually ship something too big.
How to build a Briefcase Definition that works for the field
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.
Trust & references
Cross-checked against the following references.
- Briefcase Builder referenceSalesforce
- Salesforce Field ServiceSalesforce
Straight from the source - Salesforce's reference material on Briefcase Builder.
- Briefcase BuilderSalesforce Help
- Field Service BriefcaseSalesforce Help
- Salesforce Mobile AppSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Why is understanding Briefcase Builder important for Salesforce admins?
Q2. In which area of Salesforce would you typically find Briefcase Builder?
Q3. What is the primary benefit of Briefcase Builder for Salesforce administrators?
Discussion
Loading discussion…