In grootschalige Salesforce Field Service-omgevingen (SFS) vereist het beheer van externe contractantennetwerken een delicate balans tussen platformbeveiliging en planningsprestaties. Deze handleiding vergelijkt twee primaire architectuurpatronen: het traditionele territoriumgebaseerde patroon en het nieuwe op accounts gebaseerde deelpatroon voor het regelen van toegang en beheer door externe contractanten. In deze paper bekijken we zowel diepgaand om organisaties te helpen bij het kiezen van de basisstructuur die hun operationele doelen het beste ondersteunt, als om de nadelen van elke optie te begrijpen.

Deze patroonkeuze heeft invloed op de planningsefficiëntie, resource-inzet en productiviteit van dispatchers. Door de juiste aanpak te kiezen, zorgen bedrijven voor een naadloze ervaring voor zowel interne medewerkers als externe partners, terwijl de schaalbaarheid van hun oplossing op de lange termijn behouden blijft.

Naast de directe operationele voordelen bepaalt deze fundamentele keuze of een organisatie gereed is voor autonome service. Het op accounts gebaseerde patroon voor delen biedt de zichtbaarheid van gecombineerde gegevens die Agentforce, en met name de Planningsagent voor Field Service, nodig heeft om een holistische evaluatie uit te voeren zonder te worden beperkt door kunstmatige gegevenssilo’s. Met op accounts gebaseerd delen kan Data Cloud ook meetgegevens over prestaties van contractanten effectiever aggregeren, waardoor naadloze benchmarking door de concurrentie mogelijk is en de strikte gegevensisolatie behouden blijft die vereist is in omgevingen met meerdere leveranciers.

• Selecteer uw patroon op basis van concurrentieoverlapping. Als externe contractanten concurreren met interne of andere externe resources op gedeelde territoria, is delen op basis van accounts waarschijnlijk de architectonisch correcte keuze. Territoriumgebaseerd delen is alleen geschikt wanneer contractanten exclusieve, niet-overlappende servicegebieden/taken krijgen.
• Vermijd territoriumuitbreiding. Het maken van speciale contractantterritoria om gegevensisolatie te bereiken wanneer dit niet nodig is, introduceert een hiërarchie-bloat die de planningsefficiëntie en prestaties verslechtert en de administratieve overhead op schaal aanzienlijk verhoogt. Op accounts gebaseerd delen elimineert dit probleempatroon.
• Bouw de basis voor AI-gestuurde planning. De planningsagent voor Field Service en de optimaliseringsengine presteren beter wanneer ze volledige zichtbaarheid van de resourcepool hebben. De op territorium gebaseerde silostructuur voor delen voorkomt dit; op account gebaseerd delen is de gewenste architectonische basis.

In het afgelopen decennium zijn netwerken van contractanten in Field Service geëvolueerd van ad-hocuitbreidingen van interne teams naar strategische, bewust gestructureerde ecosystemen in sectoren zoals telecommunicatie, nutsvoorzieningen, thuisdiensten en meer. Veel Field Operations vertrouwen nu op contractanten naast fulltime medewerkers, wat duidelijke regels vereist voor toegang, zichtbaarheid en dispatching.

Naarmate organisaties schalen op Salesforce Field Service, bepaalt de manier waarop ze deze externe resources ontwerpen en beheren, hetzij via een territoriumpatroon, hetzij via delen op basis van accounts, hetzij via hybrides, rechtstreeks hoe veilig en efficiënt ze werk kunnen plannen binnen een gemengd personeelsbestand.

Deze handleiding is bedoeld voor technische en strategische belanghebbenden die verantwoordelijk zijn voor het ontwerp, de prestaties en de schaalbaarheid van Salesforce Field Service-implementaties:

• Oplossing en technische architecten: De impact van verschillende deelpatronen op de planning en optimaliseringsefficiëntie evalueren.
• Leiders Field Service Operations: Inzicht in de nadelen tussen verschillende contractantenidentiteiten, zoals Op naam gestelde contractanten, Contractantenbedrijven en Incidentele medewerkers.
• Salesforce-beheerders: Om inzicht te krijgen in de manier waarop serviceterritoria en tabellen voor delen van platforms worden gebruikt om complexe beveiligingsvereisten te beheren.

De identiteit van de contractant in scope bepaalt rechtstreeks de juiste architectuur voor delen. Elke categorie heeft verschillende implicaties voor de manier waarop toegang op recordniveau is gestructureerd, hoe de Optimizer de beschikbaarheid van resources ervaart en hoe de oplossing schaalt:

