FS-Con-101 Questions and Answers

Candidates/Get Candidates, Bulk Schedule, and Schedule is the appropriate Field Service design. These actions use the Scheduling Policy to evaluate resource eligibility and scheduling quality. Candidates exposes options, Bulk Schedule handles multiple selected appointments, and Schedule automatically places an individual appointment under policy logic.

In scheduling design, it is important to distinguish eligibility from preference. Work Rules filter candidates that do not satisfy hard constraints such as territory, availability, skills, or boolean conditions, while Service Objectives rank the remaining options. Dispatcher Console actions then use that policy logic to place, move, or dispatch appointments in a controlled way.

The alternatives address different parts of the Field Service model. Change Status to Dispatch does not perform policy-based scheduling, and manually editing a resource assignment bypasses the scheduling engine ' s candidate evaluation.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Dispatcher Console scheduling actions; Scheduling Policies.

For this scenario, Salesforce Field Service should use Page Layouts. Field Service Mobile uses assigned layouts to determine which Work Order and Service Appointment fields and related information technicians see. Appropriate profile/record-type layout assignments therefore provide the standard way to simplify the mobile record view.

Field Service Mobile is designed for technicians working in changing connectivity conditions. Standard page layouts, quick actions, flows, Service Reports, Knowledge, and supported mobile extensions should be used before introducing custom Visualforce or bespoke components because the native features participate in synchronization, offline behavior, and the Field Service security model.

The alternatives address different parts of the Field Service model. Field Sets apply to specific configurable surfaces, Visualforce is custom development, and Mini-Page Layouts do not drive the normal Field Service Mobile record experience.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Configuring Mobility — Field Service Mobile; Page Layouts; technician record views.

The requirement is best implemented with Resource Availability, Scheduling Policy logic, and realistic travel-speed settings. Routing accuracy and appointment placement depend on the availability rule, the policy ' s Work Rules and Service Objectives, and the travel-time model. Default Travel Speed is used for aerial calculations when no resource-specific speed overrides it.

In scheduling design, it is important to distinguish eligibility from preference. Work Rules filter candidates that do not satisfy hard constraints such as territory, availability, skills, or boolean conditions, while Service Objectives rank the remaining options. Dispatcher Console actions then use that policy logic to place, move, or dispatch appointments in a controlled way.

The alternatives address different parts of the Field Service model. Auto Schedule is an execution setting rather than a routing factor, and street-level routing uses road-network information rather than simply computing a straight-line shortest route.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Routing; Resource Availability; Scheduling Policies; travel speed.

For this scenario, Salesforce Field Service should use Skills, Skill Requirements, and Service Resource Skills. Skills define capabilities, Skill Requirements state what the work needs, and Service Resource Skills record what each technician possesses and at what proficiency level. Together they provide the complete data model required for skill-based scheduling.

For resource design, the consultant should model the real operational constraint at the correct layer: skills for expertise, capacity for outsourced workload, crew membership for coordinated teams, Operating Hours and absences for availability, and permission sets for user capabilities. Mixing these concepts leads to inaccurate scheduling behavior and unnecessary customization.

The alternatives address different parts of the Field Service model. Work Types can standardize the requirements but do not replace the underlying Skill and Service Resource Skill records. Routing rules and Work Order statuses do not represent expertise.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Resources — Skills; Skill Requirements; Service Resource Skills.

The correct configuration is Service Territories sized to fewer than about 50 resources. Scheduling and optimization quality improves when territories are kept within practical resource and appointment volumes. Splitting 140 resources into three territories yields roughly 46–47 resources per territory and approximately 800 appointments per day if demand is balanced.

In scheduling design, it is important to distinguish eligibility from preference. Work Rules filter candidates that do not satisfy hard constraints such as territory, availability, skills, or boolean conditions, while Service Objectives rank the remaining options. Dispatcher Console actions then use that policy logic to place, move, or dispatch appointments in a controlled way.

The alternatives address different parts of the Field Service model. Two territories would leave about 70 resources in each, while polygons inside one very large territory do not reduce the number of resources the scheduling engine must consider.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Service Territory design; optimization scalability; dispatcher performance.

Skill Requirements, Articles, and Products Required is the appropriate Field Service design. Work Types are reusable job templates. They directly associate the skills required to perform the work, the Knowledge articles that guide technicians, and the products expected for execution.

