HubSpot-assosiasjonsetiketter: Den komplette guiden (2026)

CRM-et ditt vet at en kontakt er koblet til en avtale.

Det den ikke kan fortelle deg, er hvorfor den kontakten betyr noe. Signerer de kontrakten? Kjemper de for deg internt? Blokkerer de i det stille hele avtalen?

Det gapet er akkurat det HubSpots assosiasjonsetiketter tetter.

I denne guiden lærer du hvordan du bruker assosiasjonsetiketter til å modellere kjøpskomiteer, selskapshierarkier og rotete avtaler på tvers av flere selskaper — relasjonene som faktisk driver inntekter. Du får også den ærlige versjonen: nivåbegrensningene, de harde grensene og den korte listen over ting etiketter rett og slett ikke kan gjøre.

Denne guiden gjenspeiler funksjonens nåværende tilstand, og vi oppdaterer den etter hvert som HubSpot lanserer endringer.

Hva er HubSpot-assosiasjonsetiketter?

Assosiasjonsetiketter beskriver hvorfor to poster i HubSpot er koblet sammen — for eksempel at en kontakt er «Decision Maker» (beslutningstaker) på en avtale, eller at ett selskap er «Parent» (overordnet) for et annet. En vanlig assosiasjon sier bare at en relasjon finnes. En etikett legger til rollen, slik at du kan segmentere, rapportere og automatisere på den. (For enavsnittsversjonen finnes det også en ordlisteoppføring.)

Se for deg én avtale med fem tilknyttede kontakter. Uten etiketter ser alle fem helt like ut — fem personer koblet til én mulighet.

Legg til etiketter, og bildet skjerpes: én er beslutningstaker («Decision Maker»), én er forkjemper («Champion»), én håndterer fakturering, én er juridisk kontakt, og én er sluttbruker som aldri kommer til å signere noe som helst.

Samme fem assosiasjoner. Helt annen innsikt.

Som HubSpots kunnskapsbase formulerer det, kan du «sette etiketter på assosiasjoner for å beskrive relasjonen mellom tilknyttede poster».

Og her er hvorfor det betyr noe utover ryddighet: etiketter kan spørres på. Når en relasjon først er merket, kan du filtrere en liste på den, bryte ned en rapport etter den og utløse en arbeidsflyt fra den. En naken assosiasjon støtter ingen av disse presisjonsgrepene.

Datamodellen under panseret (for API-arbeid)

Hvis du noen gang skal røre API-et — eller forklare dette for en utvikler — er det tre lag som spiller sammen, alle håndtert gjennom Associations v4 API. (Det store bildet av objekter og assosiasjoner dekkes i vår guide til HubSpots datamodell.)

• Assosiasjonstyper (definisjoner) er relasjonen mellom to objekttyper på skjemanivå. Hver retning er sin egen distinkte type — kontakt-til-selskap er ikke det samme som selskap-til-kontakt — og hver bærer sin egen numeriske associationTypeId.
• Assosiasjonsetiketter er beskrivelsene du legger oppå en type. Når du oppretter en etikett, oppretter HubSpot en ny USER_DEFINED assosiasjonstype med egen typeId. Kategoriene er enten HUBSPOT_DEFINED (Primary, umerket) eller USER_DEFINED (dine etiketter).
• Definisjonskonfigurasjoner for assosiasjoner er grensene — hvor mange poster som kan assosieres, og hvor mange ganger en gitt etikett kan brukes per post.

To HubSpot-definerte typer finnes alltid i bakgrunnen. Primary markerer hovedselskapet og kan brukes i lister og arbeidsflyter på alle nivåer, inkludert Free. Umerket («Unlabeled») legges til automatisk hver gang poster assosieres, og kommer alltid tilbake fra API-et med en label som er null. Når en post har en primær eller egendefinert etikett, ligger den typen ved siden av den vedvarende umerkede typen — den erstatter den ikke.

Én ting som er verdt å vite hvis du vedlikeholder integrasjoner: HubSpot har endret visningsnavn før (Primary-selskapsetikettene fikk formatet «<Objekt> with Primary Company») uten å endre en eneste underliggende id. Det er lærdommen fra HubSpots egen endringslogg: referer til assosiasjoner i kode med typeId, aldri med etikett-tekst. Visningsnavn er for mennesker. Id-er er for kode.

Primærselskap vs. egenskapen «Company name»

Når assosiasjoner til flere selskaper er aktivert, kan en kontakt (eller avtale, eller sak) være koblet til mange selskaper — men nøyaktig ett er flagget som Primary. Og som standard blir det første selskapet du assosierer, det primære.

Samtidig er tekstegenskapen «Company name» på en kontakt noe helt annet enn «Primary associated company». Rapporter og arbeidsflyter som baserer seg på feil felt, vil villede deg i det stille.

Løsningen: standardiser på primærselskap for rapportering, og verifiser alltid primærmarkeringene etter en import eller migrering. «Først assosiert vinner» er sjelden det primærselskapet du faktisk ønsket deg.

Enkle vs. parede etiketter: hva er forskjellen?

En enkel etikett bruker ett ord for begge sider av relasjonen (som «Partner» eller «Søsterselskap»). En paret etikett bruker ulikt ord for hver side (som Parent/Child eller Leder/Ansatt) — sett den ene siden, og HubSpot legger automatisk den inverse på den andre posten.

Det er den første beslutningen du tar hver gang du oppretter en etikett.

En enkel etikett leses likt fra begge sider. Kollega. Partner. Søsterselskap. Sett den på én post, og det samme ordet dukker opp på den andre.

En paret etikett er ulik på hver side. Leder og Ansatt. Parent og Child (overordnet og underordnet). Hovedkontor og Regionkontor. Jobber du gjennom API-et, oppgir du feltet inverseLabel — og merk deg fellen: etiketten og inverseLabel kan ikke være identiske. Vil du ha dem identiske, var det en enkel etikett du ville ha hele tiden.

Én detalj som feller folk på 50-etikettgrensen: en paret etikett teller som én etikett, ikke to. Parent/Child er én enkelt oppføring i budsjettet ditt på 50, selv om den produserer to visningsnavn.

