Free Practice Questions for the Salesforce Field Service Lightning program FS-Con-101 Exam (2026 Updated)

Customer First and Soft Boundaries is the appropriate Field Service design. Customer First emphasizes preferred resources and prompt service while still considering efficiency. Soft Boundaries applies similar customer-oriented objectives but permits appropriate resource sharing across territory boundaries, which can improve coverage.

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. High Intensity prioritizes throughput during heavy demand, and Emergency Policy is designed for urgent emergency work rather than normal preferred-resource commitments.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Standard Scheduling Policies; Customer First; Soft Boundaries.

a Product Request related to the Work Order is the appropriate Field Service design. When damaged van stock must be replaced for an upcoming job, the Product Request should be tied to the Work Order (or a line item where appropriate) so inventory personnel can see the job dependency and fulfill the required part.

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 are templates, Service Reports document completed work, and Service Appointments represent the visit rather than the primary transaction for requesting job inventory.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Inventory — Product Requests; Work Orders; van-stock replenishment.

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.

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 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 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 Company colors. Field Service Mobile supports native branding through configurable UI colors in Field Service Mobile Settings. This allows the mobile experience to reflect the organization ' s visual identity without unsupported stylesheet customization.

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. Company address is informational, arbitrary style sheets are not the native branding mechanism, and the standard configuration represented by the available choices is company color customization.

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 branding; mobile settings; UI colors.

The correct configuration is the correct Field Service Mobile action placement and supported action type. Actions can appear in Salesforce Mobile but not Field Service Mobile when they are not placed in the required publisher-action section or when an unsupported legacy Lightning Component action type is used. Field Service Mobile has its own supported action model.

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. Mobile navigation settings do not substitute for the page-layout action configuration, and the mobile client does not automatically surface every action that appears elsewhere in Salesforce.

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 actions; page layouts; supported quick-action types.

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.

For this scenario, Salesforce Field Service should use Emergency scheduling. Emergency scheduling is designed to insert urgent work into an active day, identify an appropriate nearby technician, and dispatch the appointment even when normal schedules are already occupied.

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. Get Candidates is a general candidate-evaluation action, Appointment Booking is aimed at finding bookable slots, and Fill-In Schedule uses gaps for nonurgent work rather than interrupting the plan for an emergency.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Emergency scheduling; Dispatcher Console; urgent dispatch.

member-specific Operating Hours is the appropriate Field Service design. 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.

native signature capture and offline Flow support is the appropriate Field Service design. Field Service Mobile is purpose-built for technicians. It supports onsite customer signatures and can prime supported Field Service flows and data for offline execution so work can continue when connectivity is unreliable.

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. A customized navigation menu or a basic agenda view is not the primary Field Service-specific advantage represented by these choices.

Using the supported mobile mechanism also reduces maintenance risk and keeps the technician experience compatible with Field Service synchronization, security, and offline behavior.

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; signatures; offline flows.

Status Transition restrictions based on Profile is the appropriate Field Service design. Field Service Status Transitions can be configured so only selected user profiles are allowed to move an appointment into a particular status such as Canceled. This supports the requirement that managers, but not technicians, perform the cancellation.

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. Resource Type and Role describe other aspects of the user/resource model, and permission sets do not replace the profile-based restriction available in the status-transition configuration.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Permissions and Sharing — Service Appointment Status Transitions; profile restrictions.

The correct configuration is adjusting the Scheduling Policy, Knowledge, and Dispatching. Reducing mean-time-to-service requires quicker and better assignment, faster technician execution, and timely release of work. Scheduling Policy adjustments can prioritize earlier service, Knowledge reduces diagnosis time, and effective dispatching gets the appointment to the technician promptly.

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. Customer Entitlements define service eligibility and SLA commitments but do not by themselves shorten the operational path from request to service completion.

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; Knowledge; dispatching; service efficiency.

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.

Candidates/Get Candidates, Bulk Schedule, and Schedule is the appropriate Field Service design. These actions use the Scheduling Policy to evaluate resource eligibility and scheduling quality. Candidates exposes options, Bulk Schedule handles multiple selected appointments, and Schedule automatically places an individual appointment under policy logic.

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. Change Status to Dispatch does not perform policy-based scheduling, and manually editing a resource assignment bypasses the scheduling engine ' s candidate evaluation.

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 scheduling actions; Scheduling Policies.

For this scenario, Salesforce Field Service should use Service Territory and Scheduling Policy. The Service Territory defines the population of resources and appointments being optimized, while the Scheduling Policy supplies the Work Rules and Service Objectives used to evaluate and rank scheduling alternatives.

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. Work Types affect job requirements but are not required optimization-job objects, and polygons help with geography but do not replace the optimization scope or policy.

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 jobs; Service Territories; Scheduling Policies.

For this scenario, Salesforce Field Service should use the required Salesforce Classic Publisher action placement. For the action type described, Field Service Mobile depends on the action being present in the appropriate publisher-action section of the assigned page layout. An action can therefore appear in Salesforce Mobile yet remain unavailable in Field Service Mobile if it is placed incorrectly.

Mobile configuration should reduce technician data entry and expose only the actions and information needed at the point of service. The strongest designs reuse the Work Order and Service Appointment data model, launch guided actions from the appropriate parent record, and keep customer-facing outputs such as signatures and Service Reports within the native Field Service workflow.

The alternatives address different parts of the Field Service model. Create-a-Record actions are supported, and App Extensions are a different extension mechanism rather than the cause of a standard page-layout quick action being absent.

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 actions; Classic Publisher Quick Actions.

