Skip to content

Activate Triggers

Overview

AddressTools uses Apex triggers to apply its functionality whenever a record is created or updated. The trigger takes care of your validation rules, standardises country and state values, populates lookup fields, and updates the address status after verification.

Every object with address fields configured in AddressTools needs a trigger in place. Without a trigger, AddressTools cannot act on that object, so validation, standardisation, lookup field population and verification status updates will not run.

Triggers for four standard objects come with the package:

  • Account
  • Contact
  • Contract
  • Lead

These can be enabled or disabled from AddressTools Administration > Settings. For any other object that uses AddressTools features, you will need to create a custom trigger.

Step 1: Enable or Disable the Standard Triggers

The standard triggers come enabled in your org automatically, but you can turn them on or off at any time.

  1. Click the App Launcher to search for and select AddressTools Administration.
  2. Select Settings from the left menu.
  3. Scroll to the Trigger Settings section at the bottom of the page.
  4. Find the setting for the object you want to change:
    • Enable Account Trigger
    • Enable Contact Trigger
    • Enable Contract Trigger
    • Enable Lead Trigger
  5. Click the pencil icon beside that setting.
  6. Select the checkbox to enable the trigger, or clear it to disable the trigger.
  7. Click Save.

Note: Turning a trigger off stops AddressTools behaviour on that object, including validation, standardisation, lookup field population and verification status updates. It does not remove any data already written to your records.

Step 2: Create a Trigger for Unsupported Objects

If you have configured an address block on an object that AddressTools does not supply a trigger for, you will need to create one yourself.

  1. Navigate to Setup > Object Manager.
  2. Select the object.
  3. Select Triggers, then click New.

  4. Replace the default code with the following, then substitute your own object's details:

    trigger ValidateOBJECTLABELCountryFields on OBJECTAPI (before insert, before update) {
    pw_ccpro.CountryValidator2.Validate(Trigger.new, Trigger.oldMap);
}

  5. Replace OBJECTLABEL with the object's label and OBJECTAPI with the object's API name.

  6. Click Save.

Repeat for each object that needs one.

Note: To deploy a custom trigger to production, you may be required to provide code coverage to the trigger. To do this, you will need to create an Apex test to insert a record into the object you created a trigger on.

Trigger Settings

Beneath the four standard object triggers in AddressTools Administration > Settings, the Trigger Settings section has two further settings that change how the triggers behave. Both apply across every object, including any custom triggers you have written, and both are off by default.

Edit them the same way as the supplied triggers: click the pencil icon beside the setting, change it, then click Save.

Run Trigger Only Once

The trigger fires once per transaction rather than every time the record is touched.

This reduces the number of SOQL queries AddressTools uses, which is worth doing if you are hitting Too Many SOQL Queries exceptions in an org with a lot of automation on the same object.

The trade-off is accuracy. AddressTools cannot guarantee it is the last thing to run on upsert, so if another process changes the address after AddressTools has run, that change goes unchecked and the saved address may not match your AddressTools settings.

Run Trigger Only When an Address is Modified

The trigger skips updates to existing records unless one of the fields mapped in the address block has actually changed.

This is useful on objects that are updated frequently for reasons unrelated to the address, as it stops AddressTools re-processing an address that nobody has touched.

Bear in mind that it only looks at the fields mapped in the address block, so a change to an unmapped field will not wake the trigger, and neither will a configuration change elsewhere in AddressTools. Records already saved keep whatever values they had until something edits a mapped field.

Note: New records are unaffected by this setting. It only changes how the trigger behaves on updates to records that already exist.