Free Practice Questions for Salesforce FS-Con-101 Exam

The correct configuration is Service Report Language on the Work Order. The Work Order-level language field controls the language used for the Service Report generated for that work and its related appointments or line items. This lets the technician produce customer-facing documentation in the appropriate language.

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. Changing the organization or technician user language is too broad and does not scale to customers who require different report languages.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Configuring Mobility — Service Report Language; Work Orders; multilingual reports.

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.

two Service Appointments assigned to two different resources is the appropriate Field Service design. Because the technicians can arrive at different times, their work must be independently schedulable. Separate Service Appointments allow each technician to have independent timing, travel, and assignment while still supporting the same overall job.

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 single appointment with two resources is more appropriate for a crew-style simultaneous visit, and Required Resources on one appointment would not provide separate scheduling windows.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Multiple Service Appointments; independent resource scheduling.

For this scenario, Salesforce Field Service should use Asset Relationships visible through Primary Assets and Related Assets. Asset Relationship records capture replacement, upgrade, and related lifecycle links between specific Assets. The relationships are viewed on the Asset through the Primary Assets and Related Assets related lists.

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. Field History Tracking only audits field changes and Product Requests manage inventory demand; neither models the relationship between an old Asset and its replacement.

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

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 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 new Service Appointment on the original Work Order or a new Work Order plus Service Appointment. Each physical return visit should be represented separately so the first visit remains part of the historical record. Continuing the same job can use another appointment on the existing Work Order; separately managed follow-up work can use a new Work Order and appointment.

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. Rescheduling the original appointment would overwrite the timing representation of the first visit and reduce the accuracy of visit-history reporting.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Work Orders — Return visits; multiple Service Appointments; service history.

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 requirement is best implemented with Products Required and Skill Requirements. A first-time fix depends on sending a technician who has both the required expertise and the expected parts. Skill Requirements filter or rank qualified resources, while Products Required communicate the material expected for the job.

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. Products Consumed records what was actually used after execution; estimated duration and SLA information do not ensure that the technician has the required competence and inventory.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Work Orders — Work Orders; Products Required; Skill Requirements; first-time fix.

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.