The package builder lets you turn content and external (HubSpot) resources into reusable packages that you can install between different Supered accounts.

This article will serve to document everything about HubSpot resources. There are other articles on important topics:

The rest of this article will go over each HubSpot resource, and provide any information that is important / useful to know.

Don't see your favorite HubSpot resource in the current package builder? Make a feature request in your Supered Studio.

Supered will detect existing resources (usually by label or API name) and will either:

This means that you can install a package multiple times without worrying about duplicate resources.

HubSpot resources are untouched. Supered never deletes or uninstalls HubSpot resources.

When you "uninstall" a package in Supered, the Supered resources (cards, triggers, process rules, updates) are removed from the target account.

However—to repeat—HubSpot resources are untouched.

Uninstalling and reinstalling a package is a great way to ensure you have the most up-to-date resource definitions.

Yes, there is an "install" button on each individual item. This only appears in the HubSpot sidebar.

A guiding philosophy for Supered is "Never Break HubSpot." This means we do not delete resources, we do not remove existing options, we do not change the types of properties, etc. We only support reversible and non-destructive operations.

While Supered will not break HubSpot, it is possible to set up a scenario that must be manually cleaned up (by you). For example, if you instal a set of resources into the wrong account, you would need to delete and clean up those resources. (Because Supered never deletes from HubSpot.)

HubSpot packages do not read or write data, only HubSpot configuration. This means that Supered packages will not migrate contact records, static list memberships, etc.

Supered supports tagging resources with business units. This is supported for the following resources:

We do not support business unit filters right now (ie. a list with business unit = X)

Supered does not create business units—you must create them yourself. We look for a business unit with a given name.

Create all of the business units by hand before you install a package.

Supered detects the business unit for a given resource when it's added to a package. When setting up the package, you can click the business unit name and change it to a different value.

You can assign any business unit name to a resource. This means that you can configure business units even if the business unit is not present in the source account.

We support folder on most resources that have folders. If we're missing a resource that you'd like to see included here, just let us know:

Folders are automatic. You will not see them in the package builder, but the installed resource will be created with the folder hierarchy included.

This article here: Common Installation Errors & Troubleshooting will be kept up to date with the most common errors and fixes you will see during installation.

We try really hard to prevent it, but errors are going to pop up. This can be because of existing properties or resources in the target portal, mismatch existing resources, permission issues, temporary delays, etc. So what do you do when you see an error.

In general, we recommend you try to install that failed resource again. It's safe to try again and see if the error still occurs. Sometimes, it will go away when you retry the install. (This happens because of temporary processing delays in HubSpot, or temporary internet issues when the package is installing.)

If the error still appears, try to read the text to see if anything stands out. Even though it looks technical, there's usually a sentence or phrase in the error that gives away the root cause.

Report the error to your PSM or to Supered Support Chat and we'll document the error here + look into a fix for you!

Supered will search for non-deleted campaigns. This is the same end result as searching for Campaigns in HubSpot's list UI.

Campaign resources (emails, landing pages, etc.) are not dependencies. You must manually add them to your package.

When an email or landing page references a campaign, the campaign will be picked up as a dependency.

Campaigns are looked up by name (exact match). If a match is found, the campaign is marked "already existing" and the link to the campaign is returned. If no match is found, a new campaign is created.

Campaigns are unique by name, so it is not possible to create a duplicate with the same name.

Supered picks up the business unit when you add a resource to your package.

All of your non-deleted custom objects will appear in the search interface.

Custom objects are a bit different than our other ones. Due to their complexity, all of the things needed to make them work are automatically included in the custom object bundle. This includes:

You will not see the above things appear as dependencies for the custom object. There would be a lot of noise and complexity if we did that!

Custom objects can take a few seconds to install due to the amount of things brought along with them.

Existing custom objects are looked up by API name / label. If one is found, you will see a prompt asking if you want to continue the install with this object. If you select yes, the full installation will occur for the object that already exists.

During installation, all of the custom object resources will be installed. If any of them fail, the custom object will still be created, up until that point. It is safe to re-install the custom object if this happens, it will not write-over existing resources.

