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

a separate Work Order Entitlement Process is the appropriate Field Service design. Entitlement Processes are object-specific. A Case process does not automatically govern a Work Order merely because the Work Order originated from the Case. The Work Order needs an applicable entitlement process of Work Order type so milestones can be instantiated and displayed.

Reusable configuration should be preferred over duplicating records or custom objects. Work Types can standardize duration, required skills, required products, and Knowledge, while the Work Order hierarchy and Work Order Line Item hierarchy are available when genuinely separate but related work must be represented.

The alternatives address different parts of the Field Service model. Adding the Lightning component alone does not create milestone instances, and sharing the Case entitlement does not make a Case process execute against Work Orders.

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 Entitlements; Entitlement Processes; Milestones.

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.

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.

The correct configuration is Signature Types and Signature Blocks on the Service Report Template. For multiple signatures, define the relevant Signature Types and place a separate Signature Block for each type on the Service Report Template. The technician can then collect the required approvals when the report is generated in Field Service Mobile.

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. Separate Service Reports, custom fields, or a custom Flow are unnecessary when the native Service Report signature model already supports multiple signature roles.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Configuring Mobility — Service Reports; Signature Types; Signature Blocks.

The correct configuration is Assets with a parent-child hierarchy. Serialized customer components should be represented as individual Assets related in an Asset hierarchy. Work Orders and Work Order Line Items can then reference the exact component that needs service while still preserving its relationship to the overall installed product.

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. Products describe catalog definitions, Orders describe commercial transactions, and Work Order hierarchies organize service activity rather than the physical installed-product structure.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Assets — Assets; Asset hierarchies; serialized components.

The correct configuration is Gantt Palettes. Palettes color-code Service Appointments according to selected field values, including numeric and currency values. A revenue field can therefore be mapped to a palette so dispatchers immediately see high-value appointments on the Gantt.

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. Field Sets control which data is displayed, Map Report Layers add geographic overlays, and Gantt Actions perform operations rather than continuously color-coding appointment value.

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; Gantt Palettes; appointment visualization.

The correct configuration is a Preferred Resource preference on the Account plus the Preferred Resource Service Objective. The Account-level preference establishes an ongoing customer-technician preference that can influence future work, while the Scheduling Policy objective gives that preference weight when ranking otherwise valid candidates.

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. Making the technician Required on one appointment is a one-off hard constraint and does not create the reusable customer preference required for subsequent service calls.

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; Preferred Resource objective; Account inheritance.

For this scenario, Salesforce Field Service should use one Product Item with serialized units in the related list. The locks are serialized inventory because every physical unit has a unique identifier. The Product Item represents the stock at the technician ' s van Location, and the Serialized Products related list stores each individual serial number.

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. A quantity-only Product Item would lose individual traceability, and serial numbers in Notes are unstructured and cannot participate properly in serialized-inventory transactions.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Inventory — Serialized Products; Product Items; van stock; serial-number tracking.

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 requirement is best implemented with Field Service automatic sharing for dispatched Service Appointments. With private OWD, enabling the Field Service setting to share dispatched appointments with assigned resources grants the technician access based on the Assigned Resource relationship and appointment lifecycle.

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. Changing ownership or maintaining custom sharing rules adds unnecessary automation, while User Territories are mainly used to give dispatchers and call-center users access to territory records.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Permissions and Sharing — Private OWD; automatic sharing; Assigned Resources.