In large-scale Salesforce Field Service (SFS) environments, managing external contractor networks requires a delicate balance between platform security and scheduling performance. This guide compares two primary architectural patterns: the traditional territory-based pattern and the new account-based sharing pattern for governing external contractors' access and management. In this paper, we review both in depth to help organizations choose the foundational structure that best supports their operational goals, and to understand the trade-offs of each option.

This pattern choice affects scheduling efficiency, resource utilization, and dispatcher productivity. By selecting the right approach, companies ensure a seamless experience for both internal staff and external partners while maintaining the long-term scalability of their solution.

Beyond immediate operational gains, this foundational choice determines an organization's readiness for autonomous service. The account-based sharing pattern provides the unified data visibility required for Agentforce, and specifically the Scheduling Agent for Field Service, to perform holistic evaluation without being restricted by artificial data silos. Account-based sharing also enables Data Cloud to aggregate contractor performance metrics more effectively, allowing for seamless competitive benchmarking while maintaining the rigorous data isolation required in multi-vendor environments.

• Select your pattern based on competitive overlap. If external contractors compete with internal or other external resources on shared territories, account-based sharing is likely the architecturally correct choice. Territory-based sharing is appropriate only when contractors receive exclusive, non-overlapping service areas/jobs.
• Avoid territory sprawl. Creating dedicated contractor territories to achieve data isolation when not necessary introduces hierarchy bloat that degrades scheduling efficiency and performance, and significantly increases administrative overhead at scale. Account-based sharing eliminates this problem pattern.
• Build the foundation for AI-driven scheduling. The Scheduling Agent for Field Service and the Optimization engine will have better performance when they have full resource-pool visibility. Territory-based sharing siloed structure prevents this; Account-based sharing is the desired architectural foundation.

Over the past decade, contractor networks in field service have evolved from ad hoc extensions of internal teams to strategic, deliberately structured ecosystems across industries including telecommunications, utilities, home services and more. Many field operations now rely on contractors alongside full-time employees, requiring clear rules for access, visibility, and dispatch control.

As organizations scale on Salesforce Field Service, the way they design and manage these external resources—whether through territory-style pattern, account-centric sharing, or hybrids—directly shapes how securely and efficiently they can schedule work across a blended workforce.

This guide is intended for technical and strategic stakeholders responsible for the design, performance, and scalability of Salesforce Field Service implementations:

• Solution and Technical Architects: To evaluate the impact of different sharing patterns on scheduling and optimization efficiency.
• Field Service Operations Leaders: To understand the trade-offs between different contractor personas, such as Named Contractors, Contractor Companies, and Occasional Workers.
• Salesforce Administrators: To gain insight into how Service Territories and platform sharing tables are used to manage complex security requirements.

The contractor persona in scope directly determines the appropriate sharing architecture. Each category carries distinct implications for how record-level access is structured, how the Optimizer perceives resource availability, and how the solution scales:

• Named Contractor: An individual external resource who is treated similarly to an internal employee. A named contractor requires a dedicated user license. The sharing model mirrors internal technician access patterns, making this the lowest-complexity contractor persona to support.
• Contractor Company: A third-party entity that manages its own workforce. In SFS, contractor companies are represented as Capacity-Based Resources, where the parent organization schedules and assigns work to the company rather than a specific individual.
• Occasional Worker: A user who temporarily operates across multiple territories. The most architecturally complex persona. Transient, multi-territory relationships mean that territory-based sharing boundaries break down, so visibility is managed dynamically at the record level rather than through static geographic assignment.

These patterns are complex because the parent organization and the goals of the contractor are often technically at odds.

1. Divergent Goals: The parent organization primarily focuses on customer satisfaction and contractual work/agreement (for example, resource preferences, servicing quickly and timely, and managing how work and hours are distributed across contractors). Contractors, by contrast, typically focus on maximizing assigned work while minimizing travel time and operational cost.

2. Competition: Unlike internal employees, different contractor companies are often direct competitors. While the parent organization needs a holistic view of the region (transparency), the contractors require strict isolation from each other's operations (isolation).

3. Brand Integrity: To the end customer, the worker represents your brand, which often requires the parent company to see real-time status updates. However, contractors often guard their internal operations in a closed system, or "black box."

4. Visibility and Security: While a shared service territory typically implies universal visibility of all assigned resources, multi-contractor environments require a more nuanced security pattern. To maintain competitive integrity and data privacy, it's essential to prevent contractors from accessing each other's proprietary names, schedules, or resource information.