• Benoemde contractant: Een afzonderlijke externe resource die op dezelfde manier wordt behandeld als een interne medewerker. Een benoemde contractant vereist een speciale gebruikerslicentie. Het model voor delen weerspiegelt de toegangspatronen van interne technici, waardoor dit de minst complexe contractantenidentiteit is om te ondersteunen.
• Aannemersbedrijf: Een externe entiteit die zijn eigen personeel beheert. In SFS worden contractantenbedrijven weergegeven als op capaciteit gebaseerde resources, waarbij de bovenliggende organisatie werk plant en toewijst aan het bedrijf in plaats van aan een specifiek individu.
• Incidentele medewerker: Een gebruiker die tijdelijk actief is in meerdere territoria. De meest architectonisch complexe identiteit. Tijdelijke relaties met meerdere territoria leiden ertoe dat op territoria gebaseerde grenzen voor delen worden afgebroken, waardoor de zichtbaarheid dynamisch wordt beheerd op recordniveau in plaats van door middel van statische geografische toewijzing.

Deze patronen zijn complex omdat de bovenliggende organisatie en de doelen van de contractant vaak technisch op gespannen voet staan.

1. Afwijkende doelen: De moederorganisatie richt zich primair op klanttevredenheid en contractueel werk/overeenkomst (bijvoorbeeld resourcevoorkeuren, snel en tijdig onderhoud en het beheren van de manier waarop werk en uren worden verdeeld over contractanten). Contractanten daarentegen richten zich doorgaans op het maximaliseren van toegewezen werk en het minimaliseren van reistijd en operationele kosten.

2. Concurrentie: In tegenstelling tot interne medewerkers zijn verschillende aannemersbedrijven vaak directe concurrenten. Terwijl de moederorganisatie een holistische kijk op de regio nodig heeft (transparantie), vereisen de contractanten strikte isolatie van elkaars activiteiten (isolatie).

3. Merkintegriteit: Bij de eindklant vertegenwoordigt de medewerker uw merk, wat vaak vereist dat het moederbedrijf realtime statusupdates ziet. Contractanten bewaken hun interne activiteiten echter vaak in een gesloten systeem, of “black box”.

4. Zichtbaarheid en beveiliging: Hoewel een gedeeld serviceterritorium doorgaans universele zichtbaarheid van alle toegewezen resources impliceert, vereisen omgevingen met meerdere contractanten een meer genuanceerd beveiligingspatroon. Voor het behoud van de concurrentie-integriteit en gegevensprivacy is het essentieel om te voorkomen dat contractanten toegang hebben tot elkaars eigen namen, planningen of resourcegegevens.

Contractantontwerp binnen Salesforce Field Service omvat drie verschillende bedrijfsmodellen, die elk van invloed zijn op de zichtbaarheid van resources, eigendom van dispatching en licenties:

1. Externe capaciteitstoewijzing
2. Zelfplanning van partner
3. Intern geleide verzending

Externe capaciteitstoewijzing (off-platform capaciteit): De contractant stuurt zijn personeel extern aan en biedt een gedefinieerde capaciteit (bijvoorbeeld 10 beschikbare uren) in plaats van planningen voor individuele technici. Deze capaciteit wordt behandeld als een bucket met uren of werkitems voor planningsdoeleinden.

Zelfplanning van partner: Contractantenmanagers loggen in bij Salesforce via een Experience-site om hun eigen teams te plannen. Ze vereisen strikte isolatie van andere partners.

Interne-geleide verzending: Interne dispatchers plannen technici van contractanten rechtstreeks in. Contractanten gebruiken de mobiele Field Service-app voor uitvoering.

In dit patroon fungeert het serviceterritorium als de primaire beveiligingsgrens. Elk Contractantenbedrijf wordt toegewezen aan zijn eigen unieke “Kind”-territorium.

• Kleinschalige partnernetwerken
• Partners met strikt niet-overlappende geografische regio’s
• Situaties waarin het werk van contractanten fundamenteel verschilt van het werk van interne resources, waardoor concurrentie wordt uitgesloten (zo behandelen externe contractanten alleen “Type A-installaties”, terwijl interne resources alle andere werktypen afhandelen)

• Vereenvoudigde configuratie: Gebruikt standaardinstellingen en automatisering van Gebruikersterritoria.
• Gegevensbuckets wissen: Zorgt voor eenvoudige zichtbaarheid van gegevens en vereenvoudigd beveiligingsbeheer via standaardobjecten voor Serviceterritorium.