The Field Service data model separates the service requirement from its individual tasks and visits. A Work Order represents the overall job, Work Order Line Items represent component-level or task-level work, and Service Appointments represent the scheduled field visits used to execute that work. Choosing the correct level preserves accurate history, pricing, inventory, and scheduling.

The alternatives address different parts of the Field Service model. Service Resources are selected later by scheduling, and Service Appointments may be generated from work using a Work Type but are not one of the three supporting objects identified by the question.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Work Orders — Work Types; Skill Requirements; Knowledge Articles; Products Required.

The requirement is best implemented with one Work Order and one Service Appointment assigned to the Crew-type Service Resource. The Service Crew is represented for scheduling by a Service Resource whose Resource Type is Crew. Assigning that resource to the appointment allows the two active crew members to participate together in the same visit.

For resource design, the consultant should model the real operational constraint at the correct layer: skills for expertise, capacity for outsourced workload, crew membership for coordinated teams, Operating Hours and absences for availability, and permission sets for user capabilities. Mixing these concepts leads to inaccurate scheduling behavior and unnecessary customization.

The alternatives address different parts of the Field Service model. Assigning directly to the Service Crew record or creating separate appointments for each member bypasses the standard crew scheduling model.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Resources — Service Crews; Crew-type Service Resource; Assigned Resources.

For this scenario, Salesforce Field Service should use the crew-specific scheduling behavior that ignores individual Preferred Resource scoring for active crew members. When a technician is an active member of a Service Crew, scheduling evaluates the crew as the schedulable unit rather than independently applying individual preferred-resource scoring to that member. This is an important design consideration when crew membership is used.

The Field Service resource model separates the person or workforce unit from the qualifications, territory memberships, capacity, absences, and crew relationships used by scheduling. A Service Resource can therefore be evaluated consistently by the scheduling engine without embedding workforce logic directly in Work Orders or Service Appointments.

The alternatives address different parts of the Field Service model. Capacity-based scheduling and recommended crew size are different concepts, and a resource may participate in different crews at different nonoverlapping times.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Resources — Service Crews; active Crew Members; resource preferences.

The correct configuration is separate Work Orders or separate Work Order Line Items with their own Service Appointments. Independent handling requires each Asset ' s work to have an independently schedulable Service Appointment. This can be achieved with separate Work Orders and appointments or with one Work Order containing Asset-specific line items, each with its own appointment.

Good Work Order design also preserves the distinction between planned work and execution results. Products Required, requirements, and task structure should be established before service; Products Consumed, actual times, signatures, and completion statuses then record what actually happened in the field.

The alternatives address different parts of the Field Service model. A single parent-level appointment would combine the Assets into one scheduling unit and would not let each container ' s service be handled independently.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Work Orders — Assets; Work Orders; Work Order Line Items; independent appointments.

The requirement is best implemented with a Product Request with Product Request Line Items. A Product Request represents the overall inventory demand and each Product Request Line Item specifies an individual product and quantity. This is the standard workflow when technician stock must be replenished from another Location.

Using the standard inventory objects keeps quantity, location, serial number, price, and service history aligned. Custom fields or improvised notes may capture text, but they do not participate in the native stock, fulfillment, consumption, and reporting processes that Field Service provides.

The alternatives address different parts of the Field Service model. Shipments and Product Transfers may be used later in fulfillment, but they do not replace the initial request record that expresses the demand.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Inventory — Product Requests; Product Request Line Items; inventory replenishment.

the Candidates/Get Candidates action is the appropriate Field Service design. Get Candidates evaluates qualified resources and time slots under the active Scheduling Policy and exposes the relative effect of Service Objectives on the candidate options. This is the appropriate place to inspect objective scoring.

Salesforce Field Service treats the Service Appointment as the primary unit of scheduling. Scheduling Policies combine Work Rules, which determine whether a resource or time slot is valid, with Service Objectives, which score valid alternatives against business priorities. The selected configuration therefore has to operate at the scheduling layer rather than merely changing descriptive fields on the parent Work Order.

The alternatives address different parts of the Field Service model. Bulk dispatch and the general Dispatcher Console focus on operational scheduling, while Book Appointment emphasizes bookable slots rather than explaining candidate objective scores.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Get Candidates; Service Objective scores; Scheduling Policies.

