#Salesforce Field Service35 人がディスカッション中

@Suresh G I'd hang the public holiday on the country's operating hours, not on the big regional territory.

Field Service stores a holiday on an Operating Hours record. The service territory points at those hours, and members inherit them unless that member has different hours of their own. One EURAFRIC territory with one operating hours record means every country under it shares the same closures. A holiday in France would also block Kenya.

I'd make each country its own service territory, under the region if you still want that hierarchy. Give each country its own operating hours and add that country's public holidays there. People stay members of the countries they can actually cover. Primary can be home, and a secondary membership is how someone in the region still picks up work elsewhere.

The service appointment needs to land on the country territory. Scheduling then uses that territory's hours, so the local holiday is unavailable time. Turn on Enhanced Scheduling and Optimization, otherwise the holiday shows on the calendar and the optimizer ignores it.

Personal days are a different record. Those go on the resource's own operating hours, not on the country. If a holiday repeats every year, keep the next occurrence on those operating hours, because scheduling follows the upcoming date.

The screenshot of the message didn't come through in your post, but "It looks like there was a problem" is Lightning's generic, unhandled-error message, so the text itself doesn't tell you the root cause. Because it is intermittent, the fastest route is to capture the underlying error the next time it happens and narrow down which layer is failing. 

1. Capture the real error. When the message appears, expand the "Show details"/"More details" link if present and copy the text and error ID. Also open the browser developer console (F12 > Console/Network) before reproducing; the failing request usually shows the real exception (for example a timeout, a limit, or an Apex/Flow error). 

2. Check whether it is a platform issue. Look at

for your instance at the time of the failures and search the Known Issues site for your feature (Reports, Service Reports, Document Builder). Intermittent errors that affect several users at the same time often line up with a performance incident or a known issue. 

3. If it's a standard Salesforce report: very large or complex reports (many rows, cross filters, many groupings, formulas, long date ranges) can hit the report run-time limit or fail intermittently under load. Try adding filters to reduce the data, running it in another browser/incognito with extensions disabled, and running it as another user with the same profile. 

4. If "generating reports" means Field Service service reports or generated documents (your tags mention Generate Document): check the template for large images, many related list sections or rich-text fields, and whether the failure is tied to specific work orders/service appointments with lots of related records, line items or attachments. Also check any Flow or Apex that runs when the report/document is created (Setup > Paused and Failed Flow Interviews, Apex exception emails, debug logs for an affected user). Testing the same record with a simpler template quickly shows whether the template is the cause. 

5. If you can reproduce it with the error ID, open a case with Salesforce Support and include the error ID, timestamp, user, instance and record Id. Support can look up the error ID in their logs. 

References: 

Salesforce Known Issues:

Salesforce Trust status:

Report limits, limitations and allocations:

Field Service service reports:

Assumption: without the screenshot, error details or confirmation of whether these are standard reports or Field Service service reports/documents, this is general troubleshooting guidance rather than a confirmed root cause. If you can share the full error text and which feature you use, the community can narrow it down.

Hi @Hoàng Mạnh

Salesforce Field Service has capabilities that are definitely good fit for truck - transportation, and management of fleets etc.    Salesforce Field Service also has map routing features.   

However, often I come across the question on another inter-related product "Salesforce Map" from some customers, and whether to go with full-blown "Salesforce Field Service" product or an almost subset of "Salesforce Maps" product.

Here is one article that compares/contrasts both the products and outlines their purposes, which may be helpful

https://medium.com/creme-de-la-crm/salesforce-maps-vs-field-service-646690b2ff01

Regards,

Kannan

I'm aware this is old post, but this could be useful for someone else. The issue is due to ESO feature. according to this article https://help.salesforce.com/s/articleView?id=service.fs_create_absences.htm&type=5  "If you're using Enhanced Scheduling and Optimization and there’s no address on the resource absence, optimization and scheduling actions use the location of the last event (Service Appointment or Resource Absence) that has a location to calculate the travel time to the next event. If the resource absence overlaps with the shift end, the resource’s home base location is used to calculate the travel time. If you're not using Enhanced Scheduling and Optimization and there’s no address on the resource absence, optimization uses the resource’s home base to calculate travel time to the next service appointment. For a more precise travel estimate, add an address to the absence, such as the location of the previous appointment or an address for the break."

Hi Nancy, 

(or vice versa) for an existing field. 

Go to Setup → Object Manager → Your Object → Fields & Relationships → Your Field 

Click Edit 

You'll see the picklist is tied to a Global Value Set — there is

here to detach it and switch to manual values. This choice is locked in at field creation and isn't editable afterward. 

@Nancy MagalhaesOne limitation I’d consider is the underlying data model: the native Relationship Map is primarily account/contact relationship-focused, so a true side-by-side “customer org + our internal org” hierarchy is difficult to maintain dynamically.

If this is a recurring sales use case, I’d model the internal stakeholders and customer contacts as related records with an explicit relationship type (Decision Maker, Executive Sponsor, Account Owner, etc.), then surface those relationships through a custom LWC. That would keep the visualization data-driven instead of relying on manually added cards, while still keeping everything inside Salesforce.