Hvad er en unique value property i HubSpot? Unikke ID-felter

Sådan virker unique value properties i HubSpot

En property er et felt på et objekt, og unikhed er en regel oven på feltet. Indstillingen sidder under Indstillinger, Properties, vælg objektet, og på fanen Rules hedder afkrydsningsfeltet Require unique values for this property. Feltet kan kun sættes, mens propertyen oprettes. De øvrige valideringsregler ligger samme sted og kan kombineres, så et felt både skal være unikt og overholde et bestemt format. HubSpots dokumentation for valideringsregler på properties beskriver opsætningen trin for trin.

Kun fire feltyper kan gøres unikke: enkeltlinjetekst, flerlinjetekst, telefonnummer og tal. Den detalje styrer designet af hele datamodellen, for en dropdown kan ikke være nøgle, og en dato kan heller ikke. Ligger jeres nøgle i dag i et select-felt, skal den flyttes til et tekstfelt, før den kan håndhæves, og den flytning er langt nemmere at lave, før der er skrevet tusindvis af records.

Der er plads til ti unique value properties pr. objekt. Det er rigeligt til de fleste danske B2B-opsætninger. Kører I derimod en koncern med flere ERP-instanser, et gammelt ordresystem og en webshop, der hver har sit eget kundenummer, bliver de ti pladser en begrænsning, I skal planlægge efter.

To objekter har allerede en indbygget nøgle. Contacts deduplikeres automatisk på email, companies deduplikeres på propertyen Company domain name, og alle andre objekter har kun Record ID at falde tilbage på. Der er en vigtig undtagelse: companies, der oprettes gennem API'et, deduplikeres ikke på domænet. Vi har samlet mekanikken på vores side om deduplikering af kontakter og virksomheder, og HubSpots gennemgang af deduplikering af records lister identifikatorerne objekt for objekt.

Companies har ingen brugbar standardnøgle. Både Company name og Company domain name tillader dubletter, og domænet holder kun, så længe hver kunde har sit eget. Derfor er en unique value property den eneste rigtige forretningsnøgle på company-objektet, hvis virksomheder skal kunne opdateres fra et andet system. Det er også grunden til, at de integrationsfejl, vi ser på companies, næsten altid ender med at handle om en manglende nøgle.

Unikheden kan sættes gennem API'et og ikke kun i brugerfladen. Du sender en POST til /crm/properties/2026-09/{objectType} med feltet hasUniqueValue sat til true, og propertyen er dermed nøgle fra det øjeblik, den oprettes. Properties API-guiden hos HubSpot Developers beskriver formatet og bekræfter grænsen på ti unikke ID-properties pr. objekt.

Upsert kræver en property, der kan skrives. Batch-upsert i CRM Objects API matcher på query-parameteren idProperty, og den skal pege på en property, hvis værdier er unikke for objektet. HubSpots eget hs_object_id kan ikke bruges, fordi det ikke kan oprettes eller ændres udefra. Forsøger du alligevel, får du fejlen Unable to perform update/upsert by non-unique 0-1 property hs_object_id. Nøglen skal altså være jeres eget felt.

Unikke properties virker ikke overalt i platformen. De håndhæves ved manuel oprettelse og redigering af records og ved import, men de understøttes ikke i formularer. Bygger I en formular, hvor kunden selv skal skrive sit kundenummer, får I ingen spærring på dubletter fra den vej. Den kontrol skal ligge i et workflow eller i det system, der leverer data.

Der er også en detalje ved kloning, som overrasker folk. Når en record klones, følger værdien i en unique value property ikke med, netop fordi den ville kollidere med originalen. Kloner en sælger et deal for at spare tid, står nøglefeltet tomt på kopien og skal udfyldes manuelt bagefter.

Det interne navn kan spærre jer ude. Slår du unikhed til på en ny property, der genbruger det interne navn fra en tidligere slettet property uden unikhed, fejler det. Løsningen er at give den nye property et andet internt navn. Det er en af de fejl, der koster en halv time, hvis du ikke ved, hvad du leder efter.

Endelig findes funktionen slet ikke på alle objekter. Unikhed understøttes ikke på feedback submissions, marketing events og products. Den dyreste fejl er dog en anden. Beslutningen kan ikke omgøres: på en property, der allerede findes, er afkrydsningsfeltet gråt, og HubSpot har ingen vej til at slå unikhed til bagefter. Vil I gøre et eksisterende felt til nøgle, skal I oprette en ny property, flytte værdierne over med en Copy property value-handling i et workflow eller via eksport og import, og derefter rette alle workflows, lister og rapporter, der peger på det gamle felt. På et datasæt med 20.000 companies er det ikke et fem minutters arbejde.

Vi sætter nøglefelter og integrationer op i HubSpot for danske B2B-virksomheder, og vi starter altid med at afklare, hvilket felt der skal være den fælles nøgle mellem CRM og økonomisystem. Skal I koble HubSpot til e-conomic eller Business Central, eller står I med dubletter efter en import, der gik skævt, så ser vi på datamodellen sammen med jer og siger ærligt, om problemet løses med ét felt eller kræver oprydning først.

