Lägg in en kund en gång, i HubSpot. Portalen och affärssystemet följer med.
Ett svenskt B2B-bolag har sin kundportal på Litium och sin ekonomi i Microsoft Business Central. HubSpot skulle vara platsen där kunder läggs in, men inget kopplade det till något av dem. Nu går företag och kontakter från HubSpot till portalen, och genom den till affärssystemet, utan att någon skriver in dem igen. Ändringar i portalen kommer tillbaka till HubSpot med vem som ändrade vad, och när.
ställe där en kund läggs in. Portalen och affärssystemet får den från HubSpot, så ingen skriver in samma företag två gånger.
riktningar som hålls i takt. Varje ändring går en gång och stannar, oavsett på vilken sida den gjordes.
detaljerade valideringsmöten på en vecka, varefter kunden godkände integrationen i sin helhet.
Godkänd av kunden i maj 2026 och därefter släppt till fullständig integrerad testning.
Fem saker säljteamet får som inte fanns tidigare.
Samma portal, samma affärssystem, samma säljare. Det som ändrades är var en kund läggs in, och hur mycket någon behöver skriva in eller jaga efteråt.
Ett ställe att börja på
Företag och kontakter skapas i HubSpot. Portalen och affärssystemet får dem därifrån.
Ingen dubbelinmatning
Kontakter som skapas i portalen kommer till HubSpot redan kopplade till sitt företag, med dess status.
En person godkänner första utskicket
En ny kund når portalen via en knapp, efter en kontroll. Därefter flödar ändringarna av sig själva.
Felaktig data stoppas vid dörren
En okänd säljarkod, ett okänt språk eller land ger ett tydligt meddelande i HubSpot i stället för att nå affärssystemet.
Varje ändring har en upphovsperson
Varje fält som ändras i portalen blir en anteckning i HubSpot: vad, från, till, när och av vem.
Säljaren lämnar aldrig företagsposten.
Det riktiga kortet, återskapat på sidan och i en loop. Det dyker upp när företaget blir partner, listar det som fortfarande saknas och uppdateras av sig självt medan säljaren fyller i. Tryck på det för att stega igenom själv.
Ett företag som blir partner får en knapp för att skapa det i portalen. Knappen är låst tills varje fält som portalen behöver är ifyllt, och kortet visar vilka som fortfarande är tomma. Om portalen avvisar ett värde ser säljaren varför, i klartext, i samma kort. När företaget är aktivt i portalen försvinner knappen och varje senare ändring synkas av sig själv.
När knappen visas, och när den inte gör dettvå villkor och en lista över det som saknas
Knappen visas bara när företagets livscykelfas är Partner och företaget ännu inte är aktivt i portalen. Innan den går att trycka på listar kortet varje obligatoriskt fält som fortfarande är tomt. Kortet uppdateras var tredje sekund, så säljaren ser ändringen så snart ett fält har sparats, och en uppdatering som kommer mitt i ett klick kan inte slå på knappen igen och skicka företaget två gånger.
Varför första utskicket är manuelltoch allt efter det inte är det
När en kund skapas i portalen skapas den också i affärssystemet, där den kan faktureras. Det är ett åtagande, så en person gör det, efter att kortet har bekräftat att inget saknas. När företaget är aktivt synkas varje ändring på båda sidor automatiskt. Omdömet ligger där det spelar roll och ingen annanstans.
Två system som lyssnar på varandra pratar i all oändlighet.
HubSpot berättar för portalen om en ändring. Portalen sparar den och berättar för HubSpot om ändringen den just sparade. Utan ett skydd tar det aldrig slut. Visningen växlar av sig själv. Välj en sida för att stanna på den.
Tre sätt att stoppa det, och det som valdesfingeravtryck, tidslås, ursprungsflagga
Ett tidslås ignorerar allt en stund efter ett utskick och tappar riktiga ändringar som görs under den tiden. En ursprungsflagga kräver att båda systemen bär och respekterar en markör, vilket beror på den andra leverantören. Fingeravtrycket kräver ingetdera: tjänsten minns vad den just skickade, och när samma data kommer tillbaka inom femton sekunder känner den igen sitt eget eko och stannar.
Under bygget dök detaljen upp som avgör om metoden fungerar: samma id kom som text från ena sidan och som tal från den andra, så två identiska ändringar såg olika ut. Varje värde normaliseras innan fingeravtrycket tas.
Ingen behöver fråga vem som ändrade faktura-e-posten.
Varje egenskap som ändras i portalen skrivs till företagets tidslinje i HubSpot, med det gamla värdet, det nya, tiden i Stockholm och personen som gjorde ändringen. Tidslinjen till höger fyller sig själv i en loop.
Portalen skickar id:t för användaren som gjorde ändringen, och integrationen hittar den personen bland företagets kontakter i HubSpot. Om det inte går genomförs ändringen ändå: anteckningen säger "Okänd användare", och portalen får en varning som den kan skicka vidare till sin administratör.
Ett värde som portalen avvisar hanteras på samma sätt. Om en säljare skriver en okänd säljarkod i HubSpot återgår fältet till det senaste giltiga värdet och en anteckning förklarar varför, så att det felaktiga värdet aldrig studsar fram och tillbaka mellan systemen.
Faktura-e-post ändrad från invoice@example.se till billing@example.se, av Anna Berg.
Språk ändrat från engelska till svenska, av Anna Berg.
Ny kontakt Erik Lund skapad i portalen, redan kopplad till det här företaget och dess status.
Telefon ändrat från 031 00 00 00 till 031 11 11 11, av Okänd användare. Ändringen behölls.
Säljarkod XY9 godtogs inte av portalen. Fältet återgick till AB1.
Portalformulär räknades på fel kontakten bieffekt av spårningen som upptäcktes på vägen
HubSpots spårningskod läste även formulär inne i portalen och tillskrev inskicken den kontakt som webbläsaren mindes, inte den som formuläret gällde. Rekommendationen var att blockera spårningen på portalens interna sidor via tag managern, så att marknadsrapporterna bara räknar riktiga inskick.
Sex sätt som en synk åt båda hållen går fel på, och vad som stoppar vart och ett.
Inget av det här syns i en demo. Det syns den tredje månaden. De löses en i taget. Klicka på någon av dem för att styra själv.
Oändlig loop
Varje system rapporterar tillbaka det andras ändring som ny, i all evighet.
Ett fingeravtryck av det som skickades, sparat i femton sekunder, med varje värde normaliserat.
Felaktig data i affärssystemet
En okänd säljarkod, ett okänt språk eller land går vidare och förstör något längre ned i kedjan.
Portalens avvisning blir ett tydligt meddelande i kortet, och en felaktig ändring i HubSpot återställs med en anteckning.
Dubblettkunder
Samma företag skapas två gånger, eftersom två system inte är överens om vad som gör det till samma företag.
Nyckeln bestämdes innan bygget: HubSpot-id, organisationsnummer och e-post vägdes mot varandra, inklusive filialer som delar ett organisationsnummer.
Tysta fel
Ett valideringsfel blir ett allmänt serverfel, och säljaren ser inget användbart.
Den verkliga orsaken når kortet, ord för ord.
Ett kontrakt som rör sig
Fältnamn som skiljer sig mellan portalens dokumentation och hur den beter sig, fel metoder, en radering som kommer fram tom.
Vart och ett spårades i loggarna och stämdes av med portalens utvecklare, med API-dokumentationen versionerad upp till V6.
Ändringar utan upphovsperson
Ett fält ändras och ingen kan säga vem som gjorde det.
Portalanvändaren matchas mot en kontakt i HubSpot. Om det misslyckas behålls ändringen och administratören varnas.
Incidenten i juliett kort som svarade med en webbsida
I juli började kortet få en webbsida där det väntade sig data. En kontroll lager för lager, från kortet till tjänsten bakom, visade en inställning i webbservern som krockade med en annan integration på samma server. De två konfigurationerna slogs ihop till en, och ingen av tjänsterna gick ned medan felet rättades.
Varje svar har ett namn, och varje regel är nedskriven.
Portalen byggs av en annan byrå. För att de ska kunna hantera varje fall på egen hand har varje svar från integrationen en kod som ett program kan läsa, och varje regel finns i ett dokument i stället för i någons huvud.
"code": "company_updated",
"message": "Company updated in HubSpot",
"modified_by": "Anna Berg"
}
Portalteamet läser koden, inte meningen, så varje fall kan hanteras automatiskt: uppdaterat, avvisat eller godtaget med en varning till administratören.
- En guide i klarspråk till portalens API
- En referens över varje endpoint som integrationen exponerar
- API-dokumentation versionerad upp till V6, juni 2026
- En komplett teknisk guide till integrationen
- Flödesscheman för att skapa ett företag och validera en kontakt
- En testchecklista som täcker varje scenario, med förväntad status och förväntat svar
- En genomgångsvideo av varje funktion, inspelad för kunden
Vad det körs pålitet, eget och dokumenterat
En Python-tjänst byggd med FastAPI på en dedikerad server, bakom Nginx med SSL, som körs som systemtjänst och versionshanteras i ett privat repository. Den är uppdelad i fyra lager: autentisering mot portalen (OAuth 2.0, med token som cachas och förnyas i förväg), de endpoints som tar emot ändringar från varje sida, klienterna som pratar med HubSpot och portalen, och mappningen som översätter det ena systemets fält till det andras. Webhooks från HubSpot verifieras med signatur, och de från portalen med en delad hemlighet.
I HubSpot: egna egenskaper för kundnummer, organisationsnummer, språk, säljarkod, företagets faktura-e-post och kontaktens roll i portalen, plus fält för synkstatus, och själva kortet, byggt som en HubSpot UI extension i React och TypeScript.
En integration bedöms efter vad säljaren ser när något är fel.
Att flytta data mellan två system är den enkla halvan. Den halva som avgör om folk litar på det är meddelandet på skärmen när portalen säger nej, anteckningen som säger vem som ändrade ett fält, och ändringen som går en gång och stannar.
Gör HubSpot till ingången till er portal och ert affärssystem.
- Synk åt båda hållen, där en person godkänner första utskicket och allt därefter sker automatiskt
- Varje ändring skrivs tillbaka till HubSpot med upphovsperson och tid
- Byggt för att hålla mot ett API som ägs av en annan leverantör
Trettio minuter, era system på skärmen, inga presentationsbilder.