Add Integrations

public class SlackNotificationQueueable implements Queueable, Database.AllowsCallouts {
    private List<Id> projectIds;

    public SlackNotificationQueueable(List<Id> projectIds) {
        this.projectIds = projectIds;
    }

    public void execute(QueueableContext qc) {
        for (Project__c p : [SELECT Id, Name FROM Project__c WHERE Id IN :projectIds]) {
            HttpRequest req = new HttpRequest();
            req.setEndpoint('callout:Slack_Webhook');
            req.setMethod('POST');
            req.setBody(JSON.serialize(new Map<String, Object>{
                'text' => 'Project "' + p.Name + '" is now At Risk.'
            }));
            new Http().send(req);
        }
    }
}

ProjectHealthService (or the batch job from Lesson 6) enqueues this job when it detects a health change to At Risk — Module 36\'s exact rule still applies: this callout cannot happen synchronously inside a trigger-originated transaction, so it runs as a Queueable, just like Module 42\'s ledger integration.

Module 44 introduced external objects for cases where an external system is the authoritative source of truth and must be queried live. Slack is not a data source this application needs to query — it is purely a one-way notification target. An external object would be the wrong tool entirely; this is a textbook case for a simple outbound callout instead, exactly the kind of deliberate tool-matching Module 44\'s closing lesson asked for.

If the Slack webhook is briefly unreachable, the Project__c.Health__c update itself has already committed by the time this Queueable runs — Module 39\'s and Module 42\'s "the primary operation is never lost because a downstream notification failed" principle, applied here one final time.