Og her er egenskapen som gjør at etiketter fungerer så godt: etiketten tilhører koblingen, ikke posten.

Én enkelt avtale kan ha mange merkede kontakter samtidig («Decision Maker», «Champion», juridisk kontakt). Én enkelt kontakt kan ha helt ulike etiketter på ulike avtaler. Samme person kan være «Champion» på én avtale og «Blocker» på en annen — og HubSpot holder styr på begge deler.

Ingen egendefinert egenskap på en kontakt kan gjøre det.

Hvilke objekter støtter assosiasjonsetiketter?

Assosiasjonsetiketter fungerer på tvers av kontakter, selskaper, avtaler, saker, leads, admin-aktiverte objekter (som Listings og Appointments) og egendefinerte objekter — inkludert par av samme objekt, som kontakt-til-kontakt og selskap-til-selskap. Ordrelinjer, produkter og tilbud støtter ikke egendefinerte etiketter.

Kjennetegnet er enkelt: hvis «Create association label» ikke vises som et valg for et objektpar, er ikke det paret støttet. Ikke let etter en innstilling som ikke finnes.

Listen er likevel i bevegelse. Nyere oppdateringer av Data Model Builder la til støtte for å opprette assosiasjoner og egendefinerte etiketter (med grenser) på handlekurv- og ordre-/fakturaobjekter, sammen med et ryddigere grensesnitt for å gjennomgå assosiasjoner og sette etikettgrenser på tvers av alle huber og nivåer.

Noen objektspesifikke regler som er verdt å kjenne før du designer noe som helst:

• Kontakter må ha et primærselskap. Med nøyaktig ett tilknyttet selskap er det selskapet primært som standard, og etiketten kan ikke fjernes. Med flere selskaper tvinges du til å velge et nytt hvis du fjerner det primære.
• Primary gjelder bare selskaper. Du kan sette et primærselskap på en kontakt, men ikke en «primærkontakt» på et selskap. Relasjonen er ikke symmetrisk.
• Selskapshierarkier bruker Parent/Child. Hver overordnet kan ha mange underordnede — men en underordnet kan bare ha én overordnet. Ha det i bakhodet før du prøver å modellere et selskap som rapporterer til to andre.

Hvilken HubSpot-plan trenger du for assosiasjonsetiketter?

Egendefinerte assosiasjonsetiketter krever et Professional- eller Enterprise-abonnement på en hvilken som helst hub — Marketing, Sales, Service, Data, Content eller Smart CRM. Free- og Starter-kontoer får bare den innebygde Primary-selskapsetiketten og standardetikettene Parent/Child for selskaper.

Ifølge HubSpots KB-artikkel «Create and use association labels»:

Tallene du jobber med

• 50 egendefinerte etiketter per objektpar — opp fra den opprinnelige grensen på 10; HubSpots formulering er «up to 50 paired or singular labels per object pair». En paret etikett teller som én.
• Assosiasjonsgrenser kan konfigureres per retning: enten «Many», eller et egendefinert tall opptil 10,000.
• Grenser per etikett begrenser hvor ofte en etikett brukes — for eksempel én «Billing contact» per selskap. Presedensregelen, rett fra KB-en: «if the number of associated contacts is limited to one and the Decision maker limit is set to many, the maximum number associated contacts is one whether or not it's labelled Decision maker». På godt norsk: totalgrensen for assosiasjoner vinner alltid.
• Maksimalt antall assosiasjoner mellom to objekttyper: 250,000 på betalte kontoer — hevet over tid fra opprinnelige 10,000. Noen par har historisk hatt lavere tak (selskap-til-sak, for eksempel), så sjekk gjeldende grensedokumentasjon før du designer noe med høyt volum.
• Parent/Child spesifikt: partneranalyser setter taket til opptil 10,000 tilknyttede underordnede selskaper per overordnet — mer enn nok for enhver reell organisasjonsstruktur.

En merknad om priser

Siden etiketter krever Pro eller Enterprise, er det egentlige kostnadsspørsmålet «hva koster det billigste kvalifiserende nivået?»

HubSpot priser per sete. Som en grov pekepinn på listepriser: Sales Hub Professional starter rundt €90/$90 per sete per måned med årlig fakturering (engangsgebyr for onboarding på €1,500/$1,500), og Sales Hub Enterprise ligger rundt €150/$150 per sete per måned (onboarding €3,500/$3,500). Service Hub speiler disse tallene tett. Marketing Hub Professional ligger høyere — omtrent €890/$890 per måned inkludert tre seter — med Enterprise rundt €3,600/$3,600 per måned. Starter ligger rundt €15–20/$15–20 per sete per måned og låser ikke opp egendefinerte etiketter.

Et reelt forbehold: HubSpots prisside endres ofte, og det eksakte årlige EUR-tallet for Sales Hub Professional varierer mellom kilder (du vil se både €90 årlig og €100 månedlig sitert). EUR- og USD-listepriser er omtrent 1:1, og årlig fakturering sparer et sted mellom 10 % og 40 % sammenlignet med månedlig. Bekreft alltid på hubspot.com/pricing før du legger et tall foran en kunde — vår komplette prisguide holder det store bildet oppdatert.

Hvordan bruker du assosiasjonsetiketter? (8 RevOps-brukstilfeller)

Åtte mønstre går igjen og igjen i virkelige portaler.

1. Kjøpskomiteer

Flaggskip-brukstilfellet for B2B SaaS.

Opprett avtale-til-kontakt-etiketter for rollene som betyr noe: «Decision Maker», «Champion», «Economic Buyer», «Technical Evaluator», «Influencer», «End User», «Legal/Compliance», «Blocker», «Billing contact».

Fordi rollen ligger på koblingen mellom avtale og kontakt i stedet for på kontakten, kan samme person være «Champion» på én avtale og «Blocker» på en annen uten noen konflikt.

Dette gjør en avtale om fra en enkeltkontaktpost til et kart over kjøpsgruppen. Send kontrakten kun til den juridiske gjennomgåeren. Varsle selgeren hvis ingen «Decision Maker» er merket innen et gitt stadium.