The correct configuration is Customer First and Soft Boundaries. Customer First emphasizes preferred resources and prompt service while still considering efficiency. Soft Boundaries applies similar customer-oriented objectives but permits appropriate resource sharing across territory boundaries, which can improve coverage.

Salesforce Field Service treats the Service Appointment as the primary unit of scheduling. Scheduling Policies combine Work Rules, which determine whether a resource or time slot is valid, with Service Objectives, which score valid alternatives against business priorities. The selected configuration therefore has to operate at the scheduling layer rather than merely changing descriptive fields on the parent Work Order.

The alternatives address different parts of the Field Service model. High Intensity prioritizes throughput during heavy demand, and Emergency Policy is designed for urgent emergency work rather than normal preferred-resource commitments.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Standard Scheduling Policies; Customer First; Soft Boundaries.

The requirement is best implemented with Drip Feed dispatch. Drip Feed controls how many future Service Appointments are released to each technician. Setting the quantity to the required number keeps the technician queue small and automatically dispatches the next eligible appointment as current work is completed, canceled, or cannot be completed.

In scheduling design, it is important to distinguish eligibility from preference. Work Rules filter candidates that do not satisfy hard constraints such as territory, availability, skills, or boolean conditions, while Service Objectives rank the remaining options. Dispatcher Console actions then use that policy logic to place, move, or dispatch appointments in a controlled way.

The alternatives address different parts of the Field Service model. Manual dispatch creates avoidable administrative work, while ordinary auto-dispatch does not by itself provide the same controlled queue depth and protection from frequent schedule changes.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Drip Feed; automated dispatch; mobile appointment visibility.

The requirement is best implemented with one Service Appointment per Work Order Line Item with bulk scheduling. Each server-installation step has independent skill requirements, so each line item should have its own appointment. Bulk scheduling can then assign the same or different resources according to qualification and availability.

In scheduling design, it is important to distinguish eligibility from preference. Work Rules filter candidates that do not satisfy hard constraints such as territory, availability, skills, or boolean conditions, while Service Objectives rank the remaining options. Dispatcher Console actions then use that policy logic to place, move, or dispatch appointments in a controlled way.

The alternatives address different parts of the Field Service model. A single Work Order-level appointment would force both tasks into one scheduling unit, while a Same Start dependency introduces a simultaneity requirement that the scenario does not state.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Work Order Line Item appointments; bulk scheduling; skill-based assignment.

Earliest Start Permitted and Due Date is the appropriate Field Service design. These fields define the internal scheduling window that represents when the appointment may begin and the latest time by which it should be completed. They are the Service Appointment fields most directly aligned with SLA constraints.

Operationally, the goal is to preserve schedule integrity while minimizing manual intervention. Field Service should be allowed to use the standard scheduling engine wherever possible so that resource availability, travel, appointment constraints, priorities, and territory context remain consistent across manual and automated scheduling actions.

The alternatives address different parts of the Field Service model. Scheduled Start/End are scheduling outcomes, Actual Start/End record execution, and Arrival Windows are customer-facing arrival expectations rather than the core SLA boundaries.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Service Appointment constraints; Earliest Start Permitted; Due Date.

75 Contractor licenses and 25 Contractor Plus licenses is the appropriate Field Service design. The 75 field-only contractors need standard contractor capabilities for Work Orders, Assets, mobile work, and collaboration. The 25 contractors who also participate in sales and scheduling need the broader Contractor Plus capability set.

With private organization-wide defaults, Field Service can use automatic sharing, User Territories, territory public groups, and assignment relationships to expose the operational records needed by technicians and dispatchers. These sharing mechanisms are distinct from the permissions that control whether a user can configure Field Service or use a particular application capability.

The alternatives address different parts of the Field Service model. Giving Contractor Plus to all 100 users would over-license the field-only group, while basic Contractor access would not align with the expanded scheduling and sales responsibilities of the remaining 25.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Permissions and Sharing — Contractor and Contractor Plus licensing; external Field Service users.

The requirement is best implemented with Operating Hours on the Account. The time restriction belongs to the customer, so Account Operating Hours are the correct representation of when service can be performed at that customer site. Scheduling can then respect the customer-specific availability window.

Operationally, the goal is to preserve schedule integrity while minimizing manual intervention. Field Service should be allowed to use the standard scheduling engine wherever possible so that resource availability, travel, appointment constraints, priorities, and territory context remain consistent across manual and automated scheduling actions.