Object Associations: Associations will be skipped if they cannot be created. For example, custom object A that associates to custom object B will not be created unless both custom objects exist in the instance. This all "just works" without you needing to worry about it.

Supered will search for non-deleted dashboard. This is the same end result as searching in HubSpot's list UI.

The reports inside of the dashboard are automatically included with the dashboard. Custom properties and objects are included as dependencies.

Data sets are not currently supported.

When you install a dashboard, a new set of reports will be created for that installation. We will not use existing reports inside of an installed dashboard. This allows you to delete the dashboard without worrying about whether the reports are in use elsewhere.

Supered picks up the business unit when you add a resource to your package.

When you install the dashboard, all of its reports will be attached to the same business unit as the dashboard.

Supered will search for non-deleted deal pipelines. This is the same end result as viewing deal pipelines in HubSpot's pipeline management screen.

Dependent properties and requirements are included as dependencies.

The individual stages will preserve their ID when installed into the target account. This allows filters to work more seamlessly.

You cannot have duplicate pipelines. Supered will search for an existing pipeline. If one exists, we will search for missing stages and automatically create them in the existing pipeline.

Pipeline stage properties/requirements are installed alongside the stages. If a stage already exists but doesn't have the right properties, the missing properties will be attached to the existing stage.

If a pipeline exists with the same ID but a different name, Supered will error out. There is no way for us to progress the installation if this occurs.

This is most common when you rename the default deal pipeline between the source and target account.

We recommend that you use the default name, or the same name between accounts. If needed, you should rename the target deal pipeline so that it matches the source name. (You can rename it back after the package installation is complete.)

Supered will search for non-deleted deal tags. This is the same end result as viewing them in HubSpot's deal tag management screen.

Deal tags are added to packages when you choose to add them. Dependent properties are included as dependencies.

Deal tags are unique by name, so they will be skipped over if a matching deal tag already exists.

The deal tag will be created on "all pipelines".

Note: Supered support for design templates is currently in a limited support mode. We recommend the "Copy to different account" feature that HubSpot provides to transfer arbitrary design templates between accounts.

You cannot search for design templates manually.

Design templates are included in email templates or landing pages.

The only supported templates are "generated layouts." Supered does not support design manager templates otherwise.

You should use the built in "Copy to different account" feature to bring design manager templates between accounts.

The folder structure (path) for design templates is automatically included.

Supered is not able to create "generated_layouts" entries through the package manager. Instead, we will put these layouts into a folder called "cloned_layouts". You are able to manage these templates via the design manager.

Design templates are unique based on their design manager path. If an existing template exists at the installed path, it will be skipped.

Non-deleted emails are searched for. This is the same as searching for emails in HubSpot's list UI.

The following dependencies are supported for emails:

"Blog emails" cannot be added to packages. These emails are automatically created by creating a blog, so cannot be created by Supered.

Email templates are included as a dependency, but custom modules and complex templates are not included. You must migrate complex templates by following the "Design Templates" section.

Emails are complex objects, you should always check to validate that the email was installed correctly.

If there's an existing email with the same name, you will be prompted to skip the installation, or to install a new email with the same name.

All emails are installed in a draft state. Supered cannot migrate an email into a "sent" state. This means that if you export a sent email, it will be migrated as a draft email into the target account.

If an email is too large, it will fail to install.

The business unit of the email is included on the resource. The email subscription (a dependency of the email) must have the same business unit or the email will not be created.

When you install an email, a CAN SPAM setting with the same name as the business unit will be looked up. If one is found, it will be included in the email. If one isn't found, the default CAN SPAM setting will be used. (Supered does not create CAN SPAM settings, so you must manually create them in the target account.)

You cannot manually search for email subscriptions.

Email subscriptions are only added to packages as dependencies of emails.

If an email subscription with the same name and business unit already exists, it will be skipped and marked existing.

The business unit of the email subscription is included in the package. You can have duplicately named subscriptions in different business units.

Emails installed into a subscription must have the same business unit, or they will fail to install. The email installer will search for a subscription that matches the same business unit (or it fails to install.)

One of the most common issues is your package is built with the default email subscription, but the account you're installing into has renamed it.

