Salesforce FS-Con-101 - Agentforce Field Service and Operations Consultant

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.

Knowledge Articles associated with Work Types, Work Orders, or Work Order Line Items is the appropriate Field Service design. Linking relevant Knowledge to the work context gives technicians job-specific procedures, specifications, and troubleshooting guidance. Work Types are especially useful because their associated articles can flow to recurring Work Orders and line items and be available in the Field Service mobile experience.

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. A generic Knowledge component or custom search action is less targeted, and deep linking between mobile apps does not solve offline contextual availability.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Configuring Mobility — Knowledge in Field Service; Work Types; mobile/offline access.

The correct configuration is a customer-specific Price Book containing all relevant products. A Work Order uses one Price Book, so the customer-specific book should contain both negotiated-price products and ordinary products that may appear on the same Work Order. This preserves standard Product selection and pricing on Work Order Line Items.

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 book containing only discounted items would make other required products unavailable through the normal pricing model, and a global book would not represent customer-specific negotiated prices.

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 pricing; customer Price Books; Price Book Entries.

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 correct configuration is automatic Price Book Entry population when consuming a Product Item under the Work Order price book. When the Work Order and the Product Item ' s Product use compatible Price Book context, the Product Consumed record can inherit or auto-populate the appropriate Price Book Entry, keeping inventory consumption aligned with service pricing.

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 do not combine consumed products across books, and Products Consumed are not added from a generic Price Book related list on the Work Order.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Inventory — Products Consumed; Product Items; Price Book Entries.

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 requirement is best implemented with Cases and Work Orders. The Case records the inbound technical-support interaction, while a related Work Order records the onsite physical service when dispatch is required. This preserves both contact-center and field-service histories under the standard service model.

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. Using only Cases loses the structured field-work model; using only Work Orders loses the original support interaction and case-management context.

This structure preserves a clean audit trail from the original service requirement through individual tasks and visits, which improves downstream reporting, pricing, inventory, and service-history accuracy.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Work Orders — Cases; Work Orders; contact-center-to-field-service process.

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.

For this scenario, Salesforce Field Service should use the standard Asset Install Date. An Asset represents the customer-installed product instance, and its standard Install Date records when that instance was installed. Reporting on this field directly answers how many products were installed during a selected period.

This distinction is important for reporting and maintenance because the organization often needs to know not merely what type of product was sold, but which serialized or installed unit changed status, location, parentage, or replacement state and which service work was performed against it.

The alternatives address different parts of the Field Service model. Field History Tracking audits changes rather than providing the primary installation date, Work Orders represent service activity, and a custom field on Products Consumed would duplicate a standard Asset capability.

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

Root Work Order and Root Work Order Line Item for multilevel hierarchies is the appropriate Field Service design. Root fields are most valuable when both Work Orders and Work Order Line Items have more than one hierarchy level because they provide direct visibility to the top-level record without navigating through intermediate parents.

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. With only a single hierarchy level, the immediate Parent fields already provide most of the relationship context and the Root fields add less value.

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 hierarchies; Work Order Line Item hierarchies; Root fields.