Det er også HubSpots anbefalte alternativ til å bygge et egendefinert objekt for kjøpsgrupper: et egendefinert objekt legger til kompleksitet, blokkerer innebygd rapportering og er sjelden nødvendig når en etikett bærer rollen. (Hvordan dette henger sammen med den separate Buying Groups-funksjonen, dekkes i vår guide til kjøpsgrupper og kjøpsroller.)

Profftips: lån denne styringsregelen — ingen avtale går forbi discovery uten minst tre merkede interessenter. Det er en enkel tvangsmekanisme som avdekker avtaler med bare én tråd (de som mest sannsynlig dør når din ene kontakt slutter) før de blir et prognoseproblem.

2. Kundesuksess og kontoroller

Samme mekanisme, etter salget. Kontakt-til-selskap-etiketter som «Primary contact», «Billing contact», «Executive sponsor», «Admin/Power user», «Renewal contact» og «Support contact» lar CS og support se med et blikk hvem som gjør hva — rett på assosiasjonskortene på selskapsposten. Ingen klikking inn i kontaktposter for å gjette.

3. Kontobaserte strukturer

Assosier hver interessent til riktig selskap, merk rollene, og du kan drive automatisering på kontonivå — territorietildeling, eierrotasjon, livssyklusoppdateringer — pluss kontobasert rapportering som faktisk stemmer med hvordan økonomiavdelingen teller kontoen.

Der én kontakt spenner over flere enheter (en rektor knyttet til både en skole og skoledistriktet, for eksempel), skiller etiketter relasjonene rent fra hverandre.

4. Selskapshierarkier

Bruk den parede standardetiketten Parent/Child for konserneierskap, og egendefinerte selskap-til-selskap-etiketter for alt som ikke er strengt overordnet og underordnet. Dette fortjener sin egen seksjon — se «Hvordan modellere komplekse selskapsstrukturer» nedenfor.

5. Avtaler med flere selskaper og partnere

Mange avtaler involverer mer enn ett selskap — et byrå som kjøper på vegne av en sluttkunde, eller en partnersourcet avtale.

Assosier begge selskapene til den ene avtalen og merk dem (for eksempel «Agency» og «End client», eller «Partner» og «Referred account») slik at attribusjon og eierskap forblir tydelig uansett hvem som ser på posten senere.

Dette er også slik du får rapporter på antall avtaler og verdi knyttet utelukkende til partnerselskaper — ryggraden i rapportering av partnersourcet inntekt. For provisjonssporing modellerer noen team en ekstra koblet avtale for partnerens andel.

6. Arbeidsflyter og automatisering

Etiketter dukker opp over hele automatiseringen: registreringsutløsere («meld på avtaler assosiert med en kontakt merket Economic Buyer»), hvis/så-grener, «Edit record»-handlinger som setter eller kopierer egenskaper til assosierte poster med en bestemt etikett, og «Send email»-handlinger rettet mot assosierte kontakter filtrert på etikett.

Den største spaken er likevel settet med fire dedikerte arbeidsflythandlinger for assosiasjoner:

1. Create associations
2. Apply association labels
3. Update association labels
4. Remove association labels

Create-handlingen matcher poster på egenskapsverdier — og ifølge HubSpots lanseringsnotat finnes den matchingen «only exists for single-line text, multi-line text, or phone number properties». Planlegg matchenøklene dine deretter.

Handlingene er tilgjengelige i arbeidsflyter for kontakter, selskaper, avtaler, saker, leads, fakturaer, ordrer, betalinger, abonnementer og egendefinerte objekter (ikke produkter eller tilbud).

To operative tall å kjenne: arbeidsflytbaserte assosiasjonshandlinger har et tak på 100 assosiasjoner per handling, og create-associations har et utførelsestak på 5 millioner per dag, der en merket opprettelse teller som to utførelser.

7. Lister, rapporter og dashbord

På Pro og Enterprise kan du filtrere lister og segmenter på etiketter.

I den egendefinerte rapportbyggeren avgjør den primære datakilden hvilke etiketter som er tilgjengelige; du legger til et sekundært objekt og velger deretter «Choose association labels» for å avgrense rapporten, med etiketter som kan brukes som akse, nedbryting eller filter. Retning betyr noe med parede etiketter — velger du «Child Company → Parent Company», blir underordnede selskaper den primære kilden.

Kjenn den skarpe kanten før du bygger: å velge en etikett som datakildeavgrensning ekskluderer alle poster med andre etiketter og uten etikett fra hele rapporten. Det er ofte ikke det du vil, og det er en hyppig klage i community-et. Standardomveien er å bygge en liste først og rapportere fra listen.

Profftips: bygg opptellingsegenskaper på en etikett (et antall «Billing contact»-assosiasjoner per avtale, for eksempel) for å oppdage manglende roller. Bare pass på at opptellingen nøkles på Record ID, ikke e-post — en kontakt uten nøkkelegenskapen bryter opptellingen i det stille.

8. Ruting, eierskap og deal splits

Gren arbeidsflyter på merkede assosiasjoner for å rute avtaler eller saker til riktig eier eller team automatisk.

Og en oppklaring, fordi folk blander disse: for å dele inntektskreditt mellom brukere har HubSpot en separat innebygd Deal Splits-funksjon (Sales og Service Pro og Enterprise). Den er noe annet enn etiketter, som beskriver relasjoner mellom poster, ikke brukerkreditt. For partnersourcet attribusjon er merkede selskap-til-avtale-assosiasjoner («Channel Partner», «Distributor», «Referral») det anerkjente mønsteret. Én stående begrensning å flagge for økonomi: deal split-prosenter flyter ikke inn i enkeltselgeres måloppnåelse for inntekt som standard.

Å designe en etikett-taksonomi som overlever møtet med et ekte salgsteam, er vanskeligere enn det ser ut. Snakk med Superwork om et HubSpot RevOps-engasjement, så kartlegger vi kjøpskomitérollene, selskapshierarkiene og arbeidsflytutløserne dine inn i et rent, styrbart etikettsystem — og bygger rapporteringen som beviser at det brukes.