• Optimaliseringsefficiëntie: De engine kan resources niet evalueren over territoriumgrenzen heen, wat optimale planning en efficiënte routering verhindert.
• Territoriumuitbreiding: Het maken van een groter aantal territoria voor een zeer laag aantal resources leidt tot planningsoverhead.
• Gantt-prestaties: Grote hiërarchieën (1K+-territoria) kunnen aanzienlijke bottlenecks in de prestaties veroorzaken, evenals het risico dat platformlimieten worden bereikt.

Deze handleiding introduceert een nieuwe oplossingsbenadering: Op account gebaseerd delen (geïmplementeerd via de native op criteria gebaseerde regels voor delen van Salesforce, hetzelfde platformmechanisme dat wordt gebruikt om recordtoegang te verlenen op basis van veldwaarden). Accountgebaseerd delen ontkoppelt zichtbaarheid van geografie. Territoria blijven groot en continu, terwijl zichtbaarheid wordt beheerd via de tabellen voor delen van het platform op basis van een accountrelatie. Praktisch gezien evalueren op criteria gebaseerde regels voor delen een veld in de record (zoals ServiceResource.Company) en delen die record automatisch met de juiste groep. Op criteria gebaseerd delen is de engine waarmee op account gebaseerd delen werkt zonder aangepaste code op recordniveau.

• Grootschalige ecosystemen waar een aanzienlijk deel van de beroepsbevolking bestaat uit externe hulpbronnen
• Stedelijke gebieden waar meerdere contractanten dezelfde postcodes hebben
• Scenario’s waarin zowel interne als externe resources in staat zijn hetzelfde werk uit te voeren (bijvoorbeeld “Type A-installaties”), maar bedrijfsregels een specifieke logica voor resourceselectie vereisen (bijvoorbeeld interne resourcevoorkeur in bepaalde scenario’s)

• Maximale inzet en investeringsrendement: De engine evalueert de gehele regionale pool en vindt de “beste” resource voor elke taak
• Schaalbaarheid: Ondersteunt een groot aantal contractanten/externe resources zonder territoriumtellingen te verhogen
• Geconsolideerd beheer: Intern personeel beheert één weergave in plaats van honderden geïsoleerde mappen (onderliggende territoria)

• Ontwikkelingsinspanning: Vereist aangepaste automatisering (Flow of Apex) om de tabellen voor delen te beheren
• Delen van lidmaatschap: Vereist expliciet delen van records van serviceterritoriumleden (STM)

Voor extern personeel (dimensie Externe capaciteitstoewijzing) kunnen architecten op capaciteit gebaseerde resources gebruiken om de “samenvatting” van het personeel van een contractant weer te geven.

• Capaciteit: Gebruik dit wanneer de contractant zijn eigen verzending en routering beheert. Uw primaire focus ligt op het totale volume aan werk dat ze kunnen uitvoeren, in plaats van de specifieke persoon die het uitvoert.
• Individu: Gebruik dit wanneer u fijnmazig zicht nodig hebt op de dag van een technicus. Met op individuen gebaseerde resources kunt u hun exacte locatie, real-time beschikbaarheid en specifieke taaktoewijzingen beheren alsof het intern personeel betreft.

Voordat u uw Field Service-contractantenpatroon ontwerpt, gebruikt u deze beslissingsstructuur om de juiste architectuur voor delen te bepalen.

Selectiestructuur van patroon voor delen van contractanten

Beslissingsstructuur voor het selecteren van een patroon voor delen door contractanten in Salesforce Field Service. Vanaf het moment dat externe resources in gebruik zijn, vertakt de structuur zich door resourcetype en taakexclusiviteit om op territorium gebaseerd delen of op account gebaseerd delen aan te bevelen.

De kern van dit patroon is een automatiseringslaag die de relatie ServiceResource.AccountId of ServiceResource.Company (Aannemersbedrijf) converteert naar records voor het delen van platforms.

Voor het verifiëren van de juiste toegang voor de dispatcher en de serviceresource in een Experience-site moet toegang worden geregeld via:

• Regel voor delen van serviceresources: Verleent toegang op basis van een criterium (account/bedrijf)
• Regel voor delen van serviceterritorium: Verleent toegang op basis van een criterium (territoriumnaam/ID)

Wanneer u op accounts gebaseerd delen gebruikt, moet u rekening houden met de Field Service Mobile-ervaring en recordzichtbaarheid voor toegewezen technici.