The correct configuration is the Work Order Line Items related list on the Work Order page layout. Exposing the standard related list gives technicians direct task-level visibility through the native Work Order mobile experience and keeps the solution aligned with the standard Field Service data model.

Mobile configuration should reduce technician data entry and expose only the actions and information needed at the point of service. The strongest designs reuse the Work Order and Service Appointment data model, launch guided actions from the appropriate parent record, and keep customer-facing outputs such as signatures and Service Reports within the native Field Service workflow.

The alternatives address different parts of the Field Service model. Visualforce, custom Lightning components, or report-chart links add complexity when the requirement can be satisfied by the standard page-layout relationship.

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; Work Order page layouts; Work Order Line Items.

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.

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.

For preventive maintenance, the objective is to create service before predictable failure while preserving accurate Asset-level history. Using the standard maintenance framework also allows recurring work to participate naturally in scheduling, inventory planning, service reporting, and SLA processes.

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 Arrival Window Start and Arrival Window End. Arrival windows are the customer-facing expectation for when a technician is expected to arrive. They provide a practical range while allowing dispatchers operational flexibility if travel or earlier appointments change during the day.

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 and Scheduled End are internal scheduling values and may move as the schedule is optimized, so sharing them as hard customer commitments is usually inappropriate.

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 arrival windows; customer communications.

The requirement is best implemented with Product Item. A Product Item represents a specific Product at a specific inventory Location and records quantity on hand. It is therefore the correct object for understanding distribution of an expensive part across warehouses, technician vans, and other inventory locations as stock is reused and replenished.

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. Assets represent installed customer equipment, Maintenance Plans create recurring work, and Entitlements govern service eligibility rather than stock distribution.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Inventory — Product Items; Locations; inventory quantities and transactions.

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.

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.

The requirement is best implemented with a Work Order Quick Action that launches a Flow. A single Flow can collect the technician ' s required information once and update the Work Order, related Service Appointment, and Case in one guided mobile interaction.

Mobile configuration should reduce technician data entry and expose only the actions and information needed at the point of service. The strongest designs reuse the Work Order and Service Appointment data model, launch guided actions from the appropriate parent record, and keep customer-facing outputs such as signatures and Service Reports within the native Field Service workflow.

The alternatives address different parts of the Field Service model. Multiple actions would force duplicate entry, Process Builder is not the mobile interaction layer, and a custom component adds code where a standard Flow action is sufficient.

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; Quick Actions; Flow; cross-record updates.

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.

The correct configuration is a Quick Action that creates a Service Appointment. The unfinished work remains part of the existing Work Order; only a new visit is required. A mobile Quick Action can create another Service Appointment against that Work Order so the follow-up can be scheduled and tracked independently.

Mobile configuration should reduce technician data entry and expose only the actions and information needed at the point of service. The strongest designs reuse the Work Order and Service Appointment data model, launch guided actions from the appropriate parent record, and keep customer-facing outputs such as signatures and Service Reports within the native Field Service workflow.

The alternatives address different parts of the Field Service model. Creating a new Work Order would fragment the original service requirement, while Visualforce, custom buttons, or macros add unnecessary customization when a standard mobile action satisfies the requirement.

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 Quick Actions; follow-up Service Appointments.

The correct configuration is the Field Service Agent permission-set license. The call-center persona books appointments and works with customer service records without acting as a technician or full dispatcher. The Agent license aligns with that booking role and provides the appointment-creation and booking capabilities required by service representatives.

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. Resource licensing is for mobile workers, Dispatcher licensing is for users managing the scheduling console, and Admin access would grant substantially more configuration authority than necessary.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Permissions and Sharing — Field Service personas; Agent permissions; least privilege.

For this scenario, Salesforce Field Service should use a Resource Absence plus Fix Overlaps. Recording the sickness as a Resource Absence accurately removes the technician ' s availability. Fix Overlaps can then identify appointments that conflict with the absence and attempt to reschedule them to suitable resources under scheduling rules.

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. Changing the global policy to High Intensity does not model the absence, and manually dragging or calling customers creates avoidable administrative work before the scheduling engine is given a chance to resolve the disruption.

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 Absence; Fix Overlaps; disruption management.

For this scenario, Salesforce Field Service should use Products and Price Books. The consumed part is a Product, and pricing is supplied through Price Book Entries so the Product Consumed record can carry list price, unit price, discounts, and billing context.

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. Assets identify installed customer equipment, while Opportunity Line Items belong to the sales process and custom objects are unnecessary for standard Field Service part pricing.

The standard inventory model also keeps planned demand, stock position, movement, actual consumption, and pricing available for reporting without duplicating the same information in custom records.

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

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 requirement is best implemented with the Resource Availability Work Rule with break calculation. Lunch should be treated as part of resource availability so the scheduling engine can place work around the configured break. The Resource Availability rule is the scheduling-policy mechanism that considers operating hours, absences, travel, and breaks.

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. Operating Hours define broader working periods, while manually creating recurring appointments or absences for lunch adds avoidable maintenance and bypasses the intended break logic.

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 Availability Work Rule; breaks; resource availability.

The requirement is best implemented with a Quick Action that creates a Service Appointment. The unfinished work remains part of the existing Work Order; only a new visit is required. A mobile Quick Action can create another Service Appointment against that Work Order so the follow-up can be scheduled and tracked independently.

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. Creating a new Work Order would fragment the original service requirement, while Visualforce, custom buttons, or macros add unnecessary customization when a standard mobile action satisfies the requirement.

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 Quick Actions; follow-up Service Appointments.

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.

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.