Hvordan modellere komplekse selskapsstrukturer i HubSpot

Modeller selskapshierarkier med de innebygde Parent/Child-etikettene, og alt annet — forhandlere, byråer, franchiser, søsterselskaper — med egendefinerte selskap-til-selskap-etiketter. De tre harde grensene å designe rundt: én overordnet per underordnet, ingen innebygd roll-up av data fra underordnet til overordnet, og ingen innebygd orgkartvisning.

Hvis kontoene dine er holdingselskaper, franchisenettverk eller partnerøkosystemer, er det her etiketter blir satt på prøve. Slik jobber du med det som finnes — og rundt det som ikke gjør det.

Parent/Child-hierarkier og holdingselskaper

Den innebygde parede Parent/Child-etiketten er ryggraden, og den er tilgjengelig på alle planer, Free inkludert.

For et holdingselskap er holdingselskapet overordnet og hvert driftsselskap underordnet. Kardinalitetsregelen, ordrett fra HubSpots kunnskapsbase: «Each parent company can have multiple associated child companies, but a child company can only be associated with one parent company.»

Kjeder i flere nivåer fungerer — et selskap kan være underordnet ett selskap og overordnet andre, og HubSpots egen dokumentasjon går gjennom et eksempel i tre nivåer. Det HubSpot blokkerer, er løkker, der en post ender opp assosiert til seg selv et sted nedover kjeden.

Du kan sette relasjonene manuelt eller via import, med én rekkefølgeregel: overordnede selskaper må eksistere før du importerer deres underordnede.

Før du bygger noe som helst, bli enige internt om hva en «selskaps»-post i det hele tatt betyr i portalen deres — juridisk enhet, merkevare eller lokasjon. Et hierarki bygget på blandede definisjoner er verre enn ikke noe hierarki. Beste praksis blant partnere er konsekvent her: velg én definisjon, bruk konsekvent navngivning (legg til region eller HQ for å skille like datterselskaper), hold hierarkiet grunt, og revider det jevnlig.

De 3 grensene å designe rundt

Grense 1: Én overordnet per underordnet. Ekte strukturer med flere eiere — et joint venture eid av to konserner, for eksempel — støttes ikke innebygd. Velg den kontrollerende enheten som overordnet og modeller den andre relasjonen med en egendefinert etikett.

Grense 2: Ingen innebygd roll-up. HubSpot bekrefter at det ikke finnes noen datasynkronisering mellom overordnede og underordnede selskaper: tilknyttede kontakter, avtaler og aktiviteter blir på sine egne poster og aggregeres ikke oppover. Det finnes ingen innebygd «total inntekt på tvers av alle underordnede selskaper» — det er en langvarig, toppstemt idé som fortsatt ikke er lansert. Omveiene: egendefinerte roll-up-egenskaper med Data/Operations Hub, spesialkodede løsninger, eller marketplace-apper (Insycle for masseadministrasjon av assosiasjoner og deduplisering, Koalify for automatisk assosiering med flere betingelser).

Grense 3: Ingen innebygd orgkart. Å visualisere et selskapshierarki krever en marketplace-app. HubSpot kjøpte OrgChartHub, men den funksjonaliteten dukket opp igjen som Buying Groups-betaen på kontaktnivå — ikke en trevisning for selskap-til-selskap.

Det finnes en arbeidsflyt-konsekvens også: automatisering som leser data fra en underordnet og skriver til den overordnede, er begrenset — arbeidsflyter på tvers av hierarkiet er et av de svakeste punktene i modellen. Hvis rapportering på overordnet nivå er et reelt krav, budsjetter for Operations Hub eller et tredjepartsverktøy fra dag én i stedet for å oppdage hullet i måned tre.

Partnere, forhandlere, henvisninger og byråer

Motstå fristelsen til å misbruke Parent/Child for partnerrelasjoner — reserver den for faktisk konserneierskap.

Du har to rene modelleringsvalg i stedet:

1. Egendefinerte selskap-til-selskap-etiketter. Opprett parede etiketter som «Reseller»/«Client», «Distributor»/«Reseller», «Referral partner»/«Referred account» eller «Agency»/«Client». Relasjonen forblir strukturell og rapporterbar, og den overlever enhver enkeltavtale.
2. Assosiasjoner på avtalenivå. Assosier både sluttkunden og partnerselskapet (eller kontakten) til avtalen, og merk partnersiden. Dette er mønsteret for rapportering av partnersourcet inntekt, dekket i brukstilfellene over.

Bruk begge der det gir mening: selskap-til-selskap-etiketten fanger den stående relasjonen; etiketten på avtalenivå fanger hvem som rørte akkurat denne inntektsbiten.

Franchiser og virksomheter med flere lokasjoner

Modeller franchisegiveren som overordnet og hver lokasjon som underordnet — eller, hvis eierstrukturen er mer føderasjon enn hierarki, bruk en egendefinert paret etikett som «Franchise HQ»/«Location» i stedet.

For større nettverk kommer HubSpots Business Units (merkevareseparasjon) og arkitekturer med flere portaler inn i bildet.

Og her er skillelinjen som holder modellen ren: assosiasjonsetiketter håndterer relasjonen; franchisespesifikke data med egne attributter — royaltyperioder, helsescore per lokasjon — hører hjemme i et egendefinert objekt (Enterprise). Ikke prøv å få en etikett til å bære data.

Søsterselskaper

Det finnes ingen innebygd søsteretikett. Opprett en symmetrisk enkel etikett — «Sibling company» — og bruk arbeidsflythandlingene for assosiasjoner til å auto-assosiere underordnede som deler samme overordnede. Én arbeidsflyt, og datterselskapene dine vet om hverandre.

Kjører du en holdingstruktur, franchise eller partnertung kontostruktur i HubSpot og er usikker på om etiketter, roll-up-egenskaper eller et egendefinert objekt er riktig ryggrad? Ta kontakt med Superwork — vi designer og bygger disse hierarkiene for B2B-selskaper, roll-up-rapportering inkludert.

Assosiasjonsetiketter vs. egendefinerte egenskaper vs. egendefinerte objekter: hva bør du bruke?