• Delen van toegewezen resources: Standaard SFS-functionaliteit verleent een toegewezen resource automatisch toegang tot de Serviceafspraak en de bovenliggende Werkorder ervan. Deze set-up geeft de technicus de benodigde informatie om de taak uit te voeren zonder dat er extra aangepaste regels voor delen nodig zijn voor toegewezen werk.
• Zichtbaarheidsrisico’s: Hoewel toegewezen werk intern wordt afgehandeld, moet u voorzichtig zijn met niet-toegewezen of toekomstige afspraken waaraan geen account- of territoriumkoppeling is gekoppeld. Als standaardinstellingen voor de hele organisatie (OWD’s) niet strikt worden beheerd of als sets voor delen te breed zijn, kunnen niet-toegewezen afspraken zichtbaar zijn voor alle gebruikers in een geconsolideerd territorium.
• Account-territoriumkoppeling: Zorg ervoor dat alle serviceafspraken expliciet zijn gekoppeld aan een account en territorium. Deze koppeling maakt schone filtering binnen de mobiele app mogelijk en controleert of er geen gegevenslekkage optreedt voor niet-toegewezen werk in de regionale pool.

• Vereiste: 10 verschillende contractanten bieden glasvezelinstallatie in Londen.
• Context: Bij de aanpak van op territoria gebaseerd delen zou Londen worden opgesplitst in 10 overlappende territoria. Dispatchers zouden moeite hebben om beschikbaarheid in de buurt te zien, wat leidt tot hoge reistijden.
• Aanbeveling: Op account gebaseerd delen. Implementeer een gecombineerd “Greater London”-serviceterritorium met behulp van op accounts gebaseerd delen om fijnmazige gegevensbeveiliging te behouden. Met op accounts gebaseerd delen blijft het beheer van contractant A geïsoleerd van hun respectieve resources, terwijl de SFS Optimizer een interfunctioneel zicht houdt op alle interne en externe technici. Deze volledige planningsbenadering faciliteert een efficiëntere routeringslogica die reizen met meer dan 20% kan verminderen door volledige planning (directionele schatting op basis van veldobservaties bij SFS-klantimplementaties), waardoor onmiddellijke verbeteringen in resource-inzet en verbeterde serviceresponsiviteit worden gecreëerd.

• Vereiste: Een leverancier biedt dagelijks maximaal 40 “slots” voor boilerreparaties, maar beheert de dispatching van zijn eigen technicus.
• Context: Het beheer van 40 afzonderlijke resourcerecords voegt onnodige overhead toe.
• Aanbeveling: Op capaciteit gebaseerde resource die is gekoppeld aan de leveranciersaccount. Eén resourcerecord vertegenwoordigt de totale dagelijkse capaciteit van de leverancier, waardoor het Gantt-diagram schoon blijft en het niet nodig is om records van afzonderlijke technici te beheren.

• Vereiste: Een nutsbedrijf onboardt 50 kleine lokale contractanten tijdens het stormseizoen om piekreparaties af te handelen.
• Context: Het maken en verwijderen van 50 territoria per seizoen is een grote administratieve last en heeft een negatieve invloed op de flexibiliteit van de plannings- en optimaliseringsengine.
• Aanbeveling: Op account gebaseerd delen. Maak een permanent geografisch territorium “Overloop”. Wanneer een contractant wordt onboard, maakt u gewoon diens account en koppelt u diens resources eraan. De automatiseringslaag verwerkt de zichtbaarheid onmiddellijk zonder dat een nieuw ontwerp van de territoriumhiërarchie nodig is.

• Vereiste: Voor gaslekken met hoge prioriteit moet de dichtstbijzijnde technicus worden uitgezonden, ongeacht voor welke contractant deze werkt.
• Context: Op territorium gebaseerd delen creëert dekkingshiaten waarbij de dichtstbijzijnde technologie zich mogelijk in een ander territorium bevindt en daarom onbereikbaar is voor de planningslogica.
• Aanbeveling: Op account gebaseerd delen. Door leveranciers te consolideren in één groot territorium, voert de engine een volledige zoekopdracht uit op basis van reizen binnen de gehele pool van meerdere leveranciers, waardoor reactietijden voor kritieke veiligheidsincidenten worden verkort.

• Vereiste: Een gespecialiseerde HVAC-partner heeft een exclusief wettelijk recht van 10 jaar om een afgelegen gebied of landelijke provincie te bedienen.
• Context: Er zijn geen andere contractanten actief in deze geografie en de partner beheert volledig zijn eigen planning en verzending.
• Aanbeveling: Op territorium gebaseerd delen. In dit scenario is een speciaal serviceterritorium de meest efficiënte keuze. Aangezien er geen geografische overlapping is met andere partners, sluit de isolatie die de territoriumgrens biedt perfect aan op de wettelijke en operationele vereisten zonder verdere automatisering voor delen.

