Allow Multiple Conditions for Calculated Properties of Type Count / Sum
It is great that we can count or sum over objects using calculated properties. However, we often have cases where we want to put not just one but multiple conditions. So if we could have filter functionality similar to the normal list filters or workflow filters where we can combine multiple conditions with AND / OR that would make calculated fields much more powerful for us.
This is all great feedback. These are the two primary points I'm gathering:
Today only properties, not reports can trigger workflow automations. Automation compatibility and general flexibility is really important.
Pricing and packaging might be a barrier with datasets being Ops Hub Enterprise
Two questions:
Is there ever a need to compare these calculated property values in a summarized report visual? Or are these properties realistically just operational and not being used for analytics?
Can yall chime in with even more specifics/examples around how you're using these properties in workflows/how these properties are being used broadly?
Absolutely needed for any SAAS or subscription-based services. I cannot calculate MRR or ARR with it. Our company has a tiered pricing structure based on the number of users. There is a minimum amount per month, then a per-user price for ten different tiers.
This is a great add for HubSpot, making it much more robust for a subscription model.
Not sur why this would even need to be validated as an idea- we use TONS of calcualted properties, especially with the introduction of custom objects. It's been incredibly painful to get around the barrier of just one condition on a calculated field. It looks like this has been getting talked about since 2020? Why not just make the adjustment and delay the other menial updates? Is there any visibility as to when this could go live?
Has any progress been made on addtional conditions? See this was raised over 2 years ago so would be good to see how close we are to seeing this new feature
I actually would love to be able to apply different types of conditions to a calculated field (such as greater than or equal to). For example, I have a calculated property for the Finance team to view how revenue would be reconciliated across the months of a project (simple Deal Amount / Duration of Project), but I only want that calculation to kick in when the sales confidence is over a certain threshold. I can't do that at the moment, which is quite frustrating, especially when I have people with Salesforce experience talking about how well it works there. Are there any updates on this at all?
+ for this idea. The use cases can be very simple: I need to calculated the total revenue for a company this year and last year. I understand it is possible with Data Sets, but it's also possible with a workaround. You need to bild a separate property (Revenue 2022?) that is only filled when your (multiple) conditions aare met (e.g. Close Date is between 1.1.2022 and 30.12.2022 AND Stage = Won). Then you can apply the condition "Revenue 2022? = Yes" and sum it for a company.
But that's unnecessary complicated especially when there are already working solutions on Enterprise level. It just feels like making such thing more complicated for Customer that are not on Enterprise level yet.
It seems that often a request gets over-analyzed. @smcmillian replied offering a more complex solution using DataSets and asked for feedback. From what I can tell, a couple of users gave good examples for why DataSets wouldn't be a solution. The original request, and one that I also need, is simply to increase the number of conditions. I bet just adding one or two more conditions would resolve most people's need. In my case we have a "SITES" or locations module that looks just like a Company, but the SITES are associated to a Company, as we track revenue and implementation by SITE/Location. AND we need to be able to count the number of Sites where (condition 1) SITE STATUS = ACTIVE, AND (condition 2) SITE PRODUCT = X. So we just need one more condition for the calculated value. Maybe there is a complex reason that HubSpot cannot programmatically accomplish this, but for those of us that are semi-technical or technical, it is frustrating when what seems like a simple solution is over-looked or over engineered, especially one that is being requested by third party soution providers that help sell and customize HubSpot for end users! And as @JessKing86 says: "It's been incredibly painful to get around the barrier of just one condition on a calculated field. It looks like this has been getting talked about since 2020? Why not just make the adjustment and delay the other menial updates?"
This one simple change can help so much. Is HubSpot afraid this will keep customers from upgrading? We are Enterprise level and we need this.
I'm happy to report that this Idea is now In Development! Our team is actively implementing a solution for this feature and we are super close to an alpha.
We are currently looking for a select few willing to give feedback to be part of the alpha.
If you are interested in being a participant, please fill out this form. Once we're alpha-ready, we'll contact you with the next steps.
The classic build a workflow and copy results into another property is clunky and not something I want to have to explain to reps. Worst part is hitting that refresh button 2 times just to see a result in the property.
We have certain cases where there are two types of records: Parent & Children.
- We want to calculate the same property differently based on what type of record they are.
- Not having if/then logic in the calculation field blocks us from doing so easily.
- Result: we have to build a workflow and use that conditional logic wich slows down and clutters up the user experience.
This sounds promising. Here's the use case I was trying to achieve with a calculated field using a different value based on comparing date values of two other fields.....
"I'm currently looking to modify/enhance a calculated property field 'Time between Date field A and Date field B'
Currently it takes the time between two date properties: Date A AND Date B
I want to enhance this by making it dynamic so that the 'from' date is one of two different date properties depending on which one contains the later date.
For example
If 'Date A' property is a later date than 'Date B' property, calculate time between: 'Date A' property value AND 'Date C' property value
Else if 'Date B' property is a later date than 'Date A' property, calculate time between: 'Date B' value AND 'Date C' value
I would then product a report showing the updated 'Date C' value for various deals, which would be calculated dynamically as per the above logic.
Does anyone know another method of achieving this (e.g. using workflows and deal stages)?
Agree this is needed desperately. We need to calculate a multiple checkbox property. So the only operator in the calculation is currently "==" which means if multiple options are selected it returns a 0 value. Workflows are also not an efficient way to deal with this calculation either because the property is very dynamic.
We need more operators when we're calculating a count on an associated object's property. Basically we need an operator that can handle "contains".
I need a custom variable to integrate into a rewards program, it needs apply a value to an "AMOUNT" range for Deals.
Something like this - A new Field "Referral Reward" with the following used to enter the Value:
if (([properties.amount] < 5000, 50) or ([properties.amount] >= 5000 and < 10000, 100) or ([properties.amount] >= 10000 and < 15000, 150) or ([properties.amount] >= 15000 and < 30000, 300) or ([properties.amount] > 30000, 400))
I find it mind-blowing to think that any developer would limit Boolean functionality to a single expression, that's not how logic equations work!
When will this functionality be available? I'm on a deadline to get this working!
I would be happy with the option to have a CASE function, instead of IF. Or a IF / THEN /ELSE logic.
This would solve sooooo many use-cases, which currently today are solved (sometimes) by using a field to store an interim number which is set through a workflow to feed into the next step of the maths/logic.
I can't imagine how much cloud processing power is wasted by Hubspot to handle all these working numbers, when a simple control function within a calculated field could do it.
