Skip to content

Queue a Screen From a Flow

Batch screening picks records up on its next run, which leaves a gap: a record created or edited during the day is not screened until that night, unless somebody opens it and presses Screen. A record-triggered Flow closes the gap by asking PhoneTools to screen the record as soon as it is saved.

PhoneTools ships an Apex action called Phone Screening for exactly this. You build one Flow per object you screen.

Creating the Flow

  1. Go to Setup and open Flows.
  2. Select New Flow, then Record-Triggered Flow.
  3. Choose the object you screen, such as Account.
  4. Set Configure Trigger to A record is created or updated.
  5. Set Optimize the Flow for to Actions and Related Records. The action runs after the record is saved, which is what PhoneTools needs.
  6. Select Done.

Screening Only Records That Need it

PhoneTools already ignores a record whose result is still in date, so this step is optional. Adding it means the Flow does not hand over records that would be passed over anyway, which keeps your Flow tidy and avoids needless asynchronous work on a large data load.

Add a Decision element beneath the Start element with an outcome that is met when the record is either unscreened or overdue.

  • Set Label to Is Null or Overdue, and let the API Name default.
  • Set Condition Requirements to Execute Outcome to Any Condition Is Met (OR).
  • Add a condition with resource {!$Record.pw_pss__NextPhoneScreenDue__c}, operator Is Null, value {!$GlobalConstant.True}.
  • Add a second condition with resource {!$Record.pw_pss__NextPhoneScreenDue__c}, operator Less Than or Equal, value {!$Flow.CurrentDateTime}.

Note: Use {!$Flow.CurrentDateTime}, not {!$Flow.CurrentDate}. The Next Screen Due Field is a Date/Time, and comparing it against a Date does not give you the answer you expect. If you screen an object other than Account, Contact or Lead, use whichever field you configured as its Next Screen Due Field in place of pw_pss__NextPhoneScreenDue__c.

Leave the default outcome as it is. Nothing needs to happen on that path.

Adding the Phone Screening Action

  1. On the outcome path of the Decision element, add an Action element.
  2. Search for Phone Screening and select it.
  3. Give the action a Label, such as Screen Phone Numbers, and let the API Name default.
  4. Set ID of Record to Screen to {!$Record.Id}. This input is required.
  5. Select Done, then save and activate the Flow.

Repeat for each object you want screened this way.

Note: A Flow on Lead will hand over converted Leads along with the rest, and PhoneTools will not screen them. Nothing breaks, but if you would rather the Flow did not pass them over at all, add {!$Record.IsConverted} equals {!$GlobalConstant.False} to the Decision element.

What Happens When the Flow Runs

The action does not screen the record on the spot. It hands the record's ID to PhoneTools, which screens it in the background a moment later, so the record is saved and the user carries on without waiting for the registers to answer.

That has three consequences worth knowing about.

  • The result is not on the record the instant it is saved. A user who is watching the record needs to refresh the page to see the new status, and may need to wait a few seconds first.
  • Nothing is reported on screen if screening fails. Errors are emailed to the address in Email address for screening alerts under the subject "ScreenPhoneNumbers Error", which is another reason to point that address at a monitored mailbox.
  • The user who saved the record needs the same access as a user pressing Screen on the record page, because the screening result is written back under their permissions. See Permission Set Assignments.

Bulk saves are handled properly. When a data load or a mass update fires the Flow for many records at once, Salesforce passes them all to the action together, and PhoneTools queues them as a single piece of background work rather than one per record.

PhoneTools also ignores the action when it is called from a batch job or from work that is already running in the background, which stops its own batch screening from setting the same Flow off again each time it updates a record.

Keep the Daily Job

A Flow screens records as they are saved. It does nothing for a record that nobody touches, and a record's result still goes out of date on its own 21 days after it was screened.

Treat the Flow as a way of closing the gap between a record being saved and the next scheduled run, not as a replacement for it, and keep the daily job enabled. See Schedule a Daily Batch Screening Job.