Contractor design within Salesforce Field Service spans three distinct operating models, each affecting resource visibility, dispatch ownership, and licensing:

1. External Capacity Allocation
2. Partner Self-Scheduling
3. Internal-Led Dispatch

External Capacity Allocation (Off-Platform Capacity): The contractor manages their workforce externally and provides a defined capacity (for example, 10 available hours) rather than individual technician schedules. This capacity is treated as a bucket of hours or work items for scheduling purposes.

Partner Self-Scheduling: Contractor managers log into Salesforce via an Experience Site to schedule their own teams. They require strict isolation from other partners.

Internal-Led Dispatch: Internal dispatchers schedule contractor technicians directly. Contractors use the Field Service Mobile App for execution.

In this pattern, the Service Territory serves as the primary security boundary. Each Contractor Company is assigned to its own unique "Child" territory.

• Small-scale partner networks
• Partners with strictly non-overlapping geographical regions
• Situations where contractor work is fundamentally different from internal resource work, eliminating competition (for example, external contractors handle only "Type A installations", while internal resources handle all other work types)

• Simplified configuration: Uses standard User Territory setup and automation.
• Clear data bucketing: Makes sure of easy data visibility and simplified security management through standard Service Territory objects.

• Optimization Efficiency: The engine cannot evaluate resources across territory boundaries, preventing optimal scheduling and efficient routing.
• Territory Sprawl: Creating a larger number of territories for a very low number of resources leads to scheduling overhead.
• Gantt Performance: Large hierarchies (1K+ territories) can cause significant performance bottlenecks as well as risks of hitting platform limits.

