How to trigger a flow based on certain custom fields changing?

[ColinJi1]

Hi! I have 7 particular custom fields on a Project form, and I need to trigger a fusion flow whenever any of them is changed. I made a calculated field that concatenates the values of those 7 fields, as many answers on this forum suggest--the trouble is, calculated fields aren't selectable in the Watch Field module nor readable in the old state/new state of the Watch Events module, so I have no way of validating whether those fields changed at the start of the module. The operations that follow are somewhat lengthy, so I don't want to trigger them every single time a Project is updated. The alternative is making a separate flow for each field, but that will be a nightmare to maintain. Any tips?

[Sven-iX · Accepted solution]

Hi @ColinJi1 

Simple approach:

1. Change your scenario to start with a webhook
2. Create 4 listening scenarios, one for each custom field. as Filter, use DE:field name = changed
3. Then add a HTTP module that calls the scenario in #1, passing the newState and oldState objects

I recently learned (thanks JustinG and @ChrisStephens) that you can create a custom event subscription: 
The watch event module gives only a simplified version - most annoying that it doesn't allow OR filters.

Check out here Event Subscription API

You can use Fusion to a) remove existing subscriptions that point the your event module, then b) add the needed subscription and filters. In your case something along the below might work.

[ColinJi1]

@Sven-iX This sounds fantastic! The latter solution might be a bit over my head (not even sure where to start with setting up an event subscription), but the "simple approach" sounds like it'd get the job done. I've never used an HTTP module before, can you give me a nudge in the right direction? This was my best guess but it definitely doesn't like it (with the full webhook URL entered, of course).

Thank you!

[ColinJi1]

Figured out something that works! I couldn't figure out how to send the whole old and new states along, but for the sake of any others who might come across this thread in the future: it was enough for me to send this along in the HTTP and query the project in the webhook scenario based on which listening scenario triggered it (passed along using fieldThatChanged).

[Sven-iX]

Hi @ColinJi1 

You were close: When you send the new/oldState content you have to first convert it to JSON (string) - in your example you're passing an object in the body. If you add a TransformToJSON module and send its output  it'll arrive at the webhook. 

Event subscriptions are not hard - it's just that there's no easy UI to manage those  
When you add/set up an "Instant" event listener module, Fusion does this behind the scenes.

So, think of it this way: 

• Create the hook URL
• add subscriptions
  • these tell WF what events to send to the hook URL

The power behind manually doing the subscriptions is that you can configure filters you otherwise can't. Plus, you can add multiple subscriptions (eg call the same webhook when a TASK changes and when an ISSUE changes) - all things you can't do with the out of box modules.

If you're willing, read up on the API - you basically use 2 modules: a WF customAPI call to /session to get the Fusion user's WF session, and an HTTP module to call the subscription API (where you pass the sessionID as authentication)

Hope that makes sense.