The alternatives address different parts of the Field Service model. Service Territory and Service Territory Member Operating Hours describe resource availability; placing the restriction there would incorrectly constrain other customers or technicians.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Account Operating Hours; customer availability; scheduling constraints.

For this scenario, Salesforce Field Service should use a Maintenance Plan. Maintenance Plans are the native Field Service mechanism for recurring preventive work. They can associate Assets, Work Types, frequencies, generation timeframes, and Work Order/Service Appointment generation so service is created before predictable failures or at regular intervals.

Maintenance Plans are the native Field Service framework for recurring preventive service. They combine Assets, Work Types, recurrence, generation timeframes, and Work Order or Service Appointment generation so that future work can be created in a controlled and repeatable way.

The alternatives address different parts of the Field Service model. Work Types describe how a job is performed but do not create a recurrence calendar; Path and custom process automation are not substitutes for the native maintenance framework.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Configuring Maintenance Plans — Maintenance Plans; recurring maintenance; Maintenance Assets.

Customer First and Soft Boundaries is the appropriate Field Service design. Customer First emphasizes preferred resources and prompt service while still considering efficiency. Soft Boundaries applies similar customer-oriented objectives but permits appropriate resource sharing across territory boundaries, which can improve coverage.

Salesforce Field Service treats the Service Appointment as the primary unit of scheduling. Scheduling Policies combine Work Rules, which determine whether a resource or time slot is valid, with Service Objectives, which score valid alternatives against business priorities. The selected configuration therefore has to operate at the scheduling layer rather than merely changing descriptive fields on the parent Work Order.

The alternatives address different parts of the Field Service model. High Intensity prioritizes throughput during heavy demand, and Emergency Policy is designed for urgent emergency work rather than normal preferred-resource commitments.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Standard Scheduling Policies; Customer First; Soft Boundaries.

For this scenario, Salesforce Field Service should use Field History Tracking on Assets. Field History Tracking records changes to selected Asset fields with timestamps, user information, and prior/new values where supported. Enabling it on lifecycle fields such as Status and location-related attributes gives managers an audit trail for a specific installed component.

Asset relationships and hierarchy fields provide different views of the installed base. Parent and Root Asset fields model structural hierarchy, while Asset Relationship records can model replacement, upgrade, or other lifecycle relationships. Field History Tracking complements those relationships by auditing changes to selected Asset fields over time.

The alternatives address different parts of the Field Service model. A Work Order related list shows service activity but not every field change, while custom tracking fields duplicate native auditing capability.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Assets — Assets; Field History Tracking; lifecycle audit.

The requirement is best implemented with Field Service Admin Permissions. These dispatchers are not only scheduling work; they are creating territories, defining Scheduling Policies, and controlling configuration settings. Those are administrative capabilities and require Field Service Admin Permissions in addition to dispatcher access.

When a requirement concerns a lifecycle action such as status change, a license concern, or territory visibility, the configuration should be placed in the corresponding security layer rather than simulated through record ownership changes or broad administrative access.

The alternatives address different parts of the Field Service model. Mobile and Scheduling licenses support different personas and do not grant the configuration authority described in the scenario.

This approach follows least-privilege design and keeps access changes maintainable as resources, territories, assignments, or user responsibilities change.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Permissions and Sharing — Field Service Admin and Dispatcher permissions; configuration access.

The requirement is best implemented with the Match Boolean Work Rule for Active Resources. A Match Boolean rule can require the Service Resource Active flag to be true, filtering inactive resources out of candidate evaluation while preserving their historical records.

Salesforce Field Service treats the Service Appointment as the primary unit of scheduling. Scheduling Policies combine Work Rules, which determine whether a resource or time slot is valid, with Service Objectives, which score valid alternatives against business priorities. The selected configuration therefore has to operate at the scheduling layer rather than merely changing descriptive fields on the parent Work Order.

The alternatives address different parts of the Field Service model. Preferred and Required Resources model preferences, while Match Fields compares data values but is not the standard Active-resource boolean control.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Match Boolean Work Rule; Active Resources; Scheduling Policies.

The correct configuration is Work Order Line Items, each with its own Service Appointment. Each task must retain its own completion, inventory, pricing, and scheduling information. A Work Order Line Item provides the task record, and a child Service Appointment allows that task to be scheduled to the same or a different technician as required.

