Import Properties

This is probably the more convoluted import type to understand. But don't worry, below explanations should help clear the air on when a Properties import is necessary and how to set it up.

This import is used to ingest properties of objects (can be additional properties of default CRM objects or new custom objects that you currently do not have access to in HockeyStack).

Most common examples include subscription data that cannot be tracked through the CRM or product line items that are updated through the data warehouse directly. This data type also supports importing additional properties for objects we already track - like importing additional properties for accounts in your CRM.

Choosing an Object Type

HockeyStack's standard objects map from CRM objects (primarily Salesforce and HubSpot). If your object type maps to a standard object type from your CRM, you can select it and import as such. Examples are not limited to:

HockeyStack Object
Salesforce Object
HubSpot Object

Company

Account

Company

User

Contact

Contact

Deal

Opportunity

Deal

Default object types are useful when you have additional datapoints about your companies and contacts etc. that your CRM does not have access to. HockeyStack can be used to unify all these datapoints.

Custom Objects:

You can also import custom objects into HockeyStack, which you would configure under "Other" type in the Data Syncs configuration page. A custom object can represent any type of structured information that can be associated with a company or user, such as Outreach Call logs, subscription details of your trial users, or other custom datasets.

The only extra information we need to be able to configure a Custom Object Properties import is an object key - which is a unique underscore key to define what the object is to be called and a _id suffix (i.e. subscription_id, outreach_call_id etc.)

Example Schema

All column names should be in underscores.

Each row in the table signifies one record of the given object type. The term “record” describes a particular occurrence of an object (i.e. a single Company in your CRM).

Column Name
Example Value
Requirement
Description

identity

acme.com

required

Identifier column. This can be an email address or company domain that the imported object is tied to.

unique_id

492143

required

A unique id for the record/row. This guide on data grain helps determine how to come up with the value for this column.

last_modified_at

2025-06-18T12:04:10.000Z

recommended

This column signifies the last time this record was modified. If provided, it is used to resync only the data that did change rather than sync everything from scratch.

user_id

399

recommended

Similar to the identity column, if there is a person (like a contact from the CRM) or a company (like an account from the CRM) that the object is tied to, this column signifies the id of that record.

call_length

45

This will be saved as a property of the record.

call_start_date

2025-03-20T23:30:21.000Z

This will be saved as a property of the record.

Example Scenario #1

Let's say you are importing subscription data for your customers. The object type is Product Subscriptions. The object key can be product_subscriptions_id (the exact key doesn't matter as long as it does not change over time and is unique).

Each row in the data warehouse will be one subscription record where unique_id is the id of the subscription. Since each subscription is connected to a person, identity would be the email address of the user and user_id would be the id of the person if it exists in your product.

Any additional properties of the subscription (that are signified by the extra columns in the row) would be recorded as such in HockeyStack as well.

Other Considerations:

Connecting your Custom Object to a Company or Person:

The need for an identity or user_id column might seem confusing - especially for custom object types.

However in order for HockeyStack to show these datapoints properly, they need to be tied to the buyer journeys in some way. Buyer journeys are a sequential list of actions done by a person or a company as a whole which means the imported object type also needs to be tied to a person or a company.

Determining the Properties of the Record

Any column name that doesn't map to a specified column in the given schema example will be ingested as a property of the given record.

What if "Last Modified At" is not Available?

If you don't have a column to signify the last time that record was modified, we are able to a re-sync operation for all the available data in the data source as long as this is communicated beforehand.

The absence of the last_modified_at column is not recommended though because it means our system needs to move around a lot of unnecessary data that might reflect in your data warehouse bill as well.

Last updated