Accountgebaseerd delen scheidt zichtbaarheid van geografie door toegang op recordniveau te koppelen aan een gemeenschappelijke account-/bedrijfs-ID die wordt gedeeld tussen de dispatchergebruiker en diens Serviceresourcerecords. De native op criteria gebaseerde engine voor delen van het platform evalueert dit veld en verleent of trekt automatisch toegang in zonder de territoriumhiërarchie te wijzigen.

De drie benodigde architectonische componenten zijn:

1. Een gemeenschappelijk identifierveld voor zowel gebruikers- als serviceresourceobjecten dat hen koppelt aan hun contractantenaccount.
2. Openbare groepen die alle Dispatcher-gebruikers per contractantenbedrijf aggregeren, waardoor regels voor delen uniform van toepassing zijn.
3. Op criteria gebaseerde regels voor delen die de identifier evalueren en de juiste openbare groep toegang verlenen tot relevante records.

Gebruik in plaats van territoria als grenzen Openbare groepen om dispatchers te aggregeren die dezelfde zichtbaarheid nodig hebben. Dispatchers zien specifieke territoria, werkorders en serviceafspraken via lidmaatschap van op territoria gebaseerde openbare groepen.

• Groep maken: Maak een openbare groep voor elk aannemersbedrijf.
• Lidtoewijzing: Voeg de relevante Partner Community-gebruikers (dispatchers) toe aan hun respectieve Openbare groep van contractanten.

Gebruik op criteria gebaseerde regels voor delen om de Openbare groep toegang te verlenen tot specifieke records.

• Criteria voor delen van serviceresources: Regels voor het delen van serviceresources dwingen de zichtbaarheid per contractant af door de bedrijfs-/account-ID in de serviceresourcerecord te koppelen aan de overeenkomende Openbare groep van contractanten.
  • Toegangsniveau staat lezen/schrijven toe, zodat dispatchers toewijzingen kunnen plannen en bijwerken.
• Criteria voor delen van serviceterritorium: Gebruik de criteria voor delen van serviceterritoria om de logica voor territoriumbeperkte toegang in te stellen. Verleen dispatchers toegang tot de brede geografische territoria waar ze geautoriseerd zijn om te werken. Voorbeeld:
  • Criteria: ServiceTerritory.Name IS GELIJK AAN “Atlanta”.
  • Gedeeld met: Relevante openbare groepen van contractanten (bijvoorbeeld Contractant A, Contractant B, Contractant C).
  • Toegangsniveau: Lezen/schrijven

Raadpleeg de officiële Salesforce-documentatie voor gedetailleerde implementatierichtlijnen:

• Op criteria gebaseerde regels voor delen
• Openbare groepen
• Apex Triggers voor geautomatiseerd recordbeheer voor delen

Indien correct geïmplementeerd, levert delen op basis van accounts:

• Gecombineerde zichtbaarheid: Dispatchers zien alle relevante resources over het volledige territorium zonder handmatige territoriumtoewijzing.
• Dynamische toegang: Naarmate contractantentoewijzingen veranderen, worden regels voor delen automatisch aangepast aan de zichtbaarheid zonder tussenkomst van een beheerder.
• Concurrentiële isolatie: Elke contractant ziet alleen zijn of haar eigen resources, waardoor de privacy van gegevens behouden blijft.
• Schaalbare architectuur: Nieuwe contractanten kunnen worden onboard door eenvoudig een account en openbare groep te maken, waarbij regels voor delen de rest automatisch afhandelen.

Terwijl Field Service-organisaties overschakelen van reactieve naar proactieve modellen, bepaalt hun keuze van het architectonische patroon het “innovatieplafond” voor operationele flexibiliteit op de lange termijn.