Good Work Order design also preserves the distinction between planned work and execution results. Products Required, requirements, and task structure should be established before service; Products Consumed, actual times, signatures, and completion statuses then record what actually happened in the field.

The alternatives address different parts of the Field Service model. Custom objects are unnecessary, and using Service Appointments as the parent of task records reverses the standard Field Service data model.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Work Orders — Work Order Line Items; child Service Appointments; task scheduling.

The correct configuration is Service Territory Member. The Service Territory Member record links a Service Resource to the territory in which the resource works. That relationship is fundamental to territory-based scheduling and sharing calculations for appointments assigned to the resource.

Field Service access combines Salesforce object permissions with Field Service permission-set licenses and managed sharing. The correct design applies least privilege: technicians, agents, dispatchers, contractors, and administrators should receive only the capabilities required for their operational persona.

The alternatives address different parts of the Field Service model. User Territory links users such as dispatchers to territory access groups; it serves a different persona and sharing purpose than the resource-territory membership relationship.

This approach follows least-privilege design and keeps access changes maintainable as resources, territories, assignments, or user responsibilities change.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Permissions and Sharing — Service Territory Members; resource-territory sharing.

For this scenario, Salesforce Field Service should use Resource Preferences together with Required and Excluded Resource Work Rules. Customer feedback can be translated into Resource Preferences on Accounts or Work Orders. Required and Excluded preferences are then enforced by the corresponding Work Rules in the Scheduling Policy so unsuitable technicians are filtered and required technicians are honored.

Operationally, the goal is to preserve schedule integrity while minimizing manual intervention. Field Service should be allowed to use the standard scheduling engine wherever possible so that resource availability, travel, appointment constraints, priorities, and territory context remain consistent across manual and automated scheduling actions.

The alternatives address different parts of the Field Service model. Business objectives rank otherwise valid candidates; they are not substitutes for Required/Excluded filtering. Preferences also belong on customer/work records rather than on the Service Resource itself.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Resource Preferences; Required Resources; Excluded Resources.

Street Level Routing and Default Travel Speed is the appropriate Field Service design. Street Level Routing uses road-network information to produce more realistic point-to-point travel estimates. Default Travel Speed is also important for aerial routing and acts as the fallback when a resource-specific speed is not configured.

Salesforce Field Service treats the Service Appointment as the primary unit of scheduling. Scheduling Policies combine Work Rules, which determine whether a resource or time slot is valid, with Service Objectives, which score valid alternatives against business priorities. The selected configuration therefore has to operate at the scheduling layer rather than merely changing descriptive fields on the parent Work Order.

The alternatives address different parts of the Field Service model. Actual Travel Time records what happened after travel, while Minimize Travel is an objective and does not correct an unrealistic underlying estimate.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Street Level Routing; Default Travel Speed; travel-time accuracy.

The correct configuration is Quantity Unit of Measure configured for meters. Field Service inventory supports units of measure on products and downstream inventory records. Adding or using Meters as the Quantity Unit of Measure lets technicians record cable requirements and consumption in the metric unit consistently.

Field Service inventory distinguishes the product catalog from stock at a location and from inventory movement or consumption. Products define what the item is, Product Items represent how much of that Product is at a specific Location, Products Required describe planned needs, and Products Consumed record what was actually used during execution.

The alternatives address different parts of the Field Service model. Price Book configuration governs commercial pricing and organization locale governs regional formatting; neither changes the physical inventory measurement unit.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Inventory — Quantity Unit of Measure; Products; Product Items; consumed quantities.

For this scenario, Salesforce Field Service should use the Work Order-to-Asset relationship. Assets represent specific customer-installed products. Relating a Work Order to the Asset records the service history against the exact installed unit and supports lifecycle, maintenance, and reliability analysis.

An Asset represents a customer-specific installed instance of a Product, which is why lifecycle, service history, hierarchy, installation dates, replacements, and component relationships should be modeled on Assets rather than on generic Product records. Work Orders can then reference the exact installed equipment being serviced.

The alternatives address different parts of the Field Service model. Products are catalog definitions rather than the customer-specific installed instances that need a service history.

This keeps the installed-base history tied to the exact customer equipment rather than only to the generic product definition, which is essential for maintenance and lifecycle reporting.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Assets — Assets; Work Orders; installed-base service history.

a Product Request related to the Work Order is the appropriate Field Service design. When damaged van stock must be replaced for an upcoming job, the Product Request should be tied to the Work Order (or a line item where appropriate) so inventory personnel can see the job dependency and fulfill the required part.

