Push Databricks churn risk scores into Salesforce every morning

Every weekday at 7am, run my account health query on my Databricks SQL warehouse and put the results in front of my customer success team inside Salesforce, instead of leaving them in a dashboard nobody opens.

Submit the query with Execute SQL Statement, passing the id of my SQL warehouse. Databricks runs statements asynchronously, so poll Get SQL Statement until status.state is SUCCEEDED before reading any rows, and pull the remaining chunks if the result set comes back paged. Each row should give me the account identifier, the current churn risk score, the change versus last week, and the usage signals driving it, such as declining logins, dropped seat count, falling feature adoption, or rising support volume.

For each row, find the matching Salesforce account with SOQL Query, matching on whichever identifier my lakehouse stores, such as the Salesforce account id, an external id field, or the company domain. Before you write anything, read the churn score currently sitting on that Salesforce record, because I need the old value to decide whether this is news. Then write the latest score onto the record with Update Account.

Treat an account as newly at risk when this week's score crosses my at-risk threshold and the score already stored on the Salesforce record was still in the healthy range. That comparison is my deduplication rule: if the record was already showing an at-risk score, the account was flagged in an earlier run and my reps should not hear about it again. Keep the score updated on every account regardless of which side of the line it falls on, and gate only the alerting. A score that is high but flat, or that is moving in the healthy direction, is not an alert.

For every newly at-risk account, add a short plain-English explanation with Add Note to Account. Write it the way I would explain it to a rep who has 30 seconds: name the one or two usage signals that actually moved the score and say what changed, rather than dumping raw numbers. Then open a follow-up for that account's owner with Create Task, assigning it to the account's owner id, with a due date in the next few days and a subject that makes the reason obvious in a task list.

Finish by posting a single Slack Bot message to my customer success channel with Send a Message. List only the newly at-risk accounts, grouped by the owner who now has a task, with the top reason for each one. Resolve owner names with Get Many Users so the digest reads with real names rather than record ids. One message per run, not one message per account.

If nothing crossed the threshold, post nothing at all, and do not add notes or create tasks. A silent run is the correct outcome on a quiet day. Make the at-risk threshold and the weekday 7am schedule easy for me to change later, and assume the churn score already exists as a modeled table or view in my lakehouse, since this workflow distributes that score rather than computing it.