Free Practice Questions for Salesforce FS-Con-101 Exam

For this scenario, Salesforce Field Service should use one Service Resource with the relevant permission-set licenses. One employee should be represented once as a Service Resource. Access to technician and dispatcher capabilities is then provided through the appropriate licenses and permission sets rather than by duplicating the person in the resource model.

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. Skills do not grant application access, and Resource Type is not a multi-value role mechanism for simultaneously defining separate dispatcher and technician identities.

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

The correct configuration is Work Order-specific Entitlement Processes and reusable Milestones. An Entitlement Process is created for one process type, such as Case or Work Order, and Work Order milestones can be configured in Setup. A Milestone definition can be reused in more than one entitlement process even though the processes themselves remain object-specific.

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 process does not simultaneously apply to both Cases and Work Orders simply because the same Milestone is used.

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 SLAs; Entitlement Process Type; Milestones.

The requirement is best implemented with High optimization runtime when priorities are similar and candidate counts are large. A longer runtime gives the optimizer more time to evaluate combinations. When many appointments have the same priority and each appointment has many qualifying resources, the search space expands and a higher runtime can improve schedule quality.

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. A blank Scheduling Policy is a configuration issue rather than a reason to spend more optimization time, and disabling travel/break calculations changes the model rather than increasing optimization complexity in the way described.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Optimization runtime; candidate volume; appointment priority.

For this scenario, Salesforce Field Service should use separate Work Orders for separate Price Books. A Work Order uses one Price Book. Work Order Line Items under that Work Order can only select products represented by Price Book Entries in the parent Work Order ' s Price Book. If required components exist only in different Price Books, separate Work Orders preserve standard pricing behavior.

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. Overriding a price cannot make an unavailable product eligible for selection, and Work Types do not provide an independent Price Book for each line item.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Inventory — Work Order pricing; Price Books; Work Order Line Items.

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 Time Sheet Entries related to Work Orders and Work Order Line Items. Time Sheets represent a resource ' s reporting period, while Time Sheet Entries capture individual blocks of labor. Standard associations let those entries be attributed to an overall Work Order or to a specific Work Order Line Item for task-level costing and reporting.

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. Assigned Resource belongs to the broader time-sheet/resource relationship, and Service Appointment is not one of the two standard work associations requested here.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Resources — Time Sheets; Time Sheet Entries; Work Orders; Work Order Line Items.

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.

The requirement is best implemented with a Capacity-Based Service Resource for the Contractor Manager. Capacity-based scheduling models an external provider as a pool of contracted work capacity rather than as named individual technicians. The Contractor Manager can represent the weekly 100-hour capacity and update the work after completion.

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. A Service Crew assumes known resources working together, while creating individual contractor technicians would add detail the stated operating model does not require.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Resources — Capacity-Based Service Resources; contractors; capacity scheduling.

For this scenario, Salesforce Field Service should use member-specific Operating Hours. A Service Territory Member can use Operating Hours that differ from the territory defaults. Because the member is one hour behind the territory, shifting the member ' s start and end times forward by one hour aligns effective availability without changing the entire territory.

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. Changing the territory affects every member, while changing the user time zone misrepresents the user ' s actual locale and is not the scheduling control intended for this requirement.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Resources — Service Territory Members; Operating Hours; time-zone scheduling.