In this case, Supered will alert you to the issue and you can choose to cancel the installation, or accept that a new email subscription will be created.

Non-deleted emails templates can be searched for. This is identical to searching in HubSpot's list UI.

Email templates are heavily used in sequences. In that case, all of the email templates will be included as dependencies.

Email templates personalization tokens and files will be included as dependencies.

If an email template exists with the same name and subject, it will be skipped and marked existing. Otherwise, a new email template will be created.

The folder structure for email templates is automatically included.

Files cannot be added to a package manually. They are included as dependencies of other resources.

File references are added to packages, but the file itself is not downloaded into Supered. This means that the file must remain accessible through installation.

When a file is installed, the source file must be available to your account. If you delete the file in the source account (or don't have access to it), then it will fail to install.

The folder structure for files is automatically included.

Non-deleted forms can be searched for. This is identical to searching in HubSpot's UI.

The following dependencies are supported for forms:

If a form already exists with the same name, the resource will be skipped and marked as existing.

The business unit for the form is included in the package.

Non-deleted landing pages can be searched for. This is identical to searching in HubSpot's UI.

The following dependencies are supported for a landing page:

Templates are included as a dependency, but custom modules and complex templates are not included. You must migrate complex templates by following the "Design Templates" section.

Landing pages are complex objects, you should always check to validate that the landing page was installed correctly.

The default account domain is used for the landing page. You must manually change the domain after creation.

Supered does not support business units for landing pages.

Business units (now) cannot be set directly on landing pages. Instead, you must set the landing page domain. The associated domain's business unit will be the landing page business unit.

The lifecycle stages for the contact object are available to search.

The stage and its properties are added to the package.

The lifecycle stage pipeline must exist with the same ID. By default this is the standard contact pipeline, which is available in every account.

If a stage already exists, it will be skipped and marked as existing. Even if the properties and requirements do not match.

The new lifecycle stage is created at the end of the existing lifecycle stage pipeline. Required properties are included with the installation.

Supered will detect and create static lists, but the list membership will not be migrated over. Static lists will be empty in the target account.

Active lists will include their full logic and will reflect the membership of matching records in the target account.

Non-deleted lists can be searched for. This is identical to searching in HubSpot's UI.

List logic is included and any dependencies are included. This can include custom properties, forms, emails, workflows, etc.

If a list with the same name exists, the list will be skipped and marked as existing. Otherwise, the new list will be created.

The folder structure for lists is automatically included.

Custom object associations are automatically included with the custom object package resource. You do not need to manually add these associations to your package.

The object associations for custom associations is available to search. System and automatic associations will not be visible.

The object association and any custom objects will be added to your package.

The association will be created if both sides of the association exist. If a custom object is missing from your package, you will see an error.

If the association already exists, it will be skipped and marked existing.

See "Deal Pipelines" for information specific to deal pipelines.

See "Lifecycle Stages" for information specific to contact lifecycle stages.

Pipelines cannot be manually added to packages. They are added as dependencies only.

Dependent properties and requirements are included as dependencies.

See "Deal Pipelines" for information regarding pipeline installation. The code is identical for deal pipelines and other pipelines—the only difference is the object that the pipeline is associated with.

All property groups for a given object will be searched.

A special group called Name (with custom properties) will include the property group and all of the custom properties it contains. This is useful to include a large number of custom properties in a single click.

Adding the property group will not include any of its properties unless you select the "(with custom properties)" option.

If the property group already exists it will be skipped and marked as existing. Otherwise, the property group will be created.

All non-deleted properties for a selected object are searchable in the package builder.

A selected property is added to your package. Any dependencies that the property relies on (calculation properties, other complex properties) are included as dependencies.

You can add "standard properties" to your package, but we generally don't recommend it (outside of selection properties.) This is because HubSpot doesn't allow creation or modification of many standard properties.

The following properties are not supported by Supered:

If the property exists but has a mismatched type, you will see an error. (Supered will not update an existing property's type.)

If a selection property (radio, checkbox, select box) exists but has missing options, Supered will show you the missing options and prompt you to add them to the property. (Supered will never remove existing options.)

If a property exists with the same API name but a different label, you will receive an error. (Supered cannot proceed in this case.)

If a property exists with the same label but a different API name, you will receive a prompt to continue with the installation process. This checks the property type and select options are valid, but does not create a new property.

The business unit for the property is included in the package.

Supered supports unified record customization views for all objects and all team views. The search function will show you all views, and you can search for the one you're looking for.

Each view's property and resource dependencies are included in your package. Custom objects are supported and will be included as dependencies.

Team-specific and default views can both be added to packages.

When a view is added to the package, it will say "Default View" or "Team View" in the sidebar. You can click this label and it will switch to the other. This allows you to install a team view as the default view or vice-versa. This is very convenient if you're creating a library of views for different use cases.

If there is an existing view with the same name (or default view), then the operation will be treated as an update. Otherwise, it will be a creation.

Creation: The new view is created using the packaged resource definition. All dependencies should be automatically included as part of the package builder.

Update: The existing view is "backed up" by creating a team view with the same name and the current time. The existing view is then updated with the cards of the packaged resource at the top of the view, and the existing cards at the bottom. Supered does not delete anything from the existing view.

Integrations: If your view has an integration, it must be installed before the view is. Otherwise, you will get an error that a card could not be found. This is a manual process today, which we hope to help streamline in the future by detecting the missing integration.

This has been replaced by Unified Record Customization Views. Existing packaged resources will no longer work.

If you are including reports from a dashboard, you do not need to include the reports in your package.

The dashboard automatically includes all reports and will create new reports each time (it does not use existing reports.)

Non-deleted reports can be searched. This is identical to searching in the HubSpot UI.

Custom properties and objects are included as dependencies.

Data sets are not currently supported.

If a report exists with the same name, you will be prompted to skip the report (use existing) or create a new report.

The business unit for the report is included in the package.

Non-deleted sequences can be searched. This is identical to searching in the HubSpot UI.

Each step of the sequence is included with its dependencies. This includes sales email templates, which are the most important aspect of the sequence.

See the section "Email Templates (Sales)" for more information on how email templates are handled.

If a sequence exists with the same name, you will be prompted to skip the sequence (use existing) or create a new sequence.

The sequence settings will be installed to the created resource. The sequence will be marked as publicly available. If you want it to be private to a user or team, you must update it after creation.

The folder structure for sequences is automatically included.

Non-deleted snippets can be searched. This is identical to searching in the HubSpot UI.

Snippets do not have any dependencies.

If a snippet exists for the same shortcut, it will be skipped and marked existing. Otherwise, the snippet will be created.

The folder structure for snippets is automatically included.

Non-deleted task queues can be searched. This is identical to searching in the HubSpot UI. Public and private task queues will be shown, as long as they are visible to you.

Task queues do not have any dependencies.

If a task queues exists for the same name, it will be skipped and marked existing. Otherwise, the task queue will be created.

Task queues are always created as public. You can change the task queue visibility after creation.

See "Pipelines" for information about ticket pipelines.

Ticket pipelines cannot be searched directly. They are only supported as dependencies.

Non-deleted views can be searched. This is identical to searching in the HubSpot UI. Public and private views will be shown, as long as they are visible to you.

Properties and objects referenced by the view filters will be included as dependencies.

If a view exists with the same name and object type, it will be skipped and marked existing.

The view is always created as public. You can change the visibility after creation.

Non-deleted workflows can be searched. This is identical to searching in the HubSpot UI.

Dependencies for supported aspects of workflows are included when you add a workflow to your package.

If a workflow exists with the same name, you will be prompted to skip the workflow or create a new workflow.

You must manually activate installed workflows. Supered installs workflows in a draft state, and will never install them already activated. You should check that your workflow is installed correctly.

The folder structure for workflows is automatically included.

The following elements are not supported:

Custom code actions are supported. Supered will bring the source code and configuration with the workflow.

Custom code secrets are detected by Supered, but cannot be accessed. So you must manually set the action secrets before creating the workflow. This is done by creating a temporary workflow, add a custom code action, "Manage secrets", set your secret values.

Secret values are account-wide, so you only need to do this once per named secret.

Supered picks up the business unit when you add a resource to your package.