Free Practice Questions for Salesforce FS-Con-101 Exam

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 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 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.

The consultant should distinguish recurrence from job definition. A Work Type describes how a recurring job is performed, while the Maintenance Plan determines when and how future work is generated. Work Order and Service Appointment generation methods then determine whether Assets are consolidated into one visit or separated into multiple jobs.

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.

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.

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 the Match Territory Work Rule. Match Territory filters candidate Service Resources so that only members of the Service Appointment ' s Service Territory qualify. It should be included in the Scheduling Policy when work must remain within territory membership.

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. Resource Availability checks whether a candidate can work at the required time; it does not establish that the resource belongs to the same territory.

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

Work Order Line Items for operations and one Service Appointment for the visit is the appropriate Field Service design. Each SOP operation should be represented as a task-level line item so it can have its own status and notes. The single Service Appointment represents the one onsite visit during which all operations are completed.

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. Using multiple appointments would imply multiple visits, while using Work Orders for each operation would fragment one preventive-maintenance job into unnecessarily separate service records.

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; Service Appointments; SOP execution.

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.

For this scenario, Salesforce Field Service should use custom Asset reports using Parent Asset and Root Asset. Parent Asset and Root Asset expose the hierarchical position of an installed component. Custom reporting can reference these fields to analyze Assets while preserving hierarchy context.

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. The interactive View Asset Hierarchy action is useful for navigation but is not the requested reporting solution, and standard Asset reports do not expose all hierarchy fields in the same way.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Assets — Asset hierarchy reporting; Parent Asset; Root Asset.