yeah, what you’re saying makes sense. I don’t have much (if any) know-how in SF, but the company i work for has a whole SF branch, so i can get them to look into it and contribute a better solution i think
Yeah, SF is a PITA when it comes to deploying Apex code (which is the approach we took back in the day to make these webhooks work). In order to deploy Apex code to production, you need to deploy it with accompanying tests, otherwise test coverage could fall below a certain threshold and SF will block those deploys. Our approach was to test the Apex code so that it reached 100% coverage, so that this code does not lower the total coverage.
But writing tests for code that’s dynamically generated is tricky, especially when SF is so customizable. For example, a SF customer might create custom field types, and we’d have no way of knowing the attributes of those custom types in order to write tests for them.
This test in particular is assuming that all fields in the object support the + operator, which might not always be true.
That’s also why the package does not support certain events for custom fields and objects, and that’s because we can’t write tests that would cover those.
yeah, i understand. I wonder if there’s a more modern approach to doing this nowadays in SF
This 2-year-old article (which is younger than our package anyways 
) seems to indicate that Apex is the “new” way (which is kinda lame):
There’re also some 3rd party SF apps in AppExchange that can be used for this, but that’d require you to create the webhooks yourself in SF and then integrate it with some HTTP source in Pipedream (not ideal, but might unblock you in the meantime)
i also did some consulting with AI, no idea how accurate it is tho, but the code it gives looks very simple
Create the Apex Class for Sending Webhooks
We’ll create a helper class that can send JSON payloads.
public class WebhookSender {
@future(callout=true)
public static void sendToWebhook(List accounts) {
try {
Http http = new Http();
HttpRequest req = new HttpRequest();
req.setEndpoint('https://your-webhook-endpoint.com/webhook');
req.setMethod('POST');
req.setHeader('Content-Type', 'application/json');
// Serialize records into JSON
String body = JSON.serialize(accounts);
req.setBody(body);
HttpResponse res = http.send(req);
System.debug('Webhook response: ' + res.getBody());
} catch (Exception e) {
System.debug('Error sending webhook: ' + e.getMessage());
}
}
}
Notes:
• We’re using @future(callout=true) because triggers can’t make callouts directly.
Create the Trigger
Now, let’s create a trigger on the object you want to monitor (example: Account).
trigger AccountTrigger on Account (after insert, after update, after delete) {
if (Trigger.isAfter) {
if (Trigger.isInsert || Trigger.isUpdate) {
WebhookSender.sendToWebhook(Trigger.new);
} else if (Trigger.isDelete) {
WebhookSender.sendToWebhook(Trigger.old);
}
}
}
it would obviously need to be turned into a template to handle different object types, this is just account, but idk, looks like there’s a native “trigger” concept
Yeah, that’s pretty much what we do, with some caveats:
- We support watching for updates in any object field, or in specific ones
- You also need to add a “remote site” in your SF account so that your Apex code is allowed to make HTTP requests to it
- The accompanying tests, that would allow you to deploy the Apex code to a production instance
I’m assuming you inspected these templates already, yeah?
salesforce-webhooks/resources/templates/apex/src at master · jverce/salesforce-webhooks · GitHub
I see, yes I had a quick look, but didn’t dive too deep yet.
So what’s the problem with the current code? The changes in that PR only touch the test, I didn’t even notice that at first. Is SF not allowing the deploy cuz the coverage dipped below some level?
What happens is that those tests need to be compiled as well, and something like item.field = "[default@example.com](mailto:default@example.com)" could make the compilation fail if item.field is not a string. I guess one alternative is to do this:
if (item.{{this}} != null) {
item.{{this}} += item.{{this}};
}
Another alternative could be do call the setFieldValue method from the SObjectFactory class, like this (I forgot the exact syntax though):
item.{{this}} = SObjectFactory.setFieldValue(item, "{{this}}");
This method checks the type of the field, and assigns it a proper default value based on it (and in some cases, a random value).
I haven’t touched this project in a while. We used to run integration tests against a SF sandbox, but IDK if that one is still up. I’ll check that today and bring it up to date, so that we can run those tests with the fix. I’ll keep you posted
amazing, thank you so much!
if anything is needed from me at any point - happy to help