Bij een Salesforce implementatie project, worden vaak oude systemen vervangen. De data uit zo’n applicatie die door Salesforce vervangen wordt, mogen meestal echter niet verloren gaan. Die ga je dus naar je nieuwe Salesforce omgeving migreren. Gelukkig kun je dat doen door csv bestanden te uploaden.
Hoewel er een Data Import Wizard ingebouwd is in de Salesforce setup, wil ik daar in dit blog niet op ingaan. Ik adviseer voor dit soort grootschalige data imports gebruik te maken van Data Loader. Dit is een applicatie die je downloadt op je computer en waarmee je data kunt exporteren, invoegen (insert), bijwerken (update), upserten (een combinatie van invoegen en bijwerken) en zelfs verwijderen.
In een eerdere blog ben ik al eens op het gebruik van Data Loader ingegaan en ook op Trailhead en Youtube is het nodige zeer nuttige lesmateriaal te vinden. Als je verantwoordelijk bent voor zo’n data import, verdiep je daar dan zeker in.
Naast het kennen van de mogelijkheden van Dataloader en hoe deze tool te gebruiken, is het belangrijk dat je het datamodel van je Salesforce omgeving begrijpt. Met het datamodel bedoel ik hier vooral dat je weet in welke objecten (zoals Opportunity of Contact) verwezen wordt naar records van andere objecten (zoals Account). Als je weet dat een Opportunity verwijst naar een Account, zul je het logisch vinden dat je eerst Accounts zult moeten importeren en pas daarna de Opportunities en Contacten die aan die Accounts gerelateerd zijn.
Voor de rest van dit artikel wil ik wat tips delen, die je misschien niet zo gemakkelijk vindt op internet, maar die zeker waardevol zijn.
Excel formules die je moet kennen
Bij het voorbereiden van je bestand zul je gebruik maken van de nodige excel formules om je data te valideren en op te schonen.
VERT.ZOEKEN / VLOOKUP
Je brondata zal niet altijd in precies dezelfde tabellen ingedeeld zijn als waar ze uiteindelijk in Salesforce terecht moeten komen. Vaak is een brondatabase wat platter. Zo kan een Service Ticket integraal de data van een klant bevatten, maar die houd je in Salesforce op één centrale plek (Account) bij. Soms kan een oorspronkelijke tabel dus tot meerdere te importeren tabellen leiden en vaak zijn de relaties tussen records in verschillende tabellen belangrijk. Zo zal een Case een relatie hebben naar een Account. Bij het juist opzetten van deze relaties komt verticaal zoeken goed van pas.
Een tip voor bij het bepalen van het bereik waarbinnen je zoekt: selecteer de gehele kolommen in plaats van een specifiek gebied. Dan voorkom je het mogelijke probleem dat je functie in de vijfde regel niet zoekt in de bovenste 4 regels van je brontabel, maar wel in de eerste 4 regels onder de laatste geselecteerde regel.
=VERT.ZOEKEN(A2;Blad1!A:B;2;0)in plaats van =VERT.ZOEKEN(A2;Blad1!A1:B999;2;0)
SUBSTITUEREN / SUBSTITUTE
Tekstvelden uit je brondata kunnen speciale tekens bevatten waar je last van kunt hebben in je importbestand. Tekens als komma’s, puntkomma’s en tabs kunnen ten onrechte als de start van een volgende kolom worden geïnterpreteerd in het csv bestand.
Dubbele aanhalingstekens, mits in paren voorkomend, zorgen dat alle komma’s en puntkomma’s ertussen niet als lijstscheidingsteken worden beschouwd. Maar wanneer aanhalingstekens binnen de cel niet in balans zijn, worden er juist lijstscheidingstekens onterecht gemist, waardoor het aantal kolommen van die regel weer niet klopt.
Aanhalingstekens kunnen gebruikt worden als symbool voor inch of seconden, dus controleer altijd of deze tekens voorkomen. Om er helemaal zeker van te zijn, pas je een aantal opeengestapelde SUBSTITUTE functies toe. Tekens die ik zelf bij voorkeur weghaal zijn:
- Regeleinden (enters), binnen de SUBSTITUTE functie te schrijven als TEKEN(12) of CHAR(12)
- Komma’s TEKEN(44) / CHAR(44)
- Puntkomma’s TEKEN(59) / CHAR(59)
- Tabs TEKEN(11) / CHAR(11)
- Dubbele aanhalingstekens TEKEN(34) / CHAR(34)
In een ASCII tabel, die je overal op internet kunt vinden, kun je de codes van alle denkbare tekens opzoeken
LINKS / LEFT
In Salesforce kunnen velden voor tekst en getallen een maximaal aantal tekens hebben. Record namen mogen over het algemeen uit maximaal 80 tekens bestaan. Veel ‘simpele’ tekstvelden mogen maximaal 255 tekens bevatten, maar custom velden kunnen ook andere limieten hebben. Controleer de velden waar de gegevens in zullen worden opgeslagen op de maximale lengte en verzeker jezelf er door een LINKS of LEFT formule te gebruiken van dat je niet teveel tekens aanbiedt.
Samen met de hierboven genoemde substitute formule kun je dit stapelen:
=LINKS(
SUBTITUEREN(
SUBTITUEREN(
SUBTITUEREN(
SUBTITUEREN(
SUBTITUEREN(
Blad1!C2,
TEKEN(12),
""
),
TEKEN(44),
""
),
TEKEN(59),
""
),
TEKEN(11),
""
),
TEKEN(34),
""
),
254
)Blad1!C2 in de formule hierboven kan ook weer een verticaal zoeken functie zijn, waardoor je er zekerder van kunt zijn dat er niet door een klein foutje in een formule data uit verschillende regels bij elkaar gezet worden.
De schrijfwijze met regeleinden en tabs zoals hierboven is prettig leesbaar, maar excel kan er problemen mee hebben, dus beter gebruik je de functie zonder spaties, tabs en regeleinden
=LINKS(SUBTITUEREN(SUBTITUEREN(SUBTITUEREN(SUBTITUEREN(SUBTITUEREN(Blad1!C2,TEKEN(12),""),TEKEN(44),""),TEKEN(59),""),TEKEN(11),""),TEKEN(34),""),254)Datumformaat
Ook belangrijk is het formaat waarin je een datum of datumtijdwaarde importeert. Wees ervan bewust dat de API waarde van een datum of datum-tijd altijd in GMT wordt uitgedrukt. Bevatten je brondata data en/of tijden die in een andere tijdzone zijn uitgedrukt, voer dan een correctie door op de waarde die je gaat importeren. Houd daarbij ook rekening met een verschil als er sprake is van verschillende zomertijd en wintertijd in de tijdzone van de data.
Je kunt ook met excel bepalen of de datum of datum-tijd die je moet corrigeren in zomertijd of wintertijd valt. Test die correctie vooraf met een kleine batch records om er zeker van te zijn dat je correctie op de juiste manier is gemaakt. Als je de tijdzone van je gebruiker goed hebt staan, zul je de juiste tijd uitgedrukt in jouw tijdzone moeten zijn, ook al heb je de datum of tijd in GMT geïmporteerd.
Stel ik wil 1 november 2023 8:00 uur Nederlandse tijd importeren, dan zet ik in mijn csv de volgende waarde: 2023-11-01T07:00:00Z. Als ik vervolgens in Salesforce de datum bekijk, zie ik in de user interface gewoon 1 november 2023 8:00 uur, terwijl iemand in Londen die naar dezelfde record kijkt een tijd van 7:00 uur zal zien.
Hierboven zie je ook meteen een schrijfwijze voor datum-tijdwaarden. Hier vind je de juiste bruikbare formaten om datum en tijd te importeren.
Zomertijd / Wintertijd correctie in excel
Voor dit voorbeeld gaan we er vanuit dat de te converteren datum in Blad1!D2 staat.
Om het overzichtelijk te houden, kun je de verschillende stappen van de berekening het beste elk in een afzonderlijke kolom uitvoeren. Ik voeg hiervoor doorgaans wat kolommen toe in het excel tabblad waar de brondata staan, die nog getransformeerd moeten worden.
Datum waarop de zomertijd begint (tijdzone Amsterdam/Europe)
(cel E2 in het voorbeeld)
=DATUM(JAAR(D2);3;24)+8-WEEKDAG(DATUM(JAAR(D2);3;24))Datum waarop de zomertijd eindigt (tijdzone Amsterdam/Europe)
(cel F2 in het voorbeeld)
=DATUM(JAAR(D2);10;24)+8-WEEKDAG(DATUM(JAAR(D2);10;24))Is Blad1!D2 in zomertijd?
(cel G2 in het voorbeeld)
In dit voorbeeld staat de formule die de startdatum van de zomertijd weergeeft in cel E2 en de formule die de einddatum van de zomertijd weergeeft in cel F2.
=EN(D2<F2;D2>E2)Resultaat als D2 in zomertijd is: WAAR
Resultaat als D2 in wintertijd is: ONWAAR
Corrigeer de tijd naar GMT
(cel H2 in het voorbeeld)
=D2-ALS(G2;2;1)/24Hierin corrigeer trek je in het geval van zomertijd (Tijdzone Amsterdam) 2 uren af en in het geval van wintertijd 1 uur. Wanneer het op 1 november 2023 8:00 uur is in Nederland, is het op datzelfde ogenblik in het Verenigd Koninkrijk 1 november 2023 7:00 uur.
Zet gecorrigeerde datum-tijd om naar juiste format voor import
(cel I2 in het voorbeeld)
=TEKST(H2;"JJJJ-MM-DD")&"T"&TEKST(H2;"uu:mm")&":00z"External Id
Aan het begin van het artikel legde ik al uit dat je vaak relaties zult moeten importeren. Uiteraard verdiep je je eerst in het datamodel en importeer je eerst records die het hoogst in de relatieboom zitten. Cases en Opportunities hebben een verwijzing naar Account en dus zul je die Accounts eerst geïmporteerd moeten hebben.
De relatie is het gemakkelijkst te maken door alle records die je importeert al een unieke ID mee te geven. Met verticaal zoeken kun je de juiste Parent Id (de unieke code van het bovenliggende record) koppelen aan je child records. Bijvoorbeeld: Opportunity 500 en 543 kunnen beide bij Account 209 horen. Als je zelf je unieke Id’s al meegeeft in je upload, kun je de relatie van een child record in een latere import gewoon aan je Account matchen zonder dat je het Salesforce record Id van dat Account eerst moet gaan opzoeken.
Check wel vooraf of er een veld bestaat dat gemarkeerd is als External Id. Indien het nog niet bestaat of er bestaat er alleen een die al voor een ander doel gebruikt wordt, maak je zelf een nieuw external Id veld aan en gebruik je dat.
Door te importeren met de upsert functie, kun je de relatie met de bovenliggende ofwel parent record leggen via de externe Id die je in je excel al hebt.
In je excel ziet dat er zo uit
In dataloader kies je eerst voor Upsert
Het selecteren van het te importeren object en de csv file, is hetzelfde als bij elke import
Omdat een upsert ook bestaande Opportunities kan updaten, moet je Dataloader aangeven je als unieke sleutel zult gebruiken om gegevens aan bestaande Opportunties te koppelen. In dit voorbeeld gebruik ik de Id uit het oude systeem, die we in Salesforce opslaan in het Legacy_ID__c veld.
Voor alle relaties naar bovenliggende objecten van het Opportunity Object kun je dat in het volgende scherm ook doen. Koppelen aan een bovenliggend Account wil ik doen op basis van de Legacy ID van het Account.
Bij het mappen van de velden doe je dit op de volgende manier
Extra voordeel van External ID’s
Een bijkomend voordeel van een unieke externe Id, is dat je eventueel mislukte regels van de import veel gemakkelijker kunt opzoeken in je bronbestand om de data issues daar op te lossen en de regel in een nieuw csv bestand op te nemen voor een bezemronde.
Doordat je de wel geslaagde records direct kunt matchen met regels in je bronbestand, weet je ook zonder twijfel welke regels je dus niet in het bestand voor de bezemronde hoeft op te nemen.
Kleinere batches
Weet je dat er in je Salesforce Org veel triggers reageren op aanmaken of updaten van records van object dat je gaat importeren, kies dan om vastlopers te voorkomen een kleinere batchgrootte. Standaard zul je met Dataloader batches van 200 records tegelijk importeren.
Onder Settings kun je de batches kleiner maken. De import duurt dan langer, maar de kans op vastlopers door lange verwerkingstijd van automatische processen is kleiner.
Nederlands 
English (UK)