TPSClear
Menu
TPSClear for Salesforce

TPS/CTPS compliance built into Salesforce records.

TPSClear for Salesforce installs as a managed package. The verdict lives on the Lead and Contact, with custom fields for the TPS, CTPS and combined statuses. Flow and Apex triggers re-screen on change. Bulk API for backfills of large orgs.

Status: Building now. Join the waitlist for early access.
Join the waitlistOr use the API

TPSClear for Salesforce is in build. We are writing it as a managed package, the AppExchange listing is in preparation, and the security review queue is what it is. This page describes the integration as designed so that you can decide whether to join the waitlist and whether the architecture matches how your org is set up.

Honest status: not yet on AppExchange. We are aiming for a UK-tested release in Q3 2026. If you need TPS screening on Salesforce sooner, the API works today and you can drive it from a Flow or an Apex callout.

Architecture: the four objects we will set status on

The managed package is designed to write a TPS/CTPS verdict to every place a UK phone number realistically lives in a Salesforce org. That means four standard objects and one optional one.

  • Lead. The primary one. Most outbound teams discover and qualify at the Lead level, and that is where the TPS surface area is largest.
  • Contact. Post-conversion, the Contact gets the same treatment, with the verdict carrying across the conversion mapping.
  • Account. Account-level phone numbers (head office, switchboard) get their own status field, distinct from the contacts attached to them.
  • Person Account. If your org has Person Accounts enabled, the package detects this on install and provisions the status fields on the merged record rather than treating Person Accounts as a separate path.

Custom fields the package provisions

Each object gets a small set of custom fields, all under the tpsclear__ namespace so they cannot collide with anything you already have:

  • tpsclear__TPS_Status__c: the TPS verdict for the phone field.
  • tpsclear__CTPS_Status__c: the CTPS verdict.
  • tpsclear__Combined_Status__c: a rolled-up value (Clean, TPS, CTPS, Both, Unscreened) for use in list views and report filters.
  • tpsclear__Last_Checked__c: ISO timestamp of the last screen.

Re-screen pattern: Flow first, Apex trigger as fallback

We are building two ways to fire a re-screen, because Salesforce orgs differ on how much custom Apex they tolerate:

  1. Record-Triggered Flow. The default. The package ships a flow per object that fires on insert and on update of the relevant phone fields, queues a callout, and writes the verdict back via a Flow-callable Apex action. This is the path admins can read, modify, and version-control without engineering involvement.
  2. Apex trigger. For orgs at the governor-limit edge, the package includes an Apex trigger that batches phone changes across a transaction and screens them in a single async callout. Same outcome, fewer flow interview transactions.

Backfilling large orgs with Bulk API

For any org over about 100,000 records, screening one record at a time is the wrong tool. The package will include a backfill job that uses the Salesforce Bulk API v2 to extract phone fields in chunks, batch the screens through the TPSClear API, and write the verdicts back as a bulk update. We have benchmarked the pattern at roughly one million records per hour, governed mostly by your org's Bulk API limits rather than by us.

Permission set

Installation creates a TPSClear User permission set that grants read on the status fields and the rescreen action. Admins assign it to the profiles or roles that should see the verdict. Reps without the permission set still get the underlying record; they simply do not see the TPS columns.

Salesforce Compliance Cloud

For orgs on Salesforce Compliance Cloud, the package is being designed to surface the TPSClear verdict as a compliance signal that can be consumed by the Compliance Cloud rule engine. That means you can express "do not auto-dial CTPS-listed corporate numbers" as a Compliance Cloud rule rather than as a Flow condition. This piece is on the roadmap, not in the first GA release.

Screenshot: Lightning record page showing the TPSClear component on a Lead, with combined status, per-phone breakdown, and rescreen button.

Why we are doing Salesforce after HubSpot

Salesforce is the highest-value integration on the roadmap and also the one with the longest review cycle. We started with HubSpot because the marketplace review is faster and the install footprint is smaller, and because it let us prove the screening backend in production before putting it in front of an AppExchange security review. The Salesforce package will ship when it can pass that review without compromise, not when the listing page is live.

What you can do today

  • Join the waitlist so we can let you know when the managed package is in beta.
  • Use the API from a Flow HTTP callout or an Apex callable. The endpoint and pricing are the same we will use under the hood when the package ships.
  • If you want to understand what a compliant outbound process looks like in advance of installing anything, our TPS compliance guide walks through the regulation.