We have a multi-model Lead Score implementation. One Product Interest Lead Score field for each of nine different Product types.
I am trying to figure out how to automatically sum all of the Product Interest Lead Scores for each record in one Aggregate Lead Score field.
The intention would be that any time one of the Product Interest Lead Scores is changed (incremented higher), that would trigger an update of the Aggregate Lead Score field.
The reason?
We want to rank our daily Leads based on the Total Engagement each lead has with our nine Products.
Is this even possible?
Solved! Go to Solution.
That'll work, yep (+ pls mark my answer as Correct when you get a chance).
The 'hook is only necessary when you need thresholds, multiplication, or other fancy conditions.
Note that Denise's mention of the "other side" doing the calculation could well apply to a custom DB, too: any SQL database can use triggers or calc'd fields.
There are 2 ways to do this:
1. May almost be too obvious for you to have thought of: in your scoring SCs, always bump up the aggregate as well as the individual.
2. Call a webhook, which will keep the aggregate in line with the individuals each time it's called.
I would add a 3rd option to Sandy's fine suggestions - assuming you use Salesforce.com:
3. Create a formula field in SFDC to sum the different scores.
The downside of this method is that the scoring aggregation only occurs if and when the person gets synced to SFDC.
BTW - I hope I'm not violating forum rules by mentioning that Sandy provided an excellent webhook for a client of mine a year or so back that performed a similar function.
Thanks for the great suggestions!
We do have a CRM, but it's not SalesForce. So our data is powered by a Custom DB where the Lead Score fields live.
Sounds like the (obvious 🙂 ) suggestions by Sanford to increment the Aggregate at the same time we increment the Product Lead Score is the easiest way to go.
Thanks again!
That'll work, yep (+ pls mark my answer as Correct when you get a chance).
The 'hook is only necessary when you need thresholds, multiplication, or other fancy conditions.
Note that Denise's mention of the "other side" doing the calculation could well apply to a custom DB, too: any SQL database can use triggers or calc'd fields.