> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Audience hub console map — contacts, segments, and every identity you send from > A map of the consoles under the Audience hub — Contacts, Lists, Segments, Identity resolution, Merge, Consent, Opt-outs, Senders, Activation, Imports, and the scoring surfaces — what each answers on a first visit, which seats can touch it, the rollout order that works with its skip conditions, and links to the in-depth guides and concept pages behind each console. # Audience hub console map — contacts, segments, and every identity you send from The Audience docs split coverage by feature — a deep guide for segments, one for identity resolution, one for the senders hub — because that is how the features shipped. Operators do not work that way. A tenant rolling out its customer-data layer asks one question: *what do I know about a contact, and what can I send them from?* This page answers it, collecting the consoles under the **Audience** hub in the dashboard into one map. Every console below is a tenant-owned control — you set it for your workspace, and no PII surface renders a row until you put data in. Each maps 1:1 to a route under `/audience` in the dashboard. ## Why the hub is a map The Audience hub groups every control for the surfaces that read or shape your contact base: the contacts themselves, the lists and segments that slice them, the identity machinery that keeps one person one profile, the consent and opt-out records that gate what you may send, the sender identities every outbound message signs from, and the scoring surfaces that rank contacts before you activate them. One question brings an operator here — *what do I know about a contact?* — and the hub answers it across contact, segment, list, identity, activation, and send surfaces. Use the map to pick the right console instead of opening the per-feature guide first; each row links its in-depth guide. ## Tile map Each row is a hub tile (or a route one hop deeper). The PII-marked rows render only for owner/admin/developer seats, mirroring the read gate over the PII-bearing customer-event stream (see [Permission scopes](#permission-scopes)). | Console | Dashboard route | What it answers | First-visit behaviour | Docs | | ----------------------------- | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------- | | **Contacts** | `/audience/contacts` | *Who is in my audience, and what does any one contact look like across channels?* The full search/import/manage surface; each contact detail page carries a **360** tab and a **Journey** tab. | Until an import runs, the list is empty and the console steers you to the import flow. | [Customer-360 workspace](/guides/customer-360-workspace) (PII) | | **Lists** | `/audience/lists` | *What static, hand-curated slices do I keep for one-off sends?* | Empty until you create a list or save one from a segment. | [Static contact lists](/guides/contact-lists-static-targeting) | | **Segments** | `/audience/segments` | *Which dynamic, rules-based audiences do I define over contact attributes and events?* | With no segments the console opens the rules builder before anything else. | [Segments + computed traits + activation](/guides/cdp-segments) (PII) | | **Identity resolution** (PII) | `/audience/identity-resolution` | *Which probabilistic merge candidates are waiting for human review, and should I merge or dismiss each?* Confidence-banded review queue with a side-by-side diff. | Shows the engine's `review` band; an empty queue means no candidates above the review threshold. | [Identity resolution guide](/guides/identity-resolution) (PII) | | **Merge** (PII) | `/audience/merge` | *Which deterministic exact/fuzzy duplicates do I collapse, and which record survives?* | Runs the find-duplicates wizard before any merge executes. | [Contact merge end-to-end](/guides/contact-merge); [merge policy](/concepts/contact-merge-policy) (PII) | | **Contact fields** | `/audience/fields` | *What schema do my segments and personalization tokens read from?* Browses every contact field, trait, and custom property. | Renders the built-in field set even before you define custom fields. | [Custom fields](/guides/custom-fields) | | **Computed traits** (PII) | `/audience/computed-traits` | *Which deterministic derived tags stamp onto matching contacts, with no LLM spend?* | Opens the rule editor; no trait rules exist until you author one. | [Computed traits guide](/guides/computed-traits) (PII) | | **Linked audiences** (PII) | `/audience/linked-audiences` | *How do I build audiences that traverse my warehouse entities — accounts, opportunities, products — without SQL?* | Asks you to declare the data graph (entities + relationships) before any audience can traverse it. | [Linked Audiences guide](/guides/linked-audiences) (PII) | | **Opt-outs** | `/audience/opt-outs` | *Who suppressed which channel, and what consent evidence do I hand a GDPR / CCPA / TCPA audit?* | Shows opt-outs only after a suppression event lands; the contact-level ledger is on each contact page. | [Opt-outs console](/guides/audience-opt-outs-console) | | **Consent inspector** (PII) | `/audience/consent` | *What consent does this one contact hold per channel, and would a destination dispatch pass right now?* Live per-contact verdicts before you send (GDPR / CCPA / LGPD / CPRA). | Runs per contact id — open a contact from Contacts first. | [Consent inspector guide](/guides/audience-consent-inspector) (PII) | | **Senders** | `/audience/senders` | *Which sender IDs, email domains, and default-from addresses do I send from?* Consolidates phone alphanumeric IDs, WhatsApp senders, email domains, RCS agents, and from-defaults. | Walks registration and verification before any identity can sign a send. | [Senders hub guide](/guides/audience-senders-hub); [onboarding map](/guides/sender-identity-onboarding-map) | | **Imports** | `/audience/imports` | *What did my bulk CSV loads import, skip, or roll back?* Job list with dry-run, progress polling, cancel, rollback. | Offers the assisted import wizard until the first job completes. | [Import & reconcile](/guides/import-contacts); [end-to-end tutorial](/guides/import-contacts-end-to-end) | | **Accounts** (PII) | `/audience/accounts` | *What B2B organizations sit in my audience as golden records, and which member contacts and parent/child hierarchies do they hold?* | Empty until group ingest defines account relations; Operators in B2C workspaces can skip this surface. | [Account relations guide](/guides/audience-accounts-relations) (PII) | | **Predictive models** (PII) | `/audience/predictive-models` | *Which trained models — churn propensity, conversion intent, lifetime value, engagement fatigue — score my contacts, and what do the training reports say?* | Lists catalog models; training runs over your first-party history before scores are readable. | [Predictive models guide](/guides/cdp-predictive-models) (PII) | | **Propensity segments** (PII) | `/audience/propensity-segments` | *Which contacts rank highest on predicted churn risk or lifetime value, and how do I save the top tier as a segment?* | Needs trained model scores before it can rank. | [Propensity segments guide](/guides/propensity-segments) (PII) | | **Churn risk** (PII) | `/audience/churn-risk` | *Which still-active contacts rank as at-risk by the trained churn model, and how do I save the top-N as a retention segment?* | Same gate as propensity segments — trained churn model first. | [Churn-risk scoring guide](/guides/churn-risk-scoring) (PII) | | **Decisioning** (PII) | `/audience/decisioning` | *Which next-best variant, channel, and send hour does the bandit pick for one profile, and how did each candidate score?* | A tester, not a standing table — feed candidate actions for a contact and read the breakdown. | [AI decisioning guide](/guides/ai-decisioning) (PII) | | **Recommendations** (PII) | `/audience/recommendations` | *Which products would this profile most likely buy next, ranked across the five affinity factors?* | Tester surface: enter purchase/browse signals for a contact, read the per-factor breakdown. | [Recommendations tester guide](/guides/audience-recommendations-tester) (PII) | | **Activation** (PII) | `/audience/activation` | *Which saved segments sync out to Meta Custom Audiences, Google Customer Match, TikTok, or LinkedIn, on what refresh cadence?* Identifiers hash server-side before they leave Orbit. | An empty destination list until you register the first activation; needs a saved segment first. | [Activation pipeline guide](/guides/audience-activation-pipeline) (PII) | One tile breaks the namespace: **Referrals** cross-links to `/marketing/referrals`, because referral programs create contacts — the referred end-users become rows in this workspace. See the [Marketing hub console map](/guides/marketing-hub-consoles) for that surface's map. The hub also keeps a **Go to Contacts** shortcut at the bottom of the grid — the tile operators open most. ## Permission scopes The hub grants three bands, and the tile hide is presentation-only — the destination page re-checks the seat server-side: * **PII surfaces** — the CDP family: Contacts (360/Journey views), Segments, Identity resolution, Merge, Computed traits, Linked audiences, Consent inspector, Accounts, Predictive models, Propensity segments, Churn risk, Decisioning, Recommendations, Activation. These render only to owner, admin, and developer seats, mirroring the read gate over the PII-bearing customer-event stream. A viewer or agent sees none of these tiles; the destination page 403s them regardless. * **Member-readable consoles** — Lists, Contact fields, Opt-outs, Senders, and Imports render for every member including viewers, because their read routes are member-readable. Writes on senders (registration, domain verification) stay owner/admin/developer-gated at the API. * **API scopes through the console** — API keys with `contacts:read` read contact rows, lists, and segments; `contacts:write` runs writes (imports, merges, list edits, sender registration). The CDP family additionally requires one of the three gated seats regardless of the key's scopes. Every console is tenant-owned: contacts, segments, consent ledgers, and sender identities live in your workspace only, nothing crosses tenant boundaries, and nothing renders until you put data in. ## Suggested rollout order Touch the consoles in this order when you stand the surfaces up for the first time. Each step builds on the one above it: 1. **Imports then Contacts** — land the first CSV or CRM export, then work the Contacts surface. Every downstream console reads this base. *Skip when:* you ingest contacts over the API or a source connector instead of CSV — start from the base however it lands. 2. **Contact fields** — define custom fields before the first import's mapping step if your schema needs them. *Skip when:* built-in fields cover your schema. 3. **Senders** — register sender IDs and verify email domains while the import runs. It is the slowest lead-time dependency (carrier/domain verification), so start it early. *Skip when:* no outbound traffic yet — nothing sends until a campaign exists. 4. **Opt-outs + Consent inspector** — inherit suppression and consent records before you send anything. Legacy unsubscribe lists belong here, not in the campaign flight path. *Skip when:* truly greenfield with no legacy suppression list — the consoles then start empty and fill as events land. 5. **Merge + Identity resolution** — collapse deterministic duplicates and review the probabilistic band before segments read inflated counts. *Skip when:* the import's merge strategy already resolved duplicates at ingest. 6. **Segments (and Lists)** — define dynamic slices once the base is clean. *Skip when:* a static list covers your only audience. 7. **Computed traits** — stamp deterministic derived tags segments can then predicate on, no LLM spend. *Skip when:* your segments read raw attributes only. 8. **Linked audiences** — add when you model warehouse entities (accounts, opportunities, products). Skip on B2C-simple workspaces. 9. **Accounts** — add B2B golden records when group ingest defines them. Skip on pure B2C. 10. **Predictive models → Propensity segments / Churn risk** — train the four built-in models, then rank and save the top tiers as segments. *Skip when:* no activation destination consumes scored audiences yet — the models still train, but nothing reads them. 11. **Decisioning + Recommendations** — per-profile testers once a campaign workflow calls them. Skip until a next-best-action or next-best-product flow exists. 12. **Activation** — sync saved segments to ad networks last. It consumes what steps 6–11 define. Steps 1–5 unblock a working contact base. Steps 6–12 turn the base into audiences and activation. ## Where the in-depth docs live * [Customer-360 workspace](/guides/customer-360-workspace) — per-contact profile, conversations, calls, journeys, and the snapshot endpoint behind the 360 tab. * [Import and reconcile contacts](/guides/import-contacts) — CSV jobs, merge strategies, rollback; the end-to-end first-import tutorial is [First contact import](/guides/import-contacts-end-to-end). * [Custom fields](/guides/custom-fields) — the schema surface the Contact fields tile browses. * [CDP segments, computed traits, and activation](/guides/cdp-segments) — the segments guide that also introduces derived traits and ad-network activation. * [Computed traits](/guides/computed-traits) — the deterministic rule DSL behind the Computed traits tile. * [Linked Audiences](/guides/linked-audiences) — data graphs and no-SQL relational audiences. * [Identity resolution](/guides/identity-resolution) — deterministic rules, probabilistic review, survivorship, consent-aware merges. * [Contact merge end-to-end](/guides/contact-merge) and [merge policy](/concepts/contact-merge-policy) — the deterministic merge workflow and the survivorship rules behind it. * [Identity resolution model](/concepts/cdp-identity-resolution) — how the engine bands candidates into auto-merge, review, and dismiss queues. * [Account relations](/guides/audience-accounts-relations) — B2B account graphs, member contacts, parent/child hierarchies, and the read endpoints behind the Accounts tile. * [CDP predictive models](/guides/cdp-predictive-models) — the four built-in models, training reports, CLV tiers, and re-activation schedules. * [Propensity segments](/guides/propensity-segments) and [Churn-risk scoring](/guides/churn-risk-scoring) — rank-by-score → save-as-segment on the trained scores. * [AI decisioning](/guides/ai-decisioning) and [Recommendations tester](/guides/audience-recommendations-tester) — the next-best-action and next-best-product testers. * [Opt-outs console](/guides/audience-opt-outs-console) — suppression provenance, STOP fences, and evidence export. * [Consent inspector](/guides/audience-consent-inspector) — per-contact consent ledgers and live destination verdicts. * [Senders hub](/guides/audience-senders-hub) and [sender-identity onboarding map](/guides/sender-identity-onboarding-map) — registration and verification for every outbound identity. * [Activation pipeline](/guides/audience-activation-pipeline) — register, run, and monitor segment pushes to ad networks and webhook sinks. * [Static contact lists](/guides/contact-lists-static-targeting) — the Lists tile's targeting model. * [Outbound audiences console](/guides/outbound-audiences-console) — how lists, segments, suppression, and frequency caps compose into a campaign audience outside this hub. ## See also * [Marketing hub console map](/guides/marketing-hub-consoles) — the same console-map treatment for Wallet Passes, Loyalty, and Referrals. * [Insights hub orientation](/insights/overview) — the map pattern applied to the analytics hub, with its RBAC visibility table. * [Consent and suppression model](/concepts/consent-and-suppression-model) — the ledger the Opt-outs and Consent inspector surfaces read from.