Bruk en assosiasjonsetikett når en relasjon har en rolle du vil filtrere, automatisere eller rapportere på. Bruk en egendefinert egenskap for ett enkelt attributt som endrer seg sakte på én post. Bruk et egendefinert objekt bare når relasjonen i seg selv er en entitet med egne data — abonnementer, kontrakter, lokasjoner.

Tre verktøy, tre jobber. Tar du denne beslutningen riktig fra start, sparer du deg for en smertefull remodellering senere.

Assosiasjonsetikett — for roller og relasjonstyper, spesielt mange-til-mange-situasjoner der samme kontakt er «Champion» på én avtale og «Blocker» på en annen. Tommelfingerregelen: hvis rollen endrer betydningen av relasjonen, fortjener den en etikett.

Egendefinert egenskap — for ett enkelt attributt som endrer seg sakte på én post (nåværende plannivå, en kjøpsrolle registrert flatt på kontakten). Enklere å rapportere på, tilgjengelig på alle nivåer. Men den skalerer ikke til mange-til-mange: én «kjøpsrolle»-egenskap på en kontakt kan ikke uttrykke at rollen varierer per avtale.

Egendefinert objekt — for relasjoner som er entiteter i seg selv, med egne egenskaper: abonnementer, kontrakter, franchiselokasjoner med royaltydata. Kjenn kostnadene: kun Enterprise, teller mot objektgrensene, kan ikke brukes i lister (bare egendefinerte rapporter), og legger til rapporteringskompleksitet. Ikke bygg et egendefinert objekt bare for å representere en relasjonsrolle — en etikett gjør det innebygd, og HubSpots egen veiledning peker samme vei. (Når egendefinerte objekter faktisk gjør nytte for seg, har vi dekket det i guiden om egendefinerte objekter.)

Signalet for å gå videre: når en relasjon begynner å samle egne attributter over tid — abonnementsvilkår, kontraktsverdier, lokasjonsmålinger — har den vokst ut av en etikett. Det er da et egendefinert objekt er verdt kompleksiteten.

Hvordan setter du opp HubSpot-assosiasjonsetiketter? (Steg for steg)

For å opprette HubSpot-assosiasjonsetiketter trenger du Super Admin-rettigheter og et Professional- eller Enterprise-abonnement. Gå til Settings → Objects → velg objektet → Associations-fanen → Create association label — eller bruk Data Model Builder under Data Management → Data Model.

To veier, samme mål.

Vei A — gjennom Settings:

1. Gå til Settings → Objects → velg objektet → Associations-fanen.
2. Klikk Create and configure → Create and configure label limits.
3. Velg objektrelasjonen (avtaler-til-kontakter, for eksempel), velg enkel eller paret, og gi den et navn. Hold navnet rent — unngå semikolon og ikke-alfanumeriske tegn, fordi de ødelegger importer.
4. Rediger eventuelt det interne navnet (det API-et og integrasjoner bruker). Vær forsiktig: det interne navnet er uforanderlig etter opprettelse, så få det riktig første gang.
5. Klikk Next, sett grensene per retning, og Save.

Vei B — gjennom Data Model: gå til Data Management → Data Model → Edit Data Model → Associations-fanen → velg objektet → klikk ellipsen på det relaterte objektet → Create association label. Du kan også bruke Breeze Copilot til å opprette etiketter i samtaleform.

Uansett vei: når du har opprettet etiketten, oppdater en post, og den dukker opp i nedtrekksmenyen.

Å sette på etiketter. På en post, hold pekeren over assosiasjonskortet → More → Edit association labels → velg etiketten(e) → Update. Når du oppretter og assosierer en helt ny post samtidig, sett etiketten etter at posten er opprettet, ikke underveis. For massebruk, bruk import (ta med assosiasjonskolonnene og legg til etiketten) eller API-et og arbeidsflyter.

Redigere, gi nytt navn, slette. Tilbake i Settings → Objects → Associations, hold pekeren over en etikett og klikk More. Derfra kan du velge Edit label (bare visningsnavnet — det interne navnet forblir låst), Edit label limit, View API details (navn, invers, internt navn, grenser, kategori og associationTypeId), View history eller Delete. Sletting er irreversibel, og hvis etiketten er i bruk på poster eller i verktøy, må du fjerne den fra disse ressursene først.

Å jobbe med API-et

Associations v4 API deler seg i to endepunktsett: skjema-endepunkter (vis, opprett og administrer typer, etiketter og grenser) og detalj-endepunkter (opprett, rediger og fjern assosiasjoner på faktiske poster).

Kallene du oftest vil trenge:

• Hent etiketter: GET /crm/v4/associations/{from}/{to}/labels — returnerer category, typeId og label.
• Opprett en etikett: POST /crm/v4/associations/{from}/{to}/labels — inkluder label, og for en paret etikett, inverseLabel (husk at de to ikke kan være like).
• Opprett merkede assosiasjoner: inkluder associationCategory (HUBSPOT_DEFINED eller USER_DEFINED) og associationTypeId. Du kan batche opptil 2,000 innslag per kall.

Marketplace-apper som Workflow Associations Manager og Associ8 legger til etikettautomatisering som arbeidsflythandlinger hvis du helst slipper å skrive egen kode.

5 oppsettsfeil å unngå

1. Ikke overlast et objektpar. Seks til åtte etiketter dekker de fleste kjøpskomiteer. Flere enn det, og selgeradopsjonen stuper — hver ekstra etikett er én ting til noen må huske å sette.
2. Unngå søppeletiketter. «Related», «Linked» og andre vage beskrivelser er ubrukelige i rapporter og arbeidsflyter. Kan du ikke filtrere eller automatisere meningsfullt på den, ikke opprett den.
3. Dropp semikolon og spesialtegn i navn — de kolliderer med importskilletegn.
4. Oppdater arbeidsflytene dine etter at du har lagt til etiketter. Eksisterende automatiseringer gjenkjenner ikke en ny etikett automatisk; du må legge den til i de relevante utløserne og grenene.
5. Planlegg en tilbakefylling. Nye etiketter merker ikke eksisterende assosiasjoner med tilbakevirkende kraft. Vil du ha historiske avtaler merket, trenger du en import.

