Skip to main content
This runbook walks a Salesforce administrator through installing the allGood Webhooks package in your org. When you finish, your org will send Lead and Contact changes to allGood automatically. It takes about 15 minutes.

​
Prerequisites

You should have received from allGood:
  • The package files
    • allgood_sfdc_package__v<version>.zip — use this for a first-time install.
    • allgood_sfdc_package__v<version>__upgrade.zip — use this if your org has had a previous version of allGood webhooks; it also removes obsolete components from the old version.
  • One or more Webhook URLs
    They look like https://webhook.allgoodhq.app/abc123.
  • Optionally, an API key for each webhook
Not sure which package file to use? If allGood webhooks have ever been installed in this org, use the __upgrade file. Otherwise use the plain file.
You will also need:
  • A Salesforce login with the System Administrator profile
  • Permission to deploy metadata and edit Custom Metadata
The package only adds new components (a configuration type, a few Apex classes, and triggers on Lead and Contact). It does not modify existing fields, layouts, or data.

​
Install the package

You can install with Workbench (no extra software) or the Salesforce CLI. Workbench is the simplest for most admins.
1

Log in to Workbench

Go to https://workbench.developerforce.com.Under Environment, choose Production (or Sandbox if installing into a sandbox), accept the terms, and log in with your admin credentials.
2

Open the Deploy page

In the Workbench menu, go to migration → Deploy.
3

Choose the package file

Click Choose File and select the package file from “Prerequisites” — plain for a first-time install, __upgrade if a previous version was installed.
4

Set the deployment options

Check these options:
  • Rollback On Error — so a failure leaves your org untouched.
  • Test Level: RunSpecifiedTests — Salesforce requires tests to run when deploying to Production.
  • Run Tests — paste the package’s three test classes:
  • Ignore Warnings — only when deploying the __upgrade file. Leave it unchecked for the plain first-time-install file.
RunLocalTests runs every test in your org — yours, allGood’s, and every other vendor’s. Any failing test anywhere blocks the install, even when it has nothing to do with allGood. In an established org there is usually at least one, so this is the most common reason an otherwise-fine install fails.RunSpecifiedTests runs only the three allGood test classes. Salesforce still enforces coverage: every class and trigger in the package must be at least 75% covered by the tests you name. The allGood package ships at 100% coverage, so it passes comfortably.This does not weaken your org. It skips running unrelated tests during this one deployment; it does not change, disable, or delete anything of yours.
The __upgrade file removes obsolete components left by older versions, and that cleanup list intentionally names components that may not be present in your org. Salesforce treats a “not found” deletion as a warning; without Ignore Warnings, that warning fails the whole deploy. Enabling it lets those skips pass while still deleting whatever obsolete components are present.Real problems still fail the deploy, and Rollback On Error keeps it all-or-nothing. The plain first-time-install file performs no deletions, so it does not need this option.
5

Deploy and wait for success

Click Next, then Deploy.Wait for the status to show Succeeded. The package’s automated tests run during the deployment and must pass — this is expected and takes a minute or two.
To rehearse without changing anything, check Check Only and deploy. Salesforce validates the package and runs the tests but commits nothing. A successful validation can also be quick-deployed later without re-running the tests.
If your team uses the Salesforce CLI, unzip the package and deploy the metadata folder. Add --ignore-warnings only for the __upgrade package:
Each test class needs its own --tests flag. Add --dry-run to validate without committing.

​
Configure your webhooks

Each webhook is one configuration record. Create one per object you want to send (Lead, Contact, or both); you can also create several for the same object if allGood gave you more than one URL.
1

Open Custom Metadata Types

In Salesforce, go to Setup, then search for and open Custom Metadata Types.
2

Manage the configuration records

Next to allGood Webhook Configuration, click Manage Records.
3

Create a configuration record

Click New and fill in the fields:
4

Save and repeat

Click Save. Repeat for each object / URL.

​
About “Update Trigger Fields”

This controls which edits send a webhook. Only changes to the fields you list here trigger an update event — this avoids sending a webhook on every unrelated edit.
  • Recommended for Lead: Status, Email, Phone, Company
  • Recommended for Contact: Email, Phone, LastName, Status
If you leave Update Trigger Fields blank, edits never send a webhook. New records (inserts) always send a webhook regardless of this field.

​
Verify it works

1

Check the configuration is active

Make sure the configuration record you created has Is Active checked.
2

Create a test record

Create a new test Lead (or Contact). This should send an “insert” webhook.
3

Edit a trigger field

Edit one of the Update Trigger Fields on that record (e.g. change the Lead’s Status). This should send an “update” webhook.
4

Confirm the events arrived

Confirm with allGood that the events arrived, or check inside Salesforce:
  • Setup → Apex Jobs — you should see a recently completed WebhookService future job.
  • Setup → Debug Logs — enable logging for your user, repeat the test, and look for the outbound request and its HTTP response status.

​
Reference

  • What is sent
    The record’s standard fields (plus any Include Fields you list) as a JSON POST, with a Metadata section describing the event (object, insert vs. update, and the previous values on an update). The API key, if set, is sent as a bearer token.
  • Reliability
    Each event is delivered asynchronously and retried up to 3 times.
  • Security
    All traffic is HTTPS to allGood-owned domains, which are pre-approved by the package (Remote Site Settings). The API key is sent in the standard Authorization header.

​
Turning it off

  • Pause one webhook: uncheck Is Active on its configuration record.
  • Pause everything: uncheck Is Active on all configuration records.
  • Full uninstall: remove the Apex triggers (LeadTrigger, ContactTrigger), then the Apex classes and the configuration type, via Setup or a destructive deployment.
For anything else, contact allGood support.

​
Troubleshooting

Confirm a configuration record exists for that object and Is Active is checked.
The edited field isn’t in Update Trigger Fields. Add it (or set the recommended list).
Update Trigger Fields is blank — add the fields that should trigger updates.
The API Key is missing or wrong — re-enter the key allGood provided.
The Webhook URL must be the exact allGood URL (it must begin with https://webhook.allgoodhq.app). Re-paste the URL allGood gave you.
You deployed the __upgrade file without Ignore Warnings — re-deploy with it checked.
If the failing test class is not one of WebhookTriggerHandlerTests, WebhookServiceTests, or WebhookConfigProviderTests, it is a pre-existing failure in your org and unrelated to this package.Set Test Level to RunSpecifiedTests and list only the three allGood classes, as described in “Set the deployment options” above. That is the recommended setting for every install. Those other failures are still worth fixing, but they should not hold up this deployment.
Your org has a validation rule that the package’s test records do not satisfy — for example, a rule requiring an Email on every Lead or an Account on every Contact. Apex tests cannot bypass validation rules, so the test records have to satisfy them.Make sure you are installing version 0.6.1 or later, which builds its test records to satisfy the most common required-field rules. If it still fails, send allGood support the exact error message and the rule it names — we will adjust the package’s test data. As a stopgap, an administrator can temporarily deactivate that validation rule (Setup → Object Manager → the object → Validation Rules), deploy, and re-activate it immediately afterward.
Re-run with Rollback On Error checked; capture the error and send it to allGood support.