# Build order: what each layer needs and why it comes where it does Each layer below names what it consumes, what consumes it, and the evidence that lets the next layer start. Platform facts were checked against HubSpot's live docs on 2026-10-17; re-check any path or limit before quoting it to a user. ## The order in one view ```text 0 First release and capability register 1 Account settings, users, seats, teams, domains, auth model 2 Records, identity keys, properties and field ownership 3 Lifecycle stage, lead status or leads object, deal stage definitions 4 Pipelines and stage evidence 5 Import rehearsal, then full import 6 Forms and tracking code 7 Integrations (Salesforce, billing, product data), one direction at a time 8 Workflows (routing, follow-up, notifications) 9 Reporting and reconciliation 10 Controlled launch, observation period, handover ``` Layers 5 and 6 can overlap when forms only collect and no workflow acts on them yet. Layer 8 never starts before 5 and 7 pass, because imports and integrations meet the same triggers as fresh requests. ## 0. First release and capability register - Consumes: the order form, seat assignments, the two or three workflows the business wants first. - Consumed by: every later layer. A design that needs an unentitled feature is rework. - Why first: entitlements differ between Hub-based subscriptions and flexible seats-and-credits subscriptions, and legacy pilot terms can differ again. Custom objects, owner rotation, the leads object, association labels, calculated properties, property view and edit restrictions, multi-currency, standard sandboxes, data sync custom mappings, Stripe subscription sync, deal attribution reports and duplicate tools all have tier or seat conditions. The list with check dates is in [data-model-and-properties.md](data-model-and-properties.md#entitlements-to-confirm). - Gate evidence: each dependency row reads confirmed (where and when) or fallback (what the simpler process is and what it cannot do). ## 1. Account settings and users What to settle and why it must precede data: - Time zone (Settings > Account Defaults > General). The account time zone localises scheduled marketing email, scheduled social posts and analytics dates. Record timelines, logged activity timestamps and property history display in each user's computer time zone, which explains "wrong" timestamps users report. Set it before building date-bucketed reports. - Company currency (Settings > Account Defaults > Currency). Changing it later does not convert existing deal amounts automatically. In multi-currency accounts a closed deal keeps the exchange rate in effect at close, and only Super Admins or users with the multi-currency write scope can edit it. Multi-currency needs Starter or above. Decide currencies before importing any deal amount. - Users, teams and seats. Owners must exist as users before an import maps an owner column, or rows lose ownership. The "Rotate record to owner" workflow action needs Sales Hub or Service Hub Professional or Enterprise, and skips users without a paid Sales or Service seat, deactivated users and users who have not accepted the invite. - Seat rule, using the seat types in HubSpot's product catalog on 2026-10-17: View-Only for people who only read; Core for people who edit records; Sales or Service seats only for users who need the specialist tools or must sit in a rotation. Read the current seat types in the portal and the order form; flexible seats-and-credits accounts use different seat names. - Permission sets per role (rep, manager, marketing, RevOps, finance). Test one record each role may see or edit and one it must not. Do this before import, because record visibility depends on owner and team. - Work inboxes and calendars: connect them for users who log email and meetings, and decide what gets logged (all threads, only tracked email, no internal mail). Logged activity is personal data, so agree the rule with the privacy owner. - Automatic company association ("Create and associate companies with contacts", Settings > Data Management > Objects > Companies > Automation). Decide before any import, form or integration. Off when companies are keyed on a source account ID or Salesforce is connected; otherwise exclude shared domains (up to 1,000). Record it in `decisions.md`. - Subscription types and consent fields, defined with the privacy owner before any form or marketing import. - Email sending domain authentication (DKIM, SPF, DMARC records in DNS) before the first marketing send. Verify the current steps on the email authentication page. - Super Admins. Keep the list short and named. Several high-impact actions (sandbox creation, leads object activation, connector approval, property restrictions, Restore CRM changes) need Super Admin. - External domains. Every externally hosted domain or subdomain that will carry the tracking code must be added in HubSpot settings. - Integration auth model. Legacy private app creation was disabled for accounts created on or after 28 September 2026 and is disabled for older accounts on 26 October 2026. Existing legacy private apps keep working. New system-to-system integrations use service keys, available through developer platform projects version 2026.09 or later; webhook use cases need an app. Record which integrations hold which credential type (never the credential itself). - REST API versions. Since 30 March 2026 HubSpot's REST APIs use date-based versions (`/2026-03/`, `/2026-09/`), released each March and September and unsupported 18 months after release. Legacy v1 to v4 paths remain available. Record the version each custom integration targets so it can be scheduled for upgrade. - Sandbox. Standard sandboxes need an Enterprise hub and Super Admin. Integrations are not connected automatically in the sandbox, record IDs differ from production, all sandbox workflows share a 100,000 enrolments per day cap, and a deployment to production cannot be cancelled once started. Without Enterprise, rehearse in production with a tagged batch and automation off. Gate evidence: account defaults recorded with date, a seat map (user, seat type, team, permission set), one allowed and one denied record tested per role, the automatic company association decision, the domain list, sending domain status, and the integration credential inventory. ## 2. Records, identity and properties - Consumes: the workflows (which facts are needed), the source systems (which IDs exist). - Consumed by: imports (column mapping uses internal names), forms (fields are properties), integration mappings, workflow triggers, reports. - Why before import: a property's internal name and object cannot be edited after creation, and an import cannot match on a unique key that does not exist yet. - Detail: [data-model-and-properties.md](data-model-and-properties.md). Gate evidence: a property register with one writer per property, the unique key per synced object, and the object map approved. ## 3. Lifecycle, lead status and deal stage definitions - Consumes: the property design, the sales process, billing states. - Consumed by: import (lifecycle values in files only move forward), forms (default stages), Salesforce sync, workflows, every funnel report. - Why before import: once an import sets a later stage, the same tool cannot move it back without a clear step. - Detail: [lifecycle-and-pipelines.md](lifecycle-and-pipelines.md). ## 4. Pipelines and stage evidence - Consumes: deal stage definitions. - Consumed by: deal imports (stage IDs), Salesforce opportunity sync, forecasts, reports. - Why before import: imports and integrations reference stage internal IDs. ## 5. Import - Consumes: settings, properties, keys, stage definitions, marketing-status decision. - Consumed by: integrations (they should find existing records, not create new ones), forms (submissions match contacts by email), workflows. - Why before integrations: an integration that starts against an empty or partly loaded portal creates records that the import later duplicates. - Exception: when Salesforce stays connected, records that exist in Salesforce enter through the integration's own import or resync after install, not by CSV. CSV covers only records with no Salesforce counterpart. See [integrations.md](integrations.md#salesforce). - Detail: [import-and-dedupe.md](import-and-dedupe.md). ## 6. Forms and tracking code - Consumes: properties (hidden fields), marketing status rules, consent decisions. - Consumed by: routing workflows, attribution reports. - Detail: [forms-and-tracking.md](forms-and-tracking.md). ## 7. Integrations - Consumes: imported baseline with source IDs, ownership register. - Consumed by: workflows and reports that read synced fields. - Why one direction at a time: a two-way default on day one hides which system wrote a bad value. - Detail: [integrations.md](integrations.md). ## 8. Workflows - Consumes: every input above, tested. - Why last before reporting: workflows act on customers. A routing workflow cannot compensate for duplicate accounts or unclear ownership. - Detail: [workflows-and-reporting.md](workflows-and-reporting.md). ## 9. Reporting - Consumes: definitions, stage timestamps, reconciled records. - Gate evidence: each dashboard number reconciles to a list of record IDs. ## 10. Launch and handover - Launch with a 30-day observation period, extended while defects stay open, and a named owner who checks failed syncs, unassigned requests, unexpected enrolments, deals missing required stage properties, marketing contact counts and report discrepancies daily. Detail: [workflows-and-reporting.md](workflows-and-reporting.md#observation-period). - Track each new writer's 14-day Restore CRM changes window, and name the Super Admin who can run a restore. - Change control: any workflow or property added during observation goes through the register and the controlled-record tests. - Hand over: how to pause new workflow enrolment, where the review queues are, who owns the registers, the defect queue, and the before-state exports. ## Estimating Estimate per gate, not per calendar week: decisions needed, configuration, data cleanup, integration build, testing and training. Name the dependencies outside the implementation team (billing access, agreement on qualification criteria, Salesforce admin time). A generic "two weeks" estimate hides the difference between a clean single-pipeline release and a migration with conflicting account identities.