Hva kan ikke assosiasjonsetiketter gjøre? (Begrensninger og feller)

De fire store: etiketter kan ikke gjøres obligatoriske innebygd, det finnes ikke noe «har ikke etikett»-filter, kontakt-til-selskap-etiketter synkroniseres ikke til Salesforce gjennom den innebygde koblingen, og overordnede/underordnede selskaper deler ingen data. Hver har en omvei — ingen av dem er usynlig.

Ærlige begrensninger redder deg fra å designe rundt funksjonalitet som ikke finnes.

Etiketter kan ikke gjøres obligatoriske innebygd. Et langvarig, toppstemt funksjonsønske. Du kan ikke tvinge en avtale til å ha en «Decision Maker» før den opprettes eller går videre et stadium. Den vanlige omveien: en skrivebeskyttet avtaleegenskap (en avkrysningsboks) som en arbeidsflyt setter når en tilknyttet kontakt bærer den påkrevde etiketten, og gjør så den egenskapen påkrevd på et pipelinestadium. Men lettelse er på vei: med den annonserte /2026-09/ API-versjonen vil admin-konfigurerte valideringsregler — inkludert betinget påkrevde egenskaper og assosiasjonsrettigheter på brukernivå — håndheves på API-skrivinger, ikke bare i grensesnittet. Håndhever du assosiasjons- eller etikettkomplettering gjennom integrasjoner, sett det på veikartet ditt.

Automatisering på tvers av hierarkiet er begrenset. Å kopiere verdier mellom overordnede og underordnede selskaper støttes ikke rett ut av boksen — automatisering som leser data fra en underordnet og skriver til den overordnede, er det svake punktet i hierarkimodellen. Tredjepartsverktøy som Insycle eller Koalify, eller en egendefinert kodehandling i Operations Hub, tetter hullet. (Å opprette assosiasjoner via arbeidsflyt er derimot løst av de dedikerte arbeidsflythandlingene — med forbeholdet om at egenskapsmatching bare fungerer på enkeltlinjetekst, flerlinjetekst og telefonnummeregenskaper.)

Salesforce-synkronisering er nyansert — og nyansen betyr noe. Den nyere HubSpot–Salesforce-selskapssynkroniseringen kan synkronisere assosiasjonsetiketter for selskaper, avtaler, saker og egendefinerte objekter, med valgbar synkroniseringsretning — ifølge KB-en: «Association labels for companies, deals, tickets, and custom objects are supported for sync via the HubSpot-Salesforce integration.» Det kjente hullet er kontakt-til-selskap-etiketter, som den innebygde koblingen ikke synkroniserer — et hyppig smertepunkt, vanligvis løst med tredjepartsverktøy (Associ8, for eksempel) eller egen mellomvare. Vær klar over at HubSpots egen dokumentasjon har inneholdt motstridende utsagn om etikettsynkronisering over tid, så verifiser mot portalens koblingsversjon før du forplikter en kunde — eller din egen arkitektur — til det.

Rapportering og listefiltrering er lite intuitivt. For å filtrere en kontaktliste på en kontakt-til-selskap-etikett må du først legge til et selskapsegenskapsfilter (som «Company name is known»), og først da dukker etikettnedtrekket opp under «Any company». For å rapportere på kontakters avtaleetiketter må du bruke den egendefinerte rapportbyggeren med begge objektene i rapporten. Det fungerer — det er bare ikke der du ville forvente det.

Det finnes ikke noe «is none of»- eller «har ikke etikett»-filter. Å finne poster som mangler en etikett krever omveier via listemedlemskap eller rapporttriks. Dette biter hver gang du vil finne for eksempel avtaler uten «Decision Maker».

Du kan ikke filtrere spesifikt på Primary-assosiasjonens etikett. Filtre evaluerer «any associated object», så du kan ikke isolere et skille mellom primære og ikke-primære etiketter.

Parent/Child blokkerer sammenslåinger. For å slå sammen to selskaper som har en Parent/Child-etikett mellom seg, fjern etiketten først. Sammenslåinger feiler også med Salesforce-synkronisering skrudd på etter 250 kombinerte sammenslåinger.

Skal du migrere? Planlegg dette på forhånd

Kartlegg kildens «kontaktroller» eller relasjonsfelter til HubSpot-etiketter før du importerer noe som helst — å ettermontere senere er smertefullt.

Husk taket på 50 etiketter per par og taket på 250,000 assosiasjoner per objekttype på betalte kontoer når du estimerer volum. Sett av tid til å tilbakefylle etiketter via import, siden de ikke gjelder med tilbakevirkende kraft.

Verifiser primærselskapsmarkeringene etter enhver import eller migrering — det første selskapet som assosieres, blir automatisk Primary, som sjelden er det du mente.

Assosiasjonsarbeid i bulk er enklest via import (nøklet på Record ID eller domene) eller arbeidsflythandlingene for assosiasjoner; for opprydding i stor skala eller i flernivåhierarkier er tredjepartsverktøy som Insycle og Koalify standardvalget.

Om styring: hold en dokumentert etikettordbok, bruk klare og handlingsorienterte navn, standardiser retningen på de parede etikettene dine, begrens etikettadministrasjon til Super Admins, og gjennomgå utfyllingsgraden jevnlig. En ubrukt etikett er verre enn ingen etikett — den gir deg falsk trygghet i rapportene dine.

Hvor assosiasjonsetiketter står i dag

Hvis du vurderte assosiasjonsetiketter for en stund siden og gikk videre, har funksjonen modnet betydelig. Her er dagens tilstand i korte trekk:

Lansert og stabilt:

• 50 etiketter per objektpar (opp fra de opprinnelige 10)
• Fire dedikerte arbeidsflythandlinger — Create associations, Apply/Update/Remove association labels — slik at etiketthåndtering kjører på automatisering i stedet for selgeres hukommelse
• Volumtak for assosiasjoner på 250,000 per objekttype på betalte kontoer
• Data Model Builder-støtte for å gjennomgå assosiasjoner og sette etiketter og grenser, inkludert på handlekurv- og ordre-/fakturaobjekter

