URN Management
URN (Uniform Resource Name) Management allows you to manually control how metadata items are matched between portals. This is essential for handling renamed items, custom mappings, and complex migration scenarios where automatic matching fails.
What are URNs?
A URN is a unique identifier for a metadata item in HubSpot Deploy. URNs follow a structured format:
urn:namespace:identifier
Examples:
urn:schema:contacts # Contacts object schema
urn:property:contacts:email # Email property on Contacts
urn:pipeline:deals:default # Default deals pipeline
urn:workflow:12345678 # Workflow with ID 12345678
urn:form:contact-us # Contact Us form
URN Components
| Component | Description | Example |
|---|---|---|
| Prefix | Always urn: | urn: |
| Namespace | The type of metadata | schema, property, pipeline, workflow, form |
| Identifier | The unique ID or name | contacts, email, 12345678 |
Why URN Management?
Problem: Automatic Matching Fails
When comparing two portals, HubSpot Deploy automatically matches items by their URNs. However, this fails when:
- Items were renamed in one portal but not the other
- Different naming conventions were used (e.g.,
contact_statusvsstatus) - Items were recreated with different IDs
- Custom objects have portal-specific prefixes
Solution: Manual URN Overrides
URN overrides allow you to tell HubSpot Deploy:
"When you see URN A in this portal, treat it as if it were URN B"
This "stitches" items together that would otherwise be seen as different.
URN Namespaces
HubSpot Deploy uses a registry of valid URN namespaces. Common namespaces include:
| Namespace | Description | Example URN |
|---|---|---|
schema | Object schemas (standard and custom) | urn:schema:contacts |
property | Object properties | urn:property:contacts:firstname |
property_group | Property groups | urn:property_group:contacts:contactinformation |
pipeline | Pipelines and stages | urn:pipeline:deals:default |
workflow | Workflows | urn:workflow:12345678 |
form | Forms | urn:form:contact-us |
email_template | Email templates | urn:email_template:welcome-email |
landing_page | Landing pages | urn:landing_page:product-demo |
list | Lists | urn:list:active-customers |
association | Association definitions | urn:association:contacts:deals |
Namespaces are extensible. New metadata types can be added as the system evolves.
Creating URN Overrides
From Instance Observer
-
Navigate to Instance Observer
- Go to Connections → Select portal → Instance Observer
-
Open URN Links Tab
- Click the URN Links tab
-
Create New Link
- Click Create Link
- The URN Override Modal opens
-
Configure the Link
- Source (Natural): The actual URN in this portal
- Select Type (namespace)
- Enter Identifier (the unique ID or name)
- Target (Effective): The URN to treat it as
- Select Type (must match source type)
- Enter Identifier (the URN from the other portal)
- Source (Natural): The actual URN in this portal
-
Save the Link
- Review the final URN mapping
- Click Link Items
- The override is saved and applied immediately
From Comparison View
When viewing a comparison, you can create URN overrides directly from diff items:
-
Identify Mismatched Items
- Look for items marked as "new" or "removed" that should match
- Note the URNs of both items
-
Click "Add Manual Link"
- Click the link icon (🔗) next to the item
- The URN Override Modal opens with the item's URN pre-filled
-
Enter Target URN
- Enter the URN from the other portal
- Click Link Items
-
Verify the Link
- Refresh the comparison
- The items should now show as "identical" or "modified"
- A link icon appears next to the item
URN Override Examples
Example 1: Renamed Property
Scenario: A property was renamed from contact_status to status in Portal B.
Portal A URN: urn:property:contacts:contact_status
Portal B URN: urn:property:contacts:status
Solution: Create an override in Portal B:
Real URN: urn:property:contacts:status
Override URN: urn:property:contacts:contact_status
Result: When comparing Portal A and Portal B, the status property in Portal B will be treated as contact_status, allowing proper matching.
Example 2: Custom Object with Portal Prefix
Scenario: A custom object "Projects" has different IDs in each portal due to portal-specific prefixes.
Portal A URN: urn:schema:p12345_projects
Portal B URN: urn:schema:p67890_projects
Solution: Create an override in Portal B:
Real URN: urn:schema:p67890_projects
Override URN: urn:schema:p12345_projects
Result: The custom object in Portal B will be matched with the one in Portal A.
Example 3: Workflow Recreated with New ID
Scenario: A workflow was deleted and recreated in Portal B, resulting in a new ID.
Portal A URN: urn:workflow:11111111
Portal B URN: urn:workflow:22222222
Solution: Create an override in Portal B:
Real URN: urn:workflow:22222222
Override URN: urn:workflow:11111111
Result: The workflow in Portal B will be treated as the same workflow from Portal A.
Example 4: Pipeline Stage Renamed
Scenario: A deal pipeline stage was renamed from "Qualified Lead" to "SQL" in Portal B.
Portal A URN: urn:pipeline:deals:default:qualified_lead
Portal B URN: urn:pipeline:deals:default:sql
Solution: Create an override in Portal B:
Real URN: urn:pipeline:deals:default:sql
Override URN: urn:pipeline:deals:default:qualified_lead
Result: The "SQL" stage in Portal B will be matched with "Qualified Lead" in Portal A.
How URN Resolution Works
1. URN Override Context
The UrnOverrideContext provides global access to URN overrides throughout the application:
interface UrnOverrideContextType {
overrides: UrnOverride[]
loading: boolean
getEffectiveUrn: (connectionId, realUrn) => string
getRealUrn: (connectionId, effectiveUrn) => string
addOverride: (connectionId, realUrn, overrideUrn) => Promise<void>
removeOverride: (id) => Promise<void>
refreshOverrides: () => Promise<void>
}
2. URN Resolution Process
When comparing or deploying metadata:
-
Fetch Overrides
- Load all URN overrides for the active workspace
- Cache in memory for performance
-
Apply Overrides
- For each metadata item, check if an override exists
- If yes, use the override URN instead of the real URN
- If no, use the real URN
-
Match Items
- Compare items using effective URNs
- Items with matching effective URNs are considered the same
-
Display Indicators
- Show link icon (🔗) next to items with overrides
- Tooltip shows both real and effective URNs
3. URN Resolver Hook
The useUrnResolver hook resolves URNs to full metadata items:
const { resolved, loading, error } = useUrnResolver(comparisonId, urns)
Features:
- Fetches metadata items by URN
- Caches results to avoid repeated queries
- Returns a map of URN → ResolvedItem
Use Cases:
- Displaying item details in dependency views
- Showing referenced items in tooltips
- Validating URN overrides
Managing URN Overrides
Viewing Active Overrides
- Go to Instance Observer → URN Links tab
- See all active overrides for this portal
- Each row shows:
- Natural URN (Real) — The actual URN in this portal
- Treat as (Effective) — The URN used for matching
- Actions — Remove the override
Editing Overrides
URN overrides cannot be edited directly. To change an override:
-
Delete the existing override
- Click the trash icon (🗑️) next to the override
- Confirm deletion
-
Create a new override
- Click Create Link
- Enter the new URN mapping
- Click Link Items
Deleting Overrides
- Go to Instance Observer → URN Links tab
- Find the override you want to remove
- Click the trash icon (🗑️)
- The override is deleted immediately
- Future comparisons will use the real URN
Deleting an override affects all future comparisons. Existing comparisons are not retroactively updated.
URN Override Best Practices
1. Document Your Overrides
When creating an override, document why it was created:
- Keep a spreadsheet or wiki page with all overrides
- Include the reason (e.g., "Property renamed during migration")
- Note the date and who created it
2. Use Overrides Sparingly
Overrides are powerful but can make comparisons harder to understand. Only use them when:
- Automatic matching fails
- The items are genuinely the same
- Renaming the item in HubSpot is not feasible
3. Validate Overrides After Creation
After creating an override:
- Create a new comparison
- Verify the items now match correctly
- Check that no unintended side effects occurred
4. Clean Up Unused Overrides
Periodically review your overrides and remove any that are no longer needed:
- Items that have been renamed back
- Portals that are no longer in use
- Temporary overrides for one-time migrations
5. Use Consistent Naming Conventions
To minimize the need for overrides:
- Establish naming conventions for properties, workflows, etc.
- Use the same names across all portals
- Avoid renaming items unless absolutely necessary
6. Test in Sandbox First
Before creating overrides in production:
- Test the override in a sandbox portal
- Verify it works as expected
- Document the process
- Apply to production
Troubleshooting
Override Not Working
Symptoms: Created an override, but items still don't match in comparisons.
Possible Causes:
- Namespace mismatch — Source and target namespaces must be identical
- Typo in URN — URNs are case-sensitive and must be exact
- Wrong portal — Override was created in the wrong portal
- Comparison not refreshed — Old comparison cached the previous state
Solutions:
- Verify the namespace matches (e.g., both are
property) - Double-check the URN spelling and capitalization
- Ensure the override is in the correct portal (usually the target portal)
- Create a new comparison to see the override in effect
Items Still Show as "New" After Override
Cause: The override URN doesn't match any item in the source portal.
Solution:
- Check the source portal to verify the item exists
- Verify the override URN matches the source item's URN exactly
- Use the Metadata Viewer to find the correct URN
Override Causes Unintended Matches
Cause: The override URN matches multiple items or the wrong item.
Solution:
- Delete the override immediately
- Review the URN structure to ensure it's specific enough
- Create a more specific override (e.g., include parent object name)
Cannot Delete Override
Cause: System permissions or connection issue.
Solution:
- Refresh the page and try again
- Check your workspace permissions (must be admin or member)
- If issue persists, contact support
Advanced Use Cases
Use Case 1: Portal Migration with Bulk Overrides
Scenario: Migrating 50+ properties from Portal A to Portal B, where many were renamed.
Approach:
- Export all properties from both portals
- Create a mapping spreadsheet (Portal A URN → Portal B URN)
- Create overrides one by one through the UI
- For large migrations, contact support for bulk import assistance
- Create a comparison to verify all overrides work
Tip: Start with a small batch (5-10 overrides) to test the approach before doing all 50+.
Use Case 2: Multi-Portal Sync with Shared Baseline
Scenario: Syncing 3 portals (Dev, Staging, Prod) with a shared Git baseline, where each portal has slightly different naming.
Approach:
- Designate one portal as the "source of truth" (e.g., Prod)
- Create overrides in Dev and Staging to match Prod's URNs
- All comparisons will now use Prod's naming convention
- Deployments will work seamlessly across all portals
Use Case 3: Temporary Override for One-Time Migration
Scenario: Migrating a single workflow that was recreated with a new ID.
Approach:
- Create the override before the migration
- Run the comparison and deployment
- After successful deployment, delete the override
- Future comparisons will use the new URN
Security & Permissions
Who Can Manage URN Overrides?
Both workspace admins and members can:
- View URN overrides
- Create URN overrides
- Delete URN overrides
URN overrides are workspace-scoped, meaning they apply to all users in the workspace.
Related Features
- Instance Observer - Centralized portal dashboard
- Comparisons - How URN overrides affect comparisons
- Deployments - How URN overrides affect deployments
- Metadata Types - Understanding metadata structure