Upcoming Sunset of Legacy Stage Calculated Properties for Contacts and Deals

[dennisedson]

We have introduced a new set of pipeline stage calculated properties for the contacts and deals objects that offer more functionality than their predecessors.  With the introduction of these new properties, we will be sunsetting the corresponding legacy properties.  These properties will cease to be available or function on November 20, 2024.  

What’s changing

We have added new stage calculated properties for contacts and deals which are available today. These properties include the following.

• hs_v2_date_entered_{stage_id}
• hs_v2_date_exited_{stage_id}
• hs_v2_latest_time_in_{stage_id}
• Hs_v2_cumulative_time_in_{stage_id}

Note: the {stage_id} value in the property names above may exactly match the stage ID on the pipeline stage, or it may be altered slightly to conform to property naming rules.  For example, a hyphen in the ID of a pipeline stage may be substituted with an underscore in the corresponding property name.

With the availability of these new properties, we will be sunsetting the following legacy versions which include the following.

• hs_lifecyclestage_{stage id}
• hs_date_entered_{stage id}
• hs_date_exited_{stage id}
• hs_time_in_{stage id}

The legacy properties do behave differently than the new, improved properties and may result in different values. Some key differences:

• legacy properties clear data when an object moves backwards.
• legacy properties auto-populate data when an object skips stages.

When switching over from the legacy properties to the new properties, there may well be some differences in values based on the above. It's important to remember that the data of the new properties provide higher data accuracy than the legacy ones.

What do you need to do

There is no need to merge the new data with the old. Integrations only need to switch over to the new v2 properties. The new properties were backfilled and should offer historical values.

Now that there is a replacement set of properties for the legacy properties, integrators will need to migrate to the new v2 properties by November 20th, 2024.

 

When is this happening

The new properties are available now.  The legacy properties will stop being returned for any API request beginning on November 20th, 2024.  

[MakeDevelopment]

Hi, sorry, I'm lost. We have our own integration and I'm trying to find out where we could have these properties. Can you please tell me which API endpoints will have these new properties? And is it in payload or only in response?
We are using

POST /contacts/v1/contact/createOrUpdate/email/ {email}

GET /companies/v2/companies/{{companyId}}/contacts",

GET /crm-pipelines/v1/pipelines/deals",

POST and GET "/crm/v3/objects/contacts",
POST and GET "/crm/v3/objects/deals",

Is any of these endpoints affected by this new change? Is there any relation to them?
Thank you

[OriginalRobert]

Hi @MakeDevelopment - this change will impact the response content (but not the response shape) of any APIs that provide access to Contacts or Deals.  This is a change to the available data but not a change to the APIs themselves.

Across any of your calls to our APIs for example, if you explicitly request a property like 'hs_lifecycle_stage_customer_date' from your own code (via the properties or propertiesWithHistory request elements), then the value for that specific property will start to come back empty after November 20th.  

Nothing about any integrations will break with our change unless those integrations are specifically relying on the legacy property information to be returned (and you should be able to do a code search on your side to see if this is the case - search for the prefixes 'hs_date_entered_', 'hs_lifecyclestage_' etc.).  If you do see these properties being referenced in your own code, you should update the property names according to the table in the comment below this.

Out of the APIs you list above:

POST and GET "/crm/v3/objects/contacts"
POST and GET "/crm/v3/objects/deals"

... will be impacted, but again this should not matter to you unless you have a known code dependency on the legacy properties.  If not, then the change will be transparent.

[ClicData]

Hi, we currently have an integration that we will need to migrate.

The new properties:

hs_v2_date_entered_{stage_id}
hs_v2_date_exited_{stage_id}
hs_v2_latest_time_in_{stage_id}
Hs_v2_cumulative_time_in_{stage_id}

the deprecated properties:
hs_lifecyclestage_{stage id}
hs_date_entered_{stage id}
hs_date_exited_{stage id}
hs_time_in_{stage id}

From the informations you give in the article, I can safely say that I'll do my replacement like this:

hs_date_entered_ fields will go => hs_v2_date_entered_

hs_date_exited_ fields will go => hs_v2_date_exited_

But for hs_time_in_ I have the choice of hs_v2_latest_time_in_ OR Hs_v2_cumulative_time_in_; What should be used then ?

Also, no information on how to migrate the hs_lifecyclestage_ related fields.

It is stated in the article that "there is a replacement set of properties for the legacy properties". I fetched the contact properties list from the API, and could not determine which one were safely replacing hs_time_in_{stage id} and hs_lifecyclestage_{stage id}.

Thanks for any help and guidance that you could provide for this.

[OriginalRobert]