Annonsert og på vei:

• API-versjonen /2026-09/ vil håndheve admin-konfigurerte valideringsregler på API-skrivinger, som åpner døren for reell håndheving av assosiasjonskomplettering i integrasjonstunge portaler

Mangler fortsatt:

• Innebygde orgkart for selskaper, roll-ups mellom parent/child og obligatoriske etiketter. Den nærmeste innebygde bevegelsen er OrgChartHub-oppkjøpet som dukket opp igjen som Buying Groups-betaen på kontaktnivå.

Slik ruller du ut assosiasjonsetiketter (5 stadier)

Starter du fra null, er dette en rekkefølge som fungerer.

Stadium 1 — Bekreft nivå og omfang (uke 1). Verifiser at kontoen er på Professional eller Enterprise av en hvilken som helst Hub, eller Smart CRM Pro/Enterprise. På Free eller Starter er egendefinerte etiketter ikke tilgjengelige — modeller relasjoner med egendefinerte egenskaper som en midlertidig løsning, og bygg oppgraderingsargumentet rundt innsyn i kjøpskomiteer og renere rapportering. Terskelspørsmålet: trenger du å segmentere, rapportere og automatisere på relasjonsroller, eller bare på at relasjonen finnes? Er det roller, trenger du etiketter.

Stadium 2 — Design taksonomien før du bygger (uke 1–2). Utkast en etikettordbok for hvert objektpar. Sett tak på seks til åtte etiketter for kjøpskomiteer. Bestem enkel versus paret for hver, og dokumenter de interne navnene, siden de er permanente. Trenger du genuint mer enn 50 etiketter på ett par, er det et signal om å revurdere modellen — et egendefinert objekt eller en egenskap kan passe bedre.

Stadium 3 — Konfigurer og pilotér (uke 2–3). Opprett etikettene, sett grenser per retning og per etikett (én «Billing contact» per avtale, for eksempel), og pilotér på én enkelt pipeline. Implementer regelen «minst tre merkede interessenter før discovery avsluttes» med en skrivebeskyttet egenskap pluss en arbeidsflyt, siden etiketter ikke kan gjøres påkrevd direkte.

Stadium 4 — Automatiser og rapporter (uke 3–5). Bygg arbeidsflytpåmelding og grener på etiketter, bruk arbeidsflythandlingene for assosiasjoner til å auto-sette etiketter fra egenskapsmatcher (husk: matching fungerer kun på enkeltlinjetekst, flerlinjetekst og telefonegenskaper), og bygg opptellingsegenskaper nøklet på Record ID for å flagge manglende kritiske roller. Bygg deretter dashbordet i den egendefinerte rapportbyggeren for komitédekning («avtaler over €50k/$50k uten Decision Maker») og lister over underordnede selskaper under hver overordnet. Der etikettavgrensningsbegrensningen biter, rapporter fra en forhåndsbygd liste i stedet.

Stadium 5 — Styr (løpende). Begrens etikettadministrasjon til Super Admins, utnevn en navngitt dataforvalter, revider utfyllingsgraden kvartalsvis, og tilbakefyll historiske assosiasjoner via import. Dokumenter modellen slik at neste admin arver en taksonomi, ikke et arkeologiprosjekt. Revurder Buying Groups når den når generell tilgjengelighet eller når du går over til Sales Hub Enterprise — men ikke oppgrader utelukkende for den, fordi etiketter allerede leverer komitémodellering på Professional.

4 signaler som bør endre tilnærmingen din

• Du trenger ekte roll-ups av inntekt eller aktivitet på overordnet nivå, strukturer med flere overordnede, eller et visuelt orgkart → etiketter alene kommer ikke dit. Legg til Data/Operations Hub-roll-ups eller en marketplace-app (Insycle, Koalify, OrgChartHub/DemandFarm), eller vurder ærlig en modell med egendefinerte objekter.
• En relasjon samler egne attributter over tid (abonnementsvilkår, kontraktsverdier, lokasjonsmålinger) → gå fra en etikett til et egendefinert objekt.
• Du nærmer deg 50 etiketter på ett par, eller selgere kan ikke forklare hva en etikett betyr → taksonomien er for kompleks. Konsolider.
• Salesforce er masterkilden («system of record») for kontaktroller → ikke stol på den innebygde koblingen for synkronisering av kontakt-til-selskap-etiketter. Budsjetter for tredjepartssynkronisering eller mellomvare fra dag én.

Ofte stilte spørsmål

Hva er assosiasjonsetiketter i HubSpot?

Assosiasjonsetiketter beskriver hvorfor to CRM-poster er koblet sammen. En vanlig assosiasjon sier at to poster er koblet; en etikett legger til kontekst — for eksempel at en kontakt er «Decision Maker» på en avtale, eller at ett selskap er «Parent» (overordnet) for et annet. Etiketten ligger på relasjonen mellom de to postene, ikke på noen av postene alene.

Hvilken HubSpot-plan trenger jeg for assosiasjonsetiketter?

Egendefinerte assosiasjonsetiketter krever Professional eller Enterprise på en hvilken som helst Hub (Marketing, Sales, Service, Data eller Content) eller på Smart CRM. Free- og Starter-kontoer kan bare bruke den innebygde Primary-selskapsetiketten og standardetikettene Parent/Child for selskaper.

Hvor mange assosiasjonsetiketter kan jeg opprette?

Opptil 50 egendefinerte etiketter per objektpar (som kontakt-til-avtale), opp fra den opprinnelige grensen på 10. En paret etikett som Parent/Child teller som én enkelt etikett mot den grensen.

Hva er forskjellen på assosiasjonsetiketter og Buying Groups?

Assosiasjonsetiketter er den underliggende mekanismen for å beskrive relasjoner, og de fungerer på Professional. Buying Groups er en separat funksjon på Enterprise-nivå (for tiden i offentlig beta) som legger et visuelt orgkart og AI-autobygging oppå det konseptet. Du kan modellere en full kjøpskomité med etiketter alene — du trenger ikke Buying Groups eller Enterprise for å gjøre det.

