#Salesforce Field Service68 personnes en discutent

Hi @maxime woussen Could you check if Drip Feed dispatch is enabled in your org? (App Launcher -> Field Service Settings -> Dispatch -> Drip Feed), sample screenshot below. If enabled, you can turn it off to prevent auto-dispatch of the next appointment on completion on the previous one.

Excellent use case and a strong example of extending Salesforce beyond traditional CRM workflows.

From an architectural perspective, I would recommend treating predictive patrol generation as a separate domain rather than creating Tasks directly from incident records. A dedicated custom object such as Patrol Recommendation or Risk Assessment provides a cleaner separation between operational incidents and system-generated intelligence. This approach improves auditability, reporting, and future scalability as the recommendation engine becomes more sophisticated.

For the data model, your proposed Account → Location hierarchy is sound. To support incidents affecting multiple physical zones, I would introduce a junction object between Cases and Zones/Locations. This avoids data duplication, preserves referential integrity, and enables more accurate analytics when evaluating incident concentration across overlapping areas.

Regarding predictive logic, a layered architecture would likely be most scalable:

• Case creation and enrichment via Record-Triggered Flows 

• Scheduled aggregation of incident metrics into summary objects (by Zone, Incident Type, Time Window, and Severity) 

• Recommendation generation based on configurable risk thresholds 

• Patrol assignment and dispatch workflows consuming those recommendations

I would caution against calculating historical density directly against large Case datasets within Flow as volume grows. Pre-aggregated metrics will perform significantly better and align more closely with enterprise-scale security operations platforms.

For a portfolio project, Flow Builder is more than capable of demonstrating the core concept. However, Agentforce could add significant value by providing contextual reasoning around recommendations—for example, explaining why a patrol was suggested, identifying recurring incident patterns, or proposing mitigation strategies based on historical trends. This would make the solution feel closer to a modern intelligence-driven operations platform rather than a rules-based dispatch system.

Looking ahead, Field Service could also become a natural extension of this architecture. Guards can be modeled as service resources, patrols as work orders or service appointments, and optimization logic can evolve toward workforce scheduling, route optimization, certification tracking, and overtime management.

Overall, the architecture direction is solid. The key design principle I would emphasize is separating raw operational events (Cases) from analytical intelligence (risk scoring, recommendations, patrol generation). That separation will make the platform significantly easier to scale, maintain, and evolve as additional predictive and AI capabilities are introduced.

@David Hastie

Reiterating 3 years later. I have license, system permission, briefcase assigned to my user and profile, Salesforce for Android app assigned to briefcase. Briefcase Run As User shows that the briefcase is assigned to my user.  

But when in Salesforce mobile app in Offline Mode, the only records that sync are Assets. Everything else says "We hit a snag. We couldn't download your records." 

The downloadable app logs show that only recently viewed records are fetched and it says 

"usingBriefcase":false

Hi , 

Are you using the following special developer org? 

Past experience has shown that if you do not use this special developer org, the  

permission set cannot be set correctly. 

https://trailhead.salesforce.com/content/learn/modules/data_security/data_security_org

@Jashwanth Ayyalapu, per Salesforce support, the Work Order History>Created By field is missing in some orgs due to, "[a] backend perm which has now been depreciated. Because of this perm, the User lookup fields in some history objects(Work Order history, Work Order Line Item History, Service History. etc.) are acting as a polymorphic field (User, CSS User). This causes issues when the user tries to create reports based on these history objects. Disabling this perm, the "Created By" field in the WOHistory object only points to the User object now making it visible." The backend perm referenced can only be disabled by Salesforce support, and is not specific to my org. Other customers have had this issue as well. Once disabled, the Created By field is available in the report type.