HubSpot Ideas

marstalb

Trigger a workflow when a property value has been changed

[This has been resolved] It would be wonderful to have the ability to trigger a workflow when a property value has changed. For example, we have leads submit answers on a form, and after a sales rep speaks to the lead, sometimes the rep find out the information our lead selected was incorrect. Once the sales rep overrides the form submission's answer, marketing needs to be notified so we can place the lead in the appropriate follow up workflow to send relevant topics to our leads. 

32 Replies
elmo
Contributor

@marymartin28, it was already explained in the second reply of this thread that there's already the "has changed" trigger, it's just unclearly named "is known". It sounds like it'd trigger only when the value becomes non-empty for the first time, so I'd really suggest for HubSpot to name it better, e.g. "Is known or changed".

 

Currently, re-enrolling based on that is not possible for company properties, only contact properties, as was said, but luckily they're already looking into adding it as well.

mitchellkp
Top Contributor

@katja Property is known is not intuitive to also mean property value has changed. Is that the only way "is known" is used? Why not change the name or add that as a distinct option?

hkampen
Contributor

Hi,

when "is known" triggers also changes, than not in HubSpot Score trigger. I try to reset the score.

  • I created the field "Test HAKA" and added a value
  • I created the score -100 trigger by "Test HAKA" "is known".
  • Than I changed the value of "Test HAKA" 

Nothing happend, the score didn't changed.

If "is known" also triggers changes, than not in scores. Than it's an inconsistent behaviour, otherwise the title "is known" must be change to "is known or changed" to be correct, as @elmo  allready wrote.

I believe "is known" also triggering changes was a bug, not a feature.

 

For me, this ticket is not resolved.

Jocksterpositio
Member | Diamond Partner

I can confirm that "is known" trigger is not the same as "has changed". When I change a company property, contact property doesn't get updated. We need "has changed property", not complicated solutions with lists!

Matt_Shonkwiler
Participant

@marymartin28 and @Jocksterpositio are right to say that "is known" is not a viable replacement for "has changed".
As @elmo points out "it'd trigger only when the value becomes non-empty for the first time" and it can't be used for Account Based (Company Based) re-enrollment.  Any chance you can re-visit this @hubspot?

Jocksterpositio
Member | Diamond Partner

@Matt_Shonkwiler Hey! Try reading this thread. Maybe it will help you!

Matt_Shonkwiler
Participant

@Jocksterpositio Thanks for the link.  Unfortunately, if the field is on the Company, then it is not available as a re-enrollment trigger (which makes ABM/Company Based Marketing extra challenging).

The "flag" workaround might be viable.  I was trying to avoid creating more workarounds than necessary (this is already a workaround to workaround an issue from another workaround).  Ideally, I'd like for the functionality to be simple and straight forward, to avoid a web of unnecessary fields and confusing workarounds which make it increasingly difficult to manage Hubspot over time.  But, in the meantime the "flag" workaround or simply using Salesforce automation to handle the heavy lifting might be our best options.  Thanks again.

MeganLegge
HubSpot Product Team

Hi everyone,

 

My name is Megan and I'm a product manager for the workflows tool. Thank you for your feedback and votes on this idea! There are a few different needs outlined in this thread, and I'd like to clarify a few things to ensure all are addressed.  

 

Currently Possible: Enroll an object in a workflow, every time a certain property’s value changes. This is applicable when the object, workflow type and property type are the same. For example, enrolling a contact into a contact workflow, every time a contact property value changes.

 

To do: Use ”Is known" as an enrollment and re-enrollment criteria. When using the property filter is known for re-enrollment, objects can re-enroll in two ways:  

  • The property gains a value after not previously having one.
  • The property is updated from one value to another. For example, a contact's lifecycle stage changing from Lead to Subscriber would qualify for Lifecycle stage is known. Each time this contact's lifecycle stage is updated, they would re-enroll in the workflow.  

 

Currently Not Possible: Enroll an object in a workflow, every time a property value changes on one of the object’s associated records. For example, enrolling a contact into a contact workflow every time the contact’s associated company has a certain property value update. This isn't possible because filters referencing associated objects cannot currently be used for re-enrollment.  

 

Workaround: For the above example, use a company workflow instead. Enroll the company in a workflow, every time the company’s property value changes. Use the company workflow to copy the company property value to all associated contacts. 

 

Potential Limitation: the value is copied out to all associated contacts, not just certain association contacts. If this limitation is what’s causing a challenge, I’d like to point you towards two other ideas forum posts that more directly discuss this:  

 

A CRM requested feature, which proposes a property mapping system for different objects, to keep certain property values in sync or updating in certain directions. Customers often use workflows to create their own property mapping systems, but a CRM feature of this nature would make this possible without a workflow. This is a feature the CRM team is actively asking for feedback on via this survey. If that feature would better suit your needs, I recommend taking the survey and adding your support there as well!  

 

A Workflows requested feature, with a specific goal of copying values to only certain associated records, but not ALL associated records. This has been recently updated with new information so take a look and see if this idea is better aligned with your need.  

 

Since the original request of this thread is currently possible, I'm going to close this one out as delivered to prevent additional confusion. For requests that are slightly different, please add your support to a more specific ideas thread that already has support/discussion, or create a new one that goes into more detail about your different need/idea.  

 

Best,

Megan

Matt_Shonkwiler
Participant

@MeganLegge  Thanks for the detailed response.

Since the original ask seems to be focusing on only one object, the Contact (Lead), I think you're right to say that it is "currently possible".

You captured my particular use case under the "Currently Not Possible" section.  And the workaround is not viable because of the "Potential Limitation".

The "CRM requested feature" link doesn't help because I already use Salesforce as our CRM, and Salesforce can already handle this easily as-is.  (I was originally trying to avoid building workarounds to Hubspot limitations in Salesforce, because I didn't want to confuse Salesforce users, but it's ultimately the simplest/easiest/fastest/most-reliable solution).

The "Workflows requested feature" link is a workaround to the "Potential Limitation" of the "Workaround".  I'd rather not make copies of field values from one object to another (because of the confusion it causes to users, and the risk of them getting out of sync). I'd prefer to simply reference the related object's field, as you described in "Currently Not Possible."

Thanks again.

GBersac8
Participant

**bleep**, that workflow trigger definition method used by hubspot is straight out confusing! You could do `when property xxx of object type yyy is updated` or `is created` like everybody else, but no, you created that strange thing with trigger and re-enrollment rules that is so weird.

KTotten
Participant

 +1

DLoszewski
Participant

What if you don't want to trigger if it never had a value to begin with?  I only want to trigger if the value has changed.  If the property gains a value after not previously having one it should not be triggering.