Scoring
Compute a score per record from weighted inputs, and publish it where you need it.
A priority order nobody can explain. Every rep has a theory about which accounts matter. None of them agree, none of them are written down, and the one number in the CRM that claims to answer it was set by a vendor three years ago on somebody else's data.
A scoring model is a weighted composite over banded inputs, which is a formal way of saying: the things you think matter, how much each one matters, and what the total is called.
Inputs can read the record or its children. An attribute input reads a field on the record. A rollup input reads a number derived from the records attached to it: how many opportunities it has won, the value of them, when the last one closed.
Computing and publishing are separate decisions. A score is stored where LiveCRM can read it the moment it is computed. Whether it also reaches a field in your CRM is a second choice, made per run, because computing is free and writing is not.
How a pass runs
The detail
Explainability
Every score here decomposes back to the fields that produced it.
The reason most CRM scores are ignored is that nobody can answer the obvious question: why is this one an eighty. If the answer is a model somebody else fitted, the number is an opinion with a decimal point.
Here the inputs are yours, the weights are yours, and the band each input landed in is recorded alongside the composite. A score can be read back to the fields that made it, which is what makes it something a rep will act on and a manager will defend.
For agents
Reads are free and need no permission to write. Anything that changes a record is a separate grant.
list_rule_templates the models on this connection readget_rule_template one model, with its inputs and weights readcreate_score_run score a scope, and optionally publish writedispatch_run start it writeWhere to start
The readiness scan runs detection against your own CRM and reports what it finds, before anything is merged.