This guide introduces a new solution approach: Account-based sharing (implemented via Salesforce's native criteria-based sharing rules, the same platform mechanism used to grant record access based on field values). Account-based sharing decouples visibility from geography. Territories remain large and continuous, while visibility is managed through the platform's sharing tables based on an account relationship. In practical terms, criteria-based sharing rules evaluate a field on the record (such as ServiceResource.Company) and automatically share that record with the appropriate group. Criteria-based sharing is the engine that makes Account-based sharing work without custom code at the record level.

• Large-scale ecosystems where a significant proportion of the workforce consists of external resources
• Urban areas where multiple contractors cover the same zip codes
• Scenarios where both internal and external resources are capable of executing the same work (for example, "Type A installations"), but business rules dictate a specific logic for resource selection (for example, internal resource preference in certain scenarios)

• Maximum utilization and ROI: The engine evaluates the entire regional pool, finding the "best" resource for every job
• Scalability: Supports a large number of contractors/external resources without increasing territory counts
• Consolidated Management: Internal staff manage one view rather than hundreds of siloed folders (child territories)

• Development Effort: Requires custom automation (Flow or Apex) to manage the Sharing tables
• Membership Sharing: Requires explicit sharing of Service Territory Member (STM) records

For external workforce (External Capacity Allocation dimension), architects can use Capacity-Based Resources to represent the "summary" of a contractor's workforce.

• Capacity: Use this when the contractor manages their own dispatching and routing. Your primary focus is on the total volume of work they can fulfill rather than the specific person performing it.
• Individual: Use this when you need granular visibility into a technician's day. Individual-based resources allow you to manage their exact location, real-time availability, and specific job assignments as if they were internal staff.

Before designing your Field Service contractor pattern, use this decision tree to determine the appropriate sharing architecture.

Contractor Sharing Pattern Selection Decision Tree

Decision tree for selecting a contractor sharing pattern in Salesforce Field Service. Starting from whether external resources are in use, the tree branches through resource type and job exclusivity to recommend either territory-based sharing or account-based sharing.

The core of this pattern is an automation layer that converts the ServiceResource.AccountId or ServiceResource.Company (Contractor Company) relationship into platform sharing records.

To verify proper access for the dispatcher and the service resource in an Experience Site, access needs to be controlled via:

• Service Resource Sharing Rule: Grants access based on a criteria (account/company)
• Service Territory Sharing Rule: Grants access based on a criteria (territory name/ID)

When using account-based sharing, be sure to account for the Field Service Mobile experience and record visibility for assigned technicians.

• Assigned Resource Sharing: Standard SFS functionality automatically grants an assigned resource access to the Service Appointment and its parent Work Order. This setup gives the technician the necessary information to execute the job without requiring additional custom sharing rules for assigned work.
• Visibility Risks: While assigned work is handled natively, be cautious about unassigned or future appointments that lack an Account or Territory association. If Organization-Wide Defaults (OWDs) aren't strictly managed, or if sharing sets are too broad, unassigned appointments could be visible to all users in a consolidated territory.
• Account-Territory Association: Make sure that all service appointments are explicitly linked to an account and territory. This linking allows clean filtering within the mobile app and verifies that data leakage does not occur for unassigned work sitting in the regional pool.

• Requirement: 10 different contractors provide fiber installation in London.
• Context: In the territory-based sharing approach, London would be split into 10 overlapping territories. Dispatchers would struggle to see nearby availability, leading to high travel times.
• Recommendation: Account-based sharing. Implement a unified "Greater London" service territory utilizing account-based sharing to maintain granular data security. Account-based sharing keeps Contractor A's management siloed to their respective resources, while the SFS Optimizer maintains cross-functional visibility of all internal and external technicians. This complete scheduling approach facilitates a more efficient routing logic that can reduce travel by more than 20% through complete scheduling (directional estimate based on field observations across SFS customer deployments), creating immediate improvements in resource utilization and enhanced service responsiveness.

• Requirement: A vendor provides up to 40 "slots" for boiler repairs daily but manages their own technician dispatching.
• Context: Managing 40 individual resource records adds unnecessary overhead.
• Recommendation: Capacity-based resource linked to the vendor account. One resource record represents the vendor's total daily capacity, keeping the Gantt clean and avoiding the need to manage individual contractor technician records.

• Requirement: A utility company onboards 50 small local contractors during storm season to handle surge repairs.
• Context: Creating and deleting 50 territories every season is a major administrative burden, and it negatively impacts the flexibility of the scheduling and optimization engine.
• Recommendation: Account-based sharing. Create a permanent "Overflow" Geographical Territory. When a contractor is onboarded, simply create their account and link their resources to it. The automation layer handles visibility instantly without requiring a territory hierarchy redesign.

• Requirement: For high-priority gas leaks, the closest technician must be dispatched regardless of which contractor they work for.
• Context: Territory-based sharing creates coverage gaps where the closest tech might be in a different territory, and therefore unreachable to the scheduling logic.
• Recommendation: Account-based sharing. By consolidating vendors into a single large territory, the engine performs a complete search based on travel across the entire multi-vendor pool, reducing response times for critical safety incidents.

• Requirement: A specialized HVAC partner has a 10-year exclusive legal right to service a remote area or rural county.
• Context: There are no other contractors operating in this geography, and the partner manages their own scheduling and dispatching entirely.
• Recommendation: Territory-based sharing. In this scenario, a dedicated Service Territory is the most efficient choice. Since there is no geographical overlap with other partners, the isolation provided by the territory boundary matches the legal and operational requirements perfectly without further sharing automation.

Account-based sharing separates visibility from geography by tying record-level access to a common account/company identifier shared between the dispatcher user and their Service Resource records. The platform's native criteria-based sharing engine evaluates this field and automatically grants or revokes access without changing the territory hierarchy.

The three architectural components required are:

1. A common identifier field on both User and Service Resource objects linking them to their contractor account.
2. Public Groups aggregating all Dispatcher users per contractor company, so sharing rules apply uniformly.
3. Criteria-based sharing rules that evaluate the identifier and grant the appropriate Public Group access to relevant records.

Rather than using territories as boundaries, use Public Groups to aggregate dispatchers who require the same visibility. Dispatchers see specific Territories, Work Orders, and Service Appointments via membership in territory-based Public Groups.

• Group Creation: Create a Public Group for each contractor company.
• Member Assignment: Add the relevant Partner Community Users (dispatchers) to their respective contractor Public Group.

Leverage criteria-based sharing rules to grant the Public Group's access to specific records.

• Service Resource Sharing Criteria: Service resource sharing rules enforce per-contractor technician visibility by matching the company/account identifier on the Service Resource record to the corresponding contractor Public Group.
  • Access level permits read/write to allow dispatchers to schedule and update assignments.
• Service Territory Sharing Criteria: Use the service territory sharing criteria to set up the logic for territory restricted access. Grant dispatchers access the broad geographical territories where they are authorized to work. Example:
  • Criteria: ServiceTerritory.Name EQUALS "Atlanta".
  • Shared With: Relevant Contractor Public Groups (for example, Contractor A, Contractor B, Contractor C).
  • Access Level: Read/Write

For detailed implementation guidance, refer to the official Salesforce documentation:

• Criteria-Based Sharing Rules
• Public Groups
• Apex Triggers for automated share record management

When correctly implemented, account-based sharing delivers:

• Unified Visibility: Dispatchers see all relevant resources across the full territory without manual territory reassignment.
• Dynamic Access: As contractor assignments change, sharing rules automatically adjust visibility without administrator intervention.
• Competitive Isolation: Each contractor only sees their own resources, maintaining data privacy.
• Scalable Architecture: New contractors can be onboarded by simply creating an account and public group, with sharing rules handling the rest automatically.

1. Principle of Least Privilege: Grant only the minimum access required for contractors to perform their role.
2. Separation of Concerns: Isolate contractor data from competitors while maintaining organizational visibility.
3. Audit Trail: All sharing rule changes should be logged and reviewable.
4. Performance Optimization: Minimize sharing rule complexity to maintain platform performance at scale.

Salesforce Field Service performance degrades as territory hierarchy depth and breadth increase:

• Recommended: Maximum 500 territories per hierarchy
• Warning Zone: 500-1,000 territories (monitor Gantt performance)
• Critical: 1,000+ territories (significant performance degradation expected)

• Batch Processing: When creating or updating sharing records via Apex, use batch processing for operations affecting more than 200 records.
• Asynchronous Execution: Use @future or Queueable Apex for sharing calculations that don't require immediate consistency.
• Selective Queries: Filter SOQL queries for sharing rule evaluation to minimize database load.

Key metrics to track:

• Gantt Load Time: Time to render dispatcher console
• Optimization Runtime: Time for scheduling engine to complete
• Sharing Calculation Time: Time for platform to recalculate sharing after record changes
• Territory Member Count: Number of resources per territory

Organizations with existing territory-based implementations can migrate incrementally:

1. Phase 1 - Foundation (Weeks 1-2)
   • Create contractor account records
   • Establish public groups
   • Configure criteria-based sharing rules (inactive)
2. Phase 2 - Pilot (Weeks 3-4)
   • Select one contractor company for pilot
   • Activate sharing rules for pilot group
   • Run parallel with existing territory structure
   • Validate dispatcher and technician access
3. Phase 3 - Rollout (Weeks 5-8)
   • Migrate contractors in batches of 5-10
   • Monitor performance metrics
   • Gather user feedback and adjust
4. Phase 4 - Cleanup (Week 9+)
   • Deactivate old territory-based structures
   • Archive unused territories
   • Document final architecture

Maintain territory structures for first 30 days post-migration to enable rapid rollback if critical issues arise.

Use Case: Organization with both exclusive and competitive territories

Implementation:

• Territory-based sharing for exclusive regions
• Account-based sharing for competitive urban areas
• Clear documentation of which pattern applies where

Use Case: Contractor companies with multiple permission levels (managers, dispatchers, technicians)

Implementation:

• Create separate public groups per permission tier
• Layer sharing rules to grant appropriate access per role
• Use permission sets to control field-level security

Use Case: Seasonal or emergency contractors with time-limited access

Implementation:

• Date-based fields on User/ServiceResource
• Scheduled flows to add/remove from public groups
• Automated deactivation after contract end date

Diagnosis:

1. Verify contractor user is in correct public group
2. Check criteria-based sharing rules are active
3. Confirm ServiceResource.AccountId matches sharing criteria
4. Validate Organization-Wide Defaults (OWD) settings

Resolution:

• Add user to appropriate public group
• Activate sharing rules if inactive
• Update AccountId field on ServiceResource
• Adjust OWD to "Private" for controlled objects

Diagnosis:

1. Check public group membership
2. Review sharing rule criteria
3. Validate territory member associations

Resolution:

• Remove user from incorrect public groups
• Refine sharing rule criteria to be more specific
• Update ServiceResource company/account fields

Diagnosis:

1. Verify ServiceTerritoryMember records exist
2. Check contractor resources are Active
3. Validate work rule configurations

Resolution:

• Create missing ServiceTerritoryMember records
• Set ServiceResource.IsActive = true
• Review and update work rule criteria

• Service Territories Overview
• Sharing and Visibility Designer
• Field Service Mobile App
• Scheduling and Optimization

• Field Service Basics
• Sharing and Security
• Apex Triggers

• Salesforce Field Service Community
• Field Service Success Community

This guide represents architectural patterns observed across Salesforce Field Service implementations. Individual requirements may vary. Consult with a Salesforce Architect or Success Architect for implementation guidance specific to your organization.