Using the standard inventory objects keeps quantity, location, serial number, price, and service history aligned. Custom fields or improvised notes may capture text, but they do not participate in the native stock, fulfillment, consumption, and reporting processes that Field Service provides.

The alternatives address different parts of the Field Service model. Work Types are templates, Service Reports document completed work, and Service Appointments represent the visit rather than the primary transaction for requesting job inventory.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Inventory — Product Requests; Work Orders; van-stock replenishment.

The correct configuration is an Excluded Resource preference on the Account. An Account-level Excluded Resource preference records that the customer should not receive that technician on future work. The Scheduling Policy ' s Excluded Resources rule can then prevent the technician from being considered.

Operationally, the goal is to preserve schedule integrity while minimizing manual intervention. Field Service should be allowed to use the standard scheduling engine wherever possible so that resource availability, travel, appointment constraints, priorities, and territory context remain consistent across manual and automated scheduling actions.

The alternatives address different parts of the Field Service model. Simply removing Preferred status would stop favoring the technician but would not prohibit assignment, and moving territories would affect unrelated customers.

The recommended choice also keeps the decision inside the native scheduling framework, so future optimization and dispatcher actions evaluate the same constraints consistently instead of relying on manual workarounds.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Resource Preferences; Excluded Resources; Account-level preferences.

the Exclude Technician from Geolocation Tracking permission is the appropriate Field Service design. A dedicated system permission can be placed in a permission set and assigned only to contractors who should not be tracked. This keeps the organization-wide mobile tracking configuration enabled for full-time technicians.

When comparing Salesforce Mobile with Field Service Mobile, the latter should be treated as an operational field-work client rather than a generic CRM client. Its offline capabilities, appointment-centric experience, signature/report functions, geolocation controls, and technician-specific actions are the features that should drive the configuration decision.

The alternatives address different parts of the Field Service model. Turning off the global tracking setting affects everyone, and profile geocoding or a zero frequency is not the supported per-user exclusion control.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Configuring Mobility — Field Service Mobile geolocation; exclusion permission.

The correct configuration is serialized inventory for the traceable product and unserialized inventory for disposable kits. The customer product needs a unique identity from factory to installed site, so each unit should be serialized. Disposable installation kits only need quantity tracking and consumption, making ordinary unserialized inventory more appropriate.

Inventory design should also preserve pricing and traceability. Price Books and Price Book Entries supply commercial pricing, while serialized inventory gives unit-level identity when individual items must be tracked. Product Requests and Product Transfers manage replenishment and movement rather than the underlying job structure.

The alternatives address different parts of the Field Service model. Serializing the kits adds unnecessary administrative overhead, while treating the product as unserialized would lose the required unit-level traceability.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Inventory — Serialized inventory; Product Items; disposable inventory.

The correct configuration is a Work Order creation action from the Entitlement. The agent has already established service eligibility through the Entitlement. Creating the Work Order from that context preserves the entitlement relationship and allows Work Order SLA and milestone processing to use the appropriate support agreement.

The Field Service data model separates the service requirement from its individual tasks and visits. A Work Order represents the overall job, Work Order Line Items represent component-level or task-level work, and Service Appointments represent the scheduled field visits used to execute that work. Choosing the correct level preserves accurate history, pricing, inventory, and scheduling.

The alternatives address different parts of the Field Service model. A Case can also relate to a Work Order, but the decisive process point in this scenario is the validated Entitlement rather than a generic Contact or Opportunity.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Work Orders — Entitlements; Work Order creation; SLA context.

a Service Crew is the appropriate Field Service design. A Service Crew models multiple technicians who need to work as one coordinated schedulable unit. The crew can combine specialized skills and is represented in scheduling by a Crew-type Service Resource.

Salesforce favors reusable resource metadata over one-off record manipulation. When resource qualifications and availability are modeled correctly, the same information can support candidate selection, optimization, dispatching, reporting, and mobile execution without duplicating logic on individual jobs.

The alternatives address different parts of the Field Service model. Required Skills alone do not create a two-person team, and separate crews or separate independent appointments are unnecessary when the resources must perform the same job together.

This keeps the workforce model reusable across scheduling, dispatching, mobile execution, and reporting and avoids encoding resource logic in individual work records.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Resources — Service Crews; Crew Members; multi-technician work.