• AI en machine learning inschakelen: Accountgebaseerd delen verifieert dat de engine zicht heeft op de gehele resourcepool om de beste overeenkomst te vinden, in plaats van te worden beperkt door gegevenssilo’s. Omdat inefficiënte territoriumsilo’s worden vermeden, biedt de Scheduling Agent voor Field Service (door AI aangestuurde planningsassistent binnen Salesforce) logischere reispatronen en toewijzingen van technici zonder te worden beperkt door geïsoleerde microterritoria. Deze benadering maximaliseert volledige optimalisering, waardoor de KPI’s voor reizen en de gereedheid van de technicus direct worden verbeterd. Accountgebaseerd delen ondersteunt AI-gestuurde planning door de engine zicht te geven op de gehele resourcepool, waardoor “true best” matching mogelijk is in plaats van te worden beperkt door kunstmatige gegevenssilo’s.
• Architectonische schaalbaarheid: Territoriumgebaseerd delen stuit vaak op een “prestatiemuur” vanwege de afhankelijkheid van geïsoleerde territoria. Naarmate het netwerk van contractanten groeit, wordt de effectiviteit van de planningsengine geneutraliseerd door kunstmatige grenzen die verhinderen dat de beschikbare capaciteit in aangrenzende territoria wordt bereikt. Daar waar op territorium gebaseerd delen een nieuw territorium en handmatige aanpassingen voor elke partner vereist, vereenvoudigt op account gebaseerd delen bovendien de groei. Organisaties onboarden honderden contractantenpartners door eenvoudig een account en gekoppelde serviceresourcerecords te maken, waarbij de geografische kernstructuur ongemoeid en performant blijft.

Deze handleiding heeft zich voornamelijk gericht op netto-nieuwe implementaties. Veel organisaties voeren echter al op territorium gebaseerd delen op grote schaal uit en hebben een aanzienlijke territoriumhiërarchieschuld. Migreren van op territorium gebaseerd delen naar op account gebaseerd delen in een live productieomgeving brengt duidelijke architectonische risico’s met zich mee die moeten worden beoordeeld voordat er met overgangswerk wordt begonnen. Deze sectie behandelt de drie kritieke dimensies van een migratie van een bestaand systeem: het evalueren van de huidige status, het bepalen van de transitiestrategie en het beheren van migratierisico’s.

• Territoriumspreiding beoordelen: Kwantificeer vóór elke migratieplanning de huidige territoriumhiërarchie. De belangrijkste diagnostische vragen zijn: Hoeveel territoria bestaan er uitsluitend om isolatie van contractanten af te dwingen ten opzichte van echte geografische grenzen? Wat is de verhouding tussen contractantspecifieke onderliggende territoria en operationele bovenliggende territoria? Zijn er territoria die worden gedeeld tussen interne en externe resources, of zijn ze volledig in een silo ondergebracht? Bij deze controle wordt een onderscheid gemaakt tussen de werkelijke geografische structuur en de geaccumuleerde isolatieschuld. Territoria die uitsluitend zijn gemaakt voor controle over de zichtbaarheid van partners, komen in aanmerking voor eliminatie onder op accounts gebaseerd delen. Territoria die echte operationele geografie coderen (planningszones, SLA-regio’s, wettelijke grenzen) blijven behouden en worden niet gecombineerd met toegangscontrole.
• Hybride transitie levensvatbaarheid: Voor organisaties op grote schaal is een volledige overstap van op territorium gebaseerd delen naar op account gebaseerd delen zelden aan te raden; in plaats daarvan vermindert een hybride transitie het risico door nieuwe contractanten onder op account gebaseerd delen te onboarden, terwijl oudere op territorium gebaseerd delen-cohorten worden gehandhaafd tot hun volgende verlengingsperiode. De hybride benadering is architectonisch haalbaar op voorwaarde dat de op accounts gebaseerde automatisering voor delen strikt is gericht op de account-/bedrijfs-ID, waardoor resources zonder die ID zonder onderbreking toegang op territoriumbasis kunnen blijven houden. Behandel de hybride status als een tijdelijke architectuur, niet als een permanent bedrijfsmodel.
• Belangrijkste migratierisico’s: Migraties van bestaande systemen introduceren drie kritieke architectonische risico’s die proactieve vermindering vereisen. Ten eerste zijn het opnieuw samenstellen van tabellen voor delen, die via een trigger worden geactiveerd door nieuwe op criteria gebaseerde regels, resource-intensief. Plan bezuinigingen tijdens perioden met weinig activiteit om te voorkomen dat er hiaten in de zichtbaarheid van dispatchers ontstaan door langdurige nieuwe berekeningen. Ten tweede riskeren werkorders tijdens de overstap zichtbaarheidsverlies; behoud lidmaatschappen van parallelle territoria of vul het delen vooraf in voor actieve records totdat ze worden gesloten. Stem tenslotte het optimaliserings- en planningsbeleid af terwijl het verwijderen van onderliggende territoria de resourcepool verschuift. Test, voer baselineruns uit en leg meetgegevens vast om te bevestigen dat geografische grenzen effectief blijven en dat efficiëntieverbeteringen daadwerkelijk worden gerealiseerd.