Here is a table listing the default appropriate translations from the old properties to the V2 properties.

Legacy Property	V2 Property
hs_lifecyclestage_{stage}_date	hs_v2_date_entered_{stage}
hs_date_entered_{stage}	hs_v2_date_entered_{stage}
hs_date_exited_{stage}	hs_v2_date_exited_{stage}
hs_time_in_{stage}	hs_v2_latest_time_in_{stage}

The difference betwee the hs_v2_latest_time_in_{stage} and hs_v2_cumulative_time_in_{stage} is that the former will only count the most recent time spent in a given stage, whereas the latter will count all the time in a stage if a contact were to enter that stage, exit it, and enter it again.

For example, if a contact sat in the 'Subscriber' stage for 2 days, then got moved to the 'Lead' stage for 1 day, and then got moved back to the 'Subscriber' stage for 1 day: the hs_v2_latest_time_in_subscriber value would be '1 day' whereas the hs_v2_cumulative_time_in_subscriber would be '3 days'. 

The 'cumulative' counting is a new option compared to the legacy system, so we recommend customers default to 'latest' when migrating if they're not sure which is appropriate for them.

[NHeidl]

I would have thought you would spend sometime at least making HS far more flexible.  For example, I cannot remove or move Email when I create a new contact.  This is infuriating.  I can't adjust the column headers to text wrap so I can see more of the data across the screen.  Another is the search only allows for name, email, phone and company.  I would like to see option for one colum of choice or be able to select how the search works.  Another is the inability to select two owners via inputting contact owner.  

[NHeidl]

I have no clue what this all means.  No examples, no detailed explanation at all.  How about you provide some semblance of a simple explanation for the layman?

[MShandor]

Please go back in the thread, I posted 2 weeks ago a more "layman" explaination that might be helpful.

[fionabOS]

Hello,

If we are using the legacy contact properties in some workfows, lists, and/or reports, do we need to switch the legacy properties to the new ones before November 20th so that our workflows keep working normally after the old properties are sunseted? Or will the switch be done automatically ?

If not, is there an easy way to do this?

[dennisedson]

@fionabOS ,

We will handle the migration for the items you mentioned (lists, workflows, reports).

Necessary changes are only applicable to 3rd party integrations and their usage.

[Xiawanbai]

Hi, thank you both for the information. Can anything go wrong? If you are using it, did you find anything that was uncorrect compare to the previous data you had in the fields?

[websrey]

Greetings,

Nothing seems to go wrong here, the data will be same as it was, jut it will migrated to new property, from "Became a [lifecycle stage] date" to "Date entered[lifecycle stage]".

I have opted in, and everythings working fine, as it was earlier.

If you are still not sure you can otp out from this migration by clicking here in this popup shown below, that you'll get by clicking on "Learn more".

[Xiawanbai]

Hi, can anyone please explain a bit more clear what do we need to do and how it might / will affect users of Hubspot? 

[websrey]

Greetings,

Nothing to worry about it.

HubSpot have added new calculated properties for lifecycle stages, and the already existing proeprty which is called leagacy contact properties, will see the sunset.

The data will not be lost.

If you don't want the migration then you have the option to opt out, that you can do by clicking here in this popup shown below, that you'll get by clicking on "Learn more".

But if you want to opt in then you just have to click "Accept" button, and you'll see that new calculated properties in your HubSpot and all the data will be migrated to these new ones.

[MShandor]

One thing to note is your level of membership with Hubspot.  If you look under Data Management-Custom Events and you see an orange arrow (image below).  You don't currently have Marketing Hub Enterprise; therefore the change will likely not have as big or an impact on your account.

What makes the update look more confusing is that it is written it in code versus using the names of the fields that will change. 

The fields that will be changed are the following:

Lifecycle Stage

Date Entered

Date Exited

Time In

(We chose to create custom fields because Lifecycle stage did not meet the needs of our company so the change will not impact us)

If you do use those fields above, you have 2 options:

1.  Reject/decline the change

2.  Accept the change and use the new fields (see list below)

Date Entered

Date Exited

Latest Time in

Cummulative Time in

As with any CRM it comes down to how you use it at your company.  If you have Marketing Hub Enterprise you have 24/7 customer service by email or phone so I would recommend that if you have concerns you have someone walk you through everything and ask all the questions you have about the developer changes.  If you do not have customer service included with your membership, I would analyze how your team uses the fields above and make a determination that works best for you.

Hope this helps.

[dennisedson]

@Xiawanbai , if you have an integration that is using the legacy versions of the properties listed above, you will need to replace those properties with the newer version.  Those properties are available now and should have values associated with them so it should be a pretty straight forward process.