Briefcase
Briefcase in Salesforce is the offline data package that mobile users (especially Salesforce Field Service technicians and Salesforce Mobile App users on intermittent connectivity) download to their device so they can read, edit, and create records when the network is unavailable.
Definition
Briefcase in Salesforce is the offline data package that mobile users (especially Salesforce Field Service technicians and Salesforce Mobile App users on intermittent connectivity) download to their device so they can read, edit, and create records when the network is unavailable. The Briefcase contains the records, related lists, page layouts, and metadata the user needs to work on the records assigned to them. When connectivity returns, the changes sync back to the Salesforce server and conflicts are resolved through the platform's sync engine.
Briefcase exists because real-world mobile work happens in places with no signal (rural service routes, hospital basements, manufacturing floors, airplanes). Without Briefcase, the mobile app reverts to read-only or offline-error when the network drops; with Briefcase, the user keeps working and the platform reconciles when they come back online. The data scope of a Briefcase is defined by Briefcase Builder, an admin tool that lets admins pick which records, related objects, and depth of relationships ship to the device.
Why offline mobile work requires a deliberate data package, not all data
What a Briefcase contains
A Briefcase contains a subset of the user's accessible Salesforce data: the user's assigned records on a specified primary object (Work Order, Service Appointment, Asset, custom field-service object), related records on configured related objects (Account, Contact, Asset linked to the Work Order), supporting metadata (page layouts, picklist values, custom field definitions), and any reference data the user needs (Knowledge articles, Pricebook entries). The total size is bounded; mobile devices have storage limits and the platform caps the Briefcase to keep download time reasonable. Most Briefcases run 50 MB to 500 MB depending on data complexity.
How Briefcase relates to Salesforce Field Service
Salesforce Field Service uses Briefcase extensively. Each technician has a Briefcase of the day's Service Appointments, Work Orders, Assets, related Customers, and any required Inventory or Service Reports. The Field Service Mobile app downloads the Briefcase at the start of the shift and works offline through the day, syncing changes as connectivity allows. Service-related Briefcase configurations are usually shipped with the Field Service Managed Package; admins customize the Briefcase scope per role (electrician, plumber, HVAC tech) so each technician's device holds the right data.
The Briefcase Builder admin surface
Briefcase Builder is the Setup area where admins design Briefcase definitions. Each Briefcase Definition has a primary object (the entry point), filters that scope which records of that object are included (assigned to current user, status in a list of values, scheduled date in a range), and a list of related objects with their own filters (related to the primary, only Active records). The builder produces a visual tree of what data the Briefcase will ship; admins can preview the size before publishing. Multiple Briefcase Definitions can exist; each is assigned to a permission set or profile to control which users get which Briefcase.
Sync, conflict resolution, and the last-write-wins question
When connectivity returns, the device syncs changes back to Salesforce. Conflicts arise when the same record was edited on the device and on the server during the offline period. The platform's default resolution is last-write-wins by timestamp; the more recent edit overwrites the earlier. Some conflicts are surfaced for manual resolution through the mobile app's conflict UI. Conflicts are most common on shared records (a Work Order assigned to two technicians; both edit the Status field offline). Designing the Briefcase to minimize shared records reduces conflict frequency more than tuning the resolution logic does.
Storage, device limits, and the size discipline
Mobile devices have storage limits; a Briefcase that grows to multiple GB fills the device and degrades app performance. Briefcase Builder shows the estimated size at publish time; admins should set a soft cap (around 500 MB) and tune filters to stay under it. Common size reducers: limit the date range of historical activities, exclude attachment files (often the largest category), exclude related objects the technician does not actually need offline (Account billing history when the work order is operational only). The size-versus-utility trade-off is the central Briefcase design decision.
Permissions and the per-role Briefcase pattern
Each Briefcase Definition is assigned to permission sets or profiles. Users in the assigned permission sets get that Briefcase on their device. Users in multiple permission sets with multiple Briefcase Definitions get the union, scoped to what the user can see. Most large Field Service deployments build per-role Briefcase Definitions (Electrician Briefcase, Plumber Briefcase, Supervisor Briefcase) rather than one universal Briefcase, because the universal pattern includes data each role does not need and bloats the size.
Where Briefcase falls short and the workaround patterns
Briefcase covers data offline but not all platform features work offline. Flows can run offline if they are marked Available for Offline use; not all Flows can be. Lightning components work offline if the developer built them with offline considerations in mind; many third-party components do not. Apex callouts do not work offline (the network is unavailable). Reports and dashboards do not work offline. For workflows that depend on these, the team has to plan around them: pre-compute values server-side, ship the result as a custom field, design the offline experience to use only the features that work offline.
How to design a Briefcase that survives a full field-service day
The successful pattern: define per-role, scope tightly, exclude attachments by default, test on the actual device under realistic offline conditions. The failed pattern: ship one universal Briefcase to every role, include everything, and discover at scale that the device runs out of storage and the sync takes 20 minutes.
- Identify the per-role data needs
For each field-service role, list the records the technician must access offline (Service Appointments today, Work Orders this week, Assets at customer locations). The list is the basis for per-role Briefcase Definitions.
- Build per-role Briefcase Definitions in Briefcase Builder
Setup, Briefcase Builder, New Briefcase. Pick the primary object and filters. Add related objects with their own filters. Use the size preview to keep the Briefcase under 500 MB.
- Exclude attachments and files by default
Attachment data is the largest single contributor to Briefcase size. Exclude unless specific workflows need the files offline; even then, scope tightly (only the current Work Order's attachments).
- Assign Briefcase Definitions through permission sets
Each role gets the matching Briefcase via permission set assignment. Users in multiple roles get the union.
- Test on the actual device under offline conditions
Download the Briefcase to a test device, turn off network, exercise the workflows the technicians actually run. Sync after, check for conflict surfaces.
- Pilot with two or three technicians for a week
Real field conditions surface issues lab testing misses. Two to three technicians for a week with explicit feedback collection finds the gaps before broad rollout.
- Monitor Briefcase size and sync time over months
Briefcase scope can grow without admin awareness as the data behind the filters changes. Quarterly audit of Briefcase size and sync time per role catches drift before it becomes a field complaint.
The entry-point object for the Briefcase (Service Appointment, Work Order, Asset). Drives what related data is in scope.
Filters scoping which records of the primary and related objects are included.
Per-Briefcase-Definition list of related objects to include with their own filters.
Whether files and attachments are part of the Briefcase. Excluded by default; opt-in for specific workflows.
Which user populations get the Briefcase. One Briefcase Definition per role is the common pattern.
- Attachment files are the largest size contributor in most Briefcases. Excluding them by default and opting in for specific workflows keeps size manageable.
- Briefcase scope can grow silently as the data behind the filters changes. Quarterly audit catches drift before it becomes a field complaint.
- Apex callouts and reports do not work offline. Workflows depending on them need server-side pre-computation or redesign for offline.
- Conflict resolution defaults to last-write-wins by timestamp. Shared records edited by multiple technicians produce conflicts; design Briefcases to minimize sharing.
- One universal Briefcase across all roles includes data each role does not need and bloats size. Per-role Briefcase Definitions are the right pattern at any scale.
Trust & references
Cross-checked against the following references.
- Briefcase Builder referenceSalesforce
- Salesforce Field ServiceSalesforce
Straight from the source - Salesforce's reference material on Briefcase.
- Briefcase BuilderSalesforce Help
- Field Service Mobile AppSalesforce 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. What does a Briefcase do in Salesforce?
Q2. Why is Briefcase configuration important for field service?
Q3. What is a potential downside of including too many records in a Briefcase?
Discussion
Loading discussion…