Gezien de schaalbaarheid en het investeringsrendement van optimalisering, raden we de aanpak van accountgebaseerd delen aan voor snelgroeiende Field Service-organisaties die meerdere concurrerende contractanten beheren in overlappende geografische regio’s. Hoewel op territorium gebaseerd delen een eenvoudigere, declaratieve set-up biedt, kunnen organisaties met op account gebaseerd delen het volledige potentieel van de engine voor planning en optimalisering benutten. Door zichtbaarheid los te koppelen van geografie, kunnen organisaties een territoriumset-up onderhouden die meeschaalt met het bedrijf en de volgende resultaten oplevert:

• Operationele efficiëntie: Door resources te aggregeren in één pool kan de engine de echte “beste” technicus voor elke taak vinden, wat reistijd en operationele kosten vermindert.
• Verbeterde serviceniveaus: Uitgebreide planning reduceert servicevertragingen door te bepalen welke gecontracteerde resource het meest beschikbaar/dichtstbij is, de time-to-serve te versnellen en de klanttevredenheid direct te verbeteren.
• Productiviteit van dispatcher: Interne medewerkers kunnen een geconsolideerde regionale weergave beheren in plaats van te schakelen tussen geïsoleerde “onderliggende” territoria.

Territoriumgebaseerd delen is het meest geschikt voor contractanten met activiteiten die sterk in één hokje zijn ondergebracht en waarbij geografische territoria/gebieden elkaar strikt niet overlappen.

Het kiezen van een architectonisch patroon is de eerste stap. Voor een geslaagde uitvoering zijn continue afstemming met best practices van Salesforce en de platformmogelijkheden vereist.

Volgende stappen:

• Uw landschap controleren: Controleer uw huidige territoriumhiërarchie en inzet van externe resources. Identificeer alle “contractantterritoria” die uitsluitend zijn gemaakt voor partnerisolatie. Als uw hiërarchie vol zit met dergelijke silo’s, evalueer dan de voordelen en inspanningen van migreren naar op accounts gebaseerd delen.
• Sandboxvalidatie: Prototype het op accounts gebaseerde patroon voor delen in een volledige of gedeeltelijke sandbox en test de zichtbaarheid end-to-end vanuit alle perspectieven:
  • Interne gebruikers (beheerders, dispatchers en interne technici): Bevestig de juiste toegang. Sommige interne gebruikers moeten over de hele linie toegang hebben.
  • De Contractor Manager-gebruiker: Controleer of de zichtbaarheid strikt beperkt is tot het eigen personeel.
  • Technici van de aannemer (de externe resources): Bevestig dat de toegang op de juiste manier is beperkt tot hun toegewezen werk.
  • Het grondig testen van de zichtbaarheid van organisaties is essentieel om gegevenslekkage tussen concurrerende partners te voorkomen.
• Benchmarking van prestaties en evaluatie van investeringsrendement: Maak gebruik van de Optimaliseringshub en Field Service Intelligence-dashboards om insights te krijgen in reistijdvermindering, resource-inzet en verbeteringen in reactietijd, waarbij u de gegevens levert die nodig zijn om de architectonische verschuiving naar belanghebbenden te rechtvaardigen. Deze analyse voor en na kan ook in productie worden herhaald zodra de transitie bezig is.
• Proeffase: Zodra het testen van de sandbox is voltooid, start u een gefaseerde proef in een of twee territoria waar interne en externe resources geografisch overlappen, idealiter met die welke in de sandbox zijn getest. Valideer de logica voor delen met een kleine, gecontroleerde gebruikersgroep voordat een bredere implementatie wordt aanbevolen voordat u deze volledig implementeert.
• Schaalbaarheid van de oplossing: Controleer of alle aangepaste automatisering (Flow of Apex) die vereist is voor het beheer van records voor delen van tabellen en serviceterritoriumleden (STM), is ontworpen voor duurzaamheid op de lange termijn. De oplossing moet modulaire ontwerppatronen (bijvoorbeeld Trigger Frameworks) gebruiken en ervoor zorgen dat de logica is samengesteld om resourcetoewijzingen met groot volume naadloos af te handelen binnen platformbeheerlimieten.

Alle patronen in deze handleiding vereisen validatie in een sandboxomgeving voordat productie wordt geïmplementeerd. Implementatiewerking kan variëren op basis van organisatieconfiguratie, gegevensvolume en bedrijfsregels.