Hvad danske B2B-teams bruger unikke nøglefelter til

Nøglefelter er sjældent et mål i sig selv. De bliver nødvendige i det øjeblik, HubSpot skal udveksle data med noget andet, og de anvendelser, vi oftest bygger, ser sådan ud.

Kundenummer fra e-conomic
Et nøglefelt på company-objektet, der holder debitornummeret fra e-conomic. Integrationen slår op på nummeret i stedet for at gemme HubSpots Record ID i økonomisystemet, hvor der sjældent er et felt til det. En dansk produktionsvirksomhed med 1.800 debitorer kan dermed lade bogholderiet blive i e-conomic og salget i HubSpot, uden at nogen skal holde to ID-lister i hovedet.

Debitor- og varenummer fra Business Central
Samme princip, men typisk på to objekter: et nøglefelt på companies til debitornummeret og et til varenummeret. Her rammer I en begrænsning, der ændrer designet: products er netop et af de objekter, hvor unikhed ikke understøttes, så varenøglen skal ligge på et custom object, hvis den skal håndhæves af platformen selv.

Import, der opdaterer i stedet for at oprette
Ved import kan en unique value property bruges som identifikator på contacts, companies, deals, tickets og custom objects i stedet for Record ID. Et regneark fra en anden afdeling kan dermed opdatere eksisterende records, uden at nogen først skal eksportere ID'er ud af HubSpot. Vores side om import af data i HubSpot gennemgår arbejdsgangen, og HubSpots dokumentation for importværktøjet viser hvilke identifikatorer der gælder pr. objekt.

Batch-upsert fra jeres eget system
Har I en egenudviklet portal eller et ordresystem, kan det skrive direkte til HubSpot via endpointet til batch-upsert af CRM-objekter og lade idProperty pege på jeres eget nøglefelt. Systemet behøver så ikke selv at holde styr på, om en record findes i forvejen. Det er den enkleste måde at gøre en natlig synkronisering idempotent.

CVR-nummer som virksomhedsnøgle
Vi bruger ofte CVR-nummeret som nøgle på companies i danske opsætninger, fordi nummeret ligger fast i CVR-registret, mens domænenavne skifter og koncerner deler domæne. Et rådgivningshus med 600 kunder kan så matche HubSpot mod både ERP og offentlige registre på det samme felt. Gem det som tekst og ikke som tal, hvis I også skal kunne håndtere registreringsnumre med foranstillede nuller fra andre lande.

Serienumre, licenser og abonnementer
Skal I holde styr på maskiner, licenser eller abonnementer, ligger de typisk på et custom object i HubSpot, og der findes ingen indbygget nøgle ud over Record ID. Et nøglefelt med serienummeret gør det muligt at opdatere den enkelte maskine fra serviceafdelingens eget system. Uden det ender I med tre records for samme maskine efter et halvt års synkronisering.

Spærring mod dubletter ved manuel oprettelse
Nøglefeltet virker også indad i organisationen. Opretter en sælger en virksomhed, der allerede findes, får de en fejl på det unikke felt i stedet for at oprette dublet nummer to. Beskeden i brugerfladen fortæller, at værdien allerede tilhører en anden record, og sælgeren kan så søge den frem.

Fælles for anvendelserne er, at nøglen skal besluttes, før propertyen oprettes, og ikke når den første import melder fejl. Unikheden kan ikke slås til bagefter, så det er billigt at oprette feltet rigtigt fra start og dyrt at bygge det om senere.

Alternativer, priser og begrænsninger

Alternativerne falder i tre grupper: et andet felt inde i HubSpot, samme mekanik i en anden platform, eller et værktøj, der rydder op bagefter i stedet for at forhindre problemet.

Record ID i HubSpot
HubSpots eget interne ID er unikt og virker som identifikator ved import på contacts, companies, deals, tickets, products og custom objects. Prisen er, at det kun findes i HubSpot: skal det bruges som nøgle, skal det gemmes i det andet system, og det kræver både et felt der og en førstegangs-udveksling. Kan I tilføje et felt til modparten, er Record ID det hurtigste valg, og det koster ingenting.

Salesforce External ID
Salesforce løser det med to indstillinger på samme felt: External ID gør feltet søgbart og brugbart i upsert, mens Unique er den indstilling, der forhindrer dubletter. External ID alene tillader dubletter, og Salesforce anbefaler selv at slå Unique til oveni, fordi parallelle indlæsninger ellers kan skabe to records med samme eksterne ID. HubSpot har lagt de to ting sammen i én indstilling. Det er enklere at forklare og mindre fleksibelt at arbejde med.

Alternate keys i Dynamics 365 og Dataverse
Microsofts model er teknisk stærkere. En tabel kan have op til ti alternate keys, altså samme antal som HubSpot, men en enkelt nøgle kan sammensættes af flere kolonner, op til 16 kolonner og 900 bytes, så et match på både landekode og kundenummer kan håndhæves som én nøgle. Det kan HubSpot ikke. Microsofts dokumentation for alternate keys i Dataverse nævner også, at de ikke understøttes på virtuelle tabeller.