Kan jeg gjøre assosiasjonsetiketter påkrevd?

Ikke innebygd. Den vanlige omveien er en skrivebeskyttet egenskap satt av en arbeidsflyt som sjekker etter en tilknyttet post med den påkrevde etiketten, og deretter gjøre den egenskapen påkrevd på et pipelinestadium. To ting peker mot endring: en privat beta for «Required Association Labels for Manual Record Creation», og den annonserte API-versjonen /2026-09/, som vil håndheve admin-konfigurerte valideringsregler på API-skrivinger.

Kan jeg filtrere lister og rapporter på assosiasjonsetikett?

Ja, på Professional og Enterprise — men filtreringen er lite intuitiv. For kontakt-til-selskap-etiketter må du først legge til et selskapsegenskapsfilter før etikettnedtrekket dukker opp, og for kontakters avtaleetiketter bruker du den egendefinerte rapportbyggeren med begge objektene i rapporten.

Synkroniseres assosiasjonsetiketter til Salesforce?

Delvis. Den nyere HubSpot–Salesforce-selskapssynkroniseringen støtter assosiasjonsetiketter for selskaper, avtaler, saker og egendefinerte objekter, med valgbar synkroniseringsretning. Kontakt-til-selskap-etiketter er det kjente hullet — den innebygde koblingen synkroniserer dem ikke, så team bruker tredjepartsverktøy (som Associ8) eller egen mellomvare. HubSpots dokumentasjon har vært inkonsistent på dette over tid, så verifiser i portalens koblingsversjon.

Kan et underordnet selskap ha to overordnede?

Nei. Hvert underordnet selskap kan bare ha én overordnet. En overordnet kan ha mange underordnede (opptil 10,000, ifølge partneranalyser), men relasjonen går bare én vei. Kjeder i flere nivåer går fint — et selskap kan være underordnet ett selskap og overordnet andre — men løkker blokkeres.

Rulles data opp fra underordnede selskaper til den overordnede?

Nei. Det finnes ingen innebygd datasynkronisering mellom overordnede og underordnede selskaper — kontakter, avtaler og aktiviteter blir på sine egne poster og aggregeres ikke oppover. Roll-ups på overordnet nivå krever egendefinerte roll-up-egenskaper i Data/Operations Hub, egen kode eller en marketplace-app. Innebygd roll-up er en langvarig, toppstemt idé som ikke er lansert.

Kan HubSpot vise et visuelt orgkart over et selskapshierarki?

Ikke innebygd. Å visualisere selskapshierarkier krever en marketplace-app. HubSpot kjøpte OrgChartHub, men den funksjonaliteten dukket opp igjen som Buying Groups-betaen på kontaktnivå — ikke en trevisning for selskap-til-selskap.

Hvordan legger jeg til assosiasjonsetiketter via API-et?

Bruk Associations v4 API. Opprett en etikett med POST /crm/v4/associations/{from}/{to}/labels (inkluder label, og inverseLabel for en paret etikett — de to kan ikke være identiske). Opprett merkede assosiasjoner ved å inkludere associationCategory og associationTypeId, batchet opptil 2,000 innslag per kall.

Kan arbeidsflyter opprette assosiasjoner eller sette etiketter automatisk?

Ja. Fire dedikerte arbeidsflythandlinger (på Pro og Enterprise) oppretter assosiasjoner og setter, oppdaterer eller fjerner etiketter. Forbeholdene: create-handlingen matcher poster kun på egenskaper av typen enkeltlinjetekst, flerlinjetekst eller telefonnummer; hver handling har et tak på 100 assosiasjoner; og create-associations har en utførelsesgrense på 5M/dag (en merket opprettelse teller som to). Det som fortsatt er begrenset, er dataflytting på tvers av hierarkiet — å kopiere verdier mellom overordnede og underordnede selskaper krever fortsatt egendefinert kode i Operations Hub eller et tredjepartsverktøy.

Konklusjonen

Assosiasjonsetiketter er en av funksjonene i HubSpot med høyest effekt og lavest kostnad for alle som tar RevOps på alvor.

De gjør vage koblinger om til strukturert, spørrbar innsikt — og lar deg modellere kjøpskomiteer, selskapshierarkier og avtaler med flere selskaper uten å kjøpe et eneste tillegg, så lenge du er på Professional eller høyere.

Gevinstene er reelle: renere rapportering, smartere automatisering og tidlig varsling på avtaler med bare én tråd inn.

Det er grensene også: ingen obligatoriske etiketter (frem til de annonserte API-valideringsreglene lander), ingen synkronisering av kontakt-til-selskap-etiketter til Salesforce, ingen parent/child-roll-ups, intet «is none of»-filter, og et tak på 50 etiketter per par som belønner en disiplinert taksonomi fremfor en uoversiktlig en.

Design systemet før du bygger det. Automatiser det med arbeidsflythandlingene. Styr det etterpå. Du får årevis med verdi ut av det.

Og hvis du vil ha et ekstra par øyne på strategien din for HubSpot-assosiasjonsetiketter — eller hjelp til å bygge arbeidsflytene og rapportene som får etikettene til å betale seg — ta kontakt med Superwork, så kartlegger vi det sammen med deg.

Detaljer om funksjoner, grenser og nivåer er forankret i HubSpots offisielle kunnskapsbase og utviklerdokumentasjon, og denne guiden oppdateres etter hvert som HubSpot lanserer endringer. Noen ærlige merknader om kildene: enkelte numeriske grenser (100 assosiasjoner per arbeidsflythandling, utførelsestaket på 5M per dag, taket på 250,000 assosiasjoner) kommer fra HubSpot-dokumentasjon og community-tråder og kan endres; fraværet av innebygde roll-ups, orgkart og obligatoriske etiketter er fastslått ut fra HubSpots idétavler og kan bli løst av en produktlansering når som helst; og flere av praktikerteknikkene som siteres, stammer fra partner- og leverandørblogger med kommersiell interesse — teknikkene er solide og bekreftet, men behandle verktøyanbefalinger deretter. Priser og betastatus endres ofte — verifiser i en aktiv HubSpot-økt før du oppgir konkrete tall til kunder.