Free Practice Questions for Salesforce FS-Con-101 Exam

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 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 Cannot Complete plus a new Service Appointment on the same Work Order. The technician made the visit but could not perform the work because the customer was unavailable. Marking the original appointment Cannot Complete preserves the failed-visit history, and a new appointment records the follow-up visit under the same underlying Work Order.

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. In Progress would misstate the final outcome, Complete would imply successful service, and a new Work Order is unnecessary because the service requirement itself has not changed.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Work Orders — Service Appointment lifecycle; Cannot Complete; follow-up visits.

For this scenario, Salesforce Field Service should use Territory and Resources filters. Filtering by Territory isolates the geographic operating area and its local scheduling context, while filtering by Resources narrows the Gantt to the technicians the dispatcher is actively managing.

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. Hours changes the visible time range but does not isolate the multi-time-zone workforce, and Skills filtering serves qualification searches rather than general console simplification.

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 — Dispatcher Console filters; Territory; Resources.

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.

The correct configuration is Products Required on the Work Type. A Work Type acts as a reusable template for recurring service. Adding standard parts to its Products Required related list lets those requirements flow to Work Orders or Work Order Line Items when the Work Type is applied.

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. Product Items show stock at a Location, and custom Flow or layout fields do not replace the standard reusable Products Required model.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Inventory — Work Types; Products Required; inventory planning.

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.

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.

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.

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.