Replacing v1 `new_install` with v2 triggers

Summary:

Future-proof your workflow by upgrading your triggers from the v1 new_install event to v2 deal.projectSubmitted or deal.projectReceived *

Who should consider making this change?

Enerflo partners currently using the v1 new_install event to process information about the install.
Enerflo partners building new integrations that process Installation data.

Why?

The new_install v1 event will eventually be deprecated.

The v2 events (deal.projectReceivedordeal.projectSubmitted) offer more precision in triggering events from related orgs.

What action should I take?

Step 1: subscribe to the deal.projectReceived or deal.projectSubmitted webhook in Enerflo

Step 2: once you have received the event payload, parse the the v2 deal id from the payload. Note, it is always found in the payload.deal.id node for for both events

Step 3: use the {payload.deal.id} value to make a single API call to Enerflo v1 and pull back the standard v1 install package. (ex: https://enerflo.io/api/v3/installs/find/{payload.deal.id}). See the API reference document here

Step 4: process data as per usual

Step 5: deprecate any workflows build off of the new_install event

* More info regarding the triggering context of deal.projectSubmitted and deal.projectReceived

The data in the event payload is the same — Figure 1.1: which event should I subscribe to?

If I am a Sales Org, I can create a single deal.projectSubmitted event subscription to alert me of any deal submission, even if I work with 100 unique installers.
If I am an Installer, I can create a single deal.projectReceived event subscription to alert me of any installation project submitted to me from any sales org I work with.