Platformdocumentatie (officieel van Salesforce):

• Field Service Developer Guide (Ontwikkelaarshandleiding voor Field Service): Kernreferentie voor Field Service-gegevensobjecten, API’s en aanpassingen
• Objectverwijzing ServiceResource: API-documentatie voor het object SR
• Objectverwijzing ServiceTerritoryMember: API-documentatie voor het STM-object
• Op criteria gebaseerde regels voor delen: Officiële beveiligingshandleiding voor het implementeren van de regels voor delen die op accounts gebaseerd delen ondersteunen
• Ontwikkelaarshandleiding voor Apex Triggers: Verwijzing naar de aangepaste automatiseringslaag die vereist is voor op account gebaseerd delen
• Best practices voor Apex Trigger: Salesforce aanbevolen patronen voor schaalbare triggerontwikkeling

Help-artikelen van Salesforce

• Richtlijnen voor het instellen van Field Service-contractanten: Richtlijnen voor het configureren van resources van contractanten voor Salesforce Field Service
• Op capaciteit gebaseerde resources definiëren: Officiële documentatie voor het instellen van op capaciteit gebaseerde resources waarnaar in het artikel wordt verwezen
• Hoe werkt de Field Service-optimaliseringsengine? Naslag Field Service-optimalisering. Richtlijnen voor het uitvoeren van optimalisering, ook relevant voor voordelen voor delen op basis van accounts en investeringsrendement waarnaar in het artikel wordt verwezen.
• Optimaliseringshub instellen: Configuratiehandleiding voor Optimaliseringshub waarnaar wordt verwezen in de sectie Volgende stappen
• Overzicht van Experience Cloud: Partner Community instellen voor delen op basis van accounts (On-platformbeheer)

Salesforce Trailhead / Opleiding

• Basisprincipes van Field Service: Basismodule voor territoria, resources en bedrijfsuren
• Field Service-planning: Planningsconcepten die de optimaliseringsdiscussie in deze handleiding ondersteunen
• Field Service-optimalisering: Diepe duik in het set-up- en planningsbeleid voor optimalisering
• Beveiliging van Salesforce en wie ziet wat: Regels voor delen en basisprincipes van gegevensbeveiliging
• Een partnerportal samenstellen met Experience Cloud: Praktische handleiding voor de set-up van Experience Cloud-partners waarnaar in het artikel wordt verwezen

Industrie en strategische context

• Salesforce-statusrapport, 7e editie: De meest recente editie, met 6.500 serviceprofessionals wereldwijd, met specifieke insights over Field Service, AI-acceptatie en productiviteitstrends van technici die direct relevant zijn voor de ROI-argumenten in dit paper.
• Agentforce voor Field Service: Salesforce’s door AI ondersteunde Field Service-platform, rechtstreeks relevant voor de discussie over AI en toekomstbestendigheid in sectie 13. De gecombineerde resourcepool voor delen op basis van accounts maximaliseert de planningsintelligence van Agentforce.
• Gartner Market Guide voor Field Service Management: De meest actuele Gartner-analyse van het FSM-marktlandschap (Gartner-abonnement vereist).

Mor Epstein
Senior Success Architect, Salesforce Field Service

Met een achtergrond in Industrial Engineering van Georgia Tech en een MBA is Mor een vertrouwde adviseur met een bewezen staat van dienst in het deblokkeren en versnellen van missiekritieke Field Service-implementaties. Haar wereldwijde klantgerichte ervaring, in combinatie met praktische, datagestuurde probleemoplossing, positioneert haar als een go-to-resource voor Field Service-organisaties wereldwijd. Mor blinkt uit in het begeleiden van klanten door het traject van planning en optimalisering, en helpt organisaties het volledige potentieel van intelligente planning te ontsluiten om meetbare winsten in efficiëntie en servicelevering te behalen.

Lee Ephrati
Senior Success Architect, Salesforce Field Service

Lee is een zeer ervaren Technisch Architect met meer dan 10 jaar Salesforce-ervaring op het gebied van levering en advies, gespecialiseerd in Field Service-architecturen en het ontwerpen van mobiele oplossingen. Lee richt zich op het afstemmen van complexe organisatiestructuren met het native SFS-platform en de mobiele toepassing om een maximaal operationeel investeringsrendement voor wereldwijde ondernemingen te stimuleren. Met een mentaliteit die de klant centraal stelt en uitgebreide platform Knowledge biedt Lee een adviserende benadering die consistent duurzame waarde biedt voor Salesforce-klanten wereldwijd.