Insycle
En tredjepartsapp fra App Marketplace, der matcher og fletter dubletter i HubSpot på flere felter, end platformen selv kan. Den forhindrer ikke dubletter i at opstå, men den rydder op efter dem og kan køre planlagt. Pr. september 2026 koster Starter 100 USD pr. måned, Growth 150 USD og Professional 200 USD ved årlig betaling, med ubegrænsede brugere og op til 100.000 records ifølge Insycles egen prisside.

Data quality automation i HubSpot Data Hub
HubSpots eget oprydningslag med duplicate management og programmerbar automatisering findes kun fra Professional og op. Pr. september 2026 koster Data Hub Professional 720 USD pr. måned ved årlig betaling med ét Core Seat inkluderet, og Enterprise starter ved 2.000 USD pr. måned. Det er et stort spring at tage, hvis behovet i virkeligheden er ét nøglefelt.

HubSpots styrke er, at unikhed er én indstilling på et felt, at den virker på alle abonnementsniveauer, og at den gælder både i brugerfladen, ved import og i API'et uden yderligere opsætning. Svagheden er fleksibiliteten: fire feltyper, ingen sammensatte nøgler, ingen håndhævelse i formularer og ingen understøttelse på products. Skal I matche på en kombination af felter, er Dataverse den rigtige model, og skal I rydde op i et datasæt, der allerede er kørt af sporet, er Insycle hurtigere end at bygge det selv.

Selve funktionen koster ikke ekstra. Unikhed kan slås til på alle abonnementsniveauer, inklusive de gratis værktøjer, så længe objektet og feltypen understøtter det. Til gengæld koster objekterne omkring den: custom objects kræver Enterprise, og beregnede properties kræver Professional eller Enterprise.

Priserne pr. september 2026 hører med i regnestykket, når nøglefeltet er en del af et større projekt. Sales Hub Starter koster 7 USD pr. seat pr. måned ved årlig betaling, Professional 90 USD pr. seat pr. måned plus et engangsgebyr på 1.500 USD for onboarding, og Enterprise 150 USD pr. seat pr. måned plus 3.500 USD.

På marketingsiden er strukturen anderledes, fordi prisen ikke er pr. seat på de høje niveauer. Marketing Hub Professional koster 800 USD pr. måned ved årlig betaling med tre Core Seats og 2.000 marketing contacts inkluderet, plus 3.000 USD i onboarding, mens Enterprise ligger på 3.600 USD pr. måned med fem Core Seats og 10.000 marketing contacts, plus 7.000 USD i onboarding. Alle priser er i USD og hentet på HubSpots egne prissider.

Ingen af de hårde grænser kan hæves ved at ringe til HubSpot. I har ti unikke properties pr. objekt og fire tilladte feltyper at vælge mellem. Funktionen findes slet ikke på feedback submissions, marketing events og products, formularer håndhæver den ikke, og værdien følger ikke med, når en record klones. Det er rammerne, og de skal tages med i designet fra begyndelsen.

En ændring, der rammer integrationer netop nu, er valideringen i API-version 2026-09. Fra 8. september 2026 håndhæver HubSpot administratoropsatte regler ved skrivninger gennem API'et, så betinget påkrævede properties og properties, der er sat som påkrævede i record-opretteren, giver en 400-fejl, hvis de mangler. Kører jeres integration på den nye version og opretter records med et nøglefelt, skal I sikre, at de øvrige påkrævede felter også sendes med.

I dansk og europæisk sammenhæng er der to ting at holde øje med. Vælg en nøgle, der ikke i sig selv er en personoplysning: et debitornummer eller et CVR-nummer er uproblematisk, mens et CPR-nummer aldrig hører til i et CRM, og en unik property er ikke stedet at gemme det. HubSpots indstillinger for sensitive data kræver desuden Enterprise, så på lavere niveauer har I ikke det ekstra lag omkring følsomme felter.

Den anden ting er matchningen mod danske registre. CVR-nummeret er stabilt, men det kan ændre sig ved visse selskabsomdannelser, og en virksomhed kan skifte både navn og domæne uden at skifte CVR. Bruger I domænet som nøgle i stedet, rammer I hurtigt koncerner, hvor fem selskaber deler ét domæne, og så holder nøglen ikke.

Hvornår kan det så ikke betale sig? Har I under et par hundrede virksomheder i CRM'et, ingen integration til et økonomisystem og ingen planer om import fra andre kilder, er et nøglefelt overflødigt. Email på contacts og domænet på companies rækker, og tiden er bedre brugt på at få pipeline og lifecycle stages rigtigt. Skal HubSpot derimod tale med et ERP, er nøglefeltet noget af det første, vi sætter op i en HubSpot-implementering, og det er væsentligt sværere at rette bagefter end at gøre rigtigt fra start.