The new property sync property types have been tremendously helpful, but would be great if we can increase the limit from 25. Very convenient to avoid working through associations, then searching dependent objects....hopefully this limit gets increased!
👋Hi all! I'm Rachel from the HubSpot Product team. We'vecombined the sync property and calculated property limit, which will enable you tocreate more sync properties(specifically, up to 40 for Pro portals and 200 for Enterprise portals).
As part of this change, we're increasing the Pro limit from25 to 40calculated properties
The combined limit for Enterprise portals will remain 200 calculated properties
Enterprise customers can purchase additional calculated properties using the existing add-on pack
I've spoken to the support team and it seems there is a limit of 10 property syncs for pro users and a limit of 25 for enterprise users. They also mentioned that "right now there are no concrete plans to increase this unless the feedback is there to match this", so hopefully with more pushback, the limits can be increased.
Increasing this limit would be exceptionally helpful for our team. Currently, the only downside is that we can't apply the property sync approach to all linked properties, and therefore need to use a combination of systems for property management. Increasing this limit would improve administration time, training and engagement, and ultimately result in higher quality data.
Very helpful new feature, but the limit of 10 for Hub Pro licences is very low... we will still have to create workflows to automate the copy of properties.
The same thing can be accomplished without limit using workflows on enterprise ops, perhaps less efficiently for HubSpots AWS bill. It would be nice to have the simplicity of not having to use the workflow tool.
I also understand the need for a cap, but 10 and 25 for pro/enterprise is way too low. Let's add a 0 to those numbers!
This is very frustrating and potentially going to be prevenring me from migrating to Hubspot if I can't find a work around.
I need to be able to data from different objects onto one as we need the grid table to be downloaded as a CSV so we can mailmerge to do our mailouts. We're moving away from Airtable where there are no limits on 'Lookups'. 25 doesn't make sense, it can't use much computing power. Why set a limit of this function at all!!
Adding my voice to say i'd like to see it increased by an order of magnatitude. 25? Cool, but restrictive. 250? Now we're talking. -- It's kind of a bummer to have to check my 'balance' of availiable sync properties. It creates this werid dynamic where i'm always wondering if i'll regret using one of my valuable syncs on any given thing rather than building a workflow.
From my point of view this has to be unlimited. We need more than 10 properties to be synced - so i have some properties that are "synced properties" and for others i have to create workflows which will sync two properties. Please increase the limit significantly or make it unlimited. This change was so nice but the limit absolutely kills it.
"Display Associated Properties" cards are not a satisfactory alternative. Integrations or even view exports often require information to be stored within the same object.
Adding another strong agreeance for this idea. Relying on workflows to copy values between properties undermines the potential benefits of having a system that includes object associations. I'm trying to ensure data integrity in the CRM, and this frustrating limit will hinder my capacity to effectively ensure this.
Please upgrade the amount. If this results in too much processing power, you could keep the current limit but extend it with a variation of property sync properties that only sync once every hour or 24 hours. I feel that fo 80% of the usecases that's fine.
Agree that we need higher limits, for all the reasons stated by others. I would also pay a little more for a higher tier (within reason) if needed to cover compute costs.
Its time to increase the property sync limits. There are a couple of really good reasons with the primary reason being the consistency of data across object types. While we can manage with workflows, there are times that the data appears to be out of sync as we are waiting for a workflow to complete. I have to think that property sync is also a less resource intensive process than consistently running workflows.