Blog

Use a Lightning Web Component (LWC) from a managed package inside a custom LWC

Introduction 

This article covers how to use a Lightning Web Component (LWC) that exists inside of a managed package (from a different namespace) inside a custom LWC. 

This is something we have been able to do with Aura components for a long time but still to this date we face challenges to complete this operation when working solely with LWCs. 

To solve this problem, we will look at using Lightning Web Security in Salesforce. 

The use case

Managed packages are a great way to obtain pre-built functionality for your org quickly and can be installed by following a URL or through the AppExchange. 

Some of these managed packages will contain LWCs which you may want to wrap inside your existing components. This is achieved by referencing the LWC name(s) in your source code. 

Without using Lightning Web Security, you will encounter the error “Attempting to reference cross-namespace module X in Y” which is why Lightning Web Security must be enabled for this solution. 

Reference a managed LWC inside a custom LWC 

In this scenario we’re going to use the Address Verification Flow Component by ProvenWorks as it demonstrates: 

  • An LWC belonging to a managed package namespace (pw_avfc), 
  • Using properties in a component. 

I have created a new LWC in Visual Studio Code and opened the HTML file. Lines 3 to 6 reference the Address Verification Flow Component. 

Whilst the component name is pw_avfc:addressVerificationFlowBaseComponent, the camel casing needs to be converted to kebab casing. This changes the name (and what we would have used in Aura) to pw_avfc-address-verification-flow-base-component. 

If you’re not familiar with kebab casing, check out this trailhead that explains how to convert from camel casing to kebab. 

The component has some properties that we’re passing values to, these names (useCounty and inlineMode) have also been converted to kebab casing. 

Once you have completed the above, you can deploy the LWC to your org. 

Enabling Lightning Web Security 

As mentioned, this approach will only work when Lightning Web Security is enabled so we must enable this before testing.  

  • Go to Salesforce Setup | Session Settings. 
  • Enable Use Lightning Web Security for Lightning web components. 
  • Select Save. 

You will now need to clear your browser cache for the change to take effect. 

Lightning Web Security overview 

This article isn’t for the purpose of explaining Lightning Web Security in any detail other than it’s the answer to this problem. At the date of writing this article (31/AUG/2022) Lightning Web Security comes with limitations that can impact other component behaviour. 

The Salesforce Developer documentation on the topic is filled with lots of useful information about the feature. You can find out more here: Lightning Web Security – Salesforce Lightning Component Library. I recommend specifically reviewing the subtopic of “When to Enable Lightning Web Security” as this may help you determine if it is suitable for your use case. 

At the time of writing, a current example of Lightning Web Security causing issues is when using Vlocity OmniStudio. When the feature is enabled in an org, OmniStudio becomes unusable. To work around this, you can simply disable the setting, use OmniStudio and then reenable Lightning Web Security when you’re ready to deploy.  

Specifically with OmniStudio, Salesforce’s current recommendation is “..keep the ‘Use Lightning Web Security for Lightning web components’ checkbox unchecked…” Not able to save Omniscripts – ‘Use Lightning Web Security for Lightning web components’ Enabled (salesforce.com) but there may be some alternative options like leaving it disabled in sandbox/dev organisation and enabled in production, but this really is a last resort. 

Test your component 

Now it’s time to look at the component. Place it somewhere in your org to test (i.e. an app, a flow screen, etc.). When you look at your custom component, you should now find the managed package component is successfully rendering within it. 

If you’re still seeing errors linked to “Attempting to reference cross-namespace module” then ensure your browser cache is cleared and try again. 

Summary

We’ve investigated how you can wrap a LWC from a managed package inside of a custom LWC which will hopefully unlock some potential for your org to grow quicker than before. Whilst it is currently dependent on Lightning Web Security (which has its limitations), it is clear that Salesforce is continuing to work on and improve its functionality. 

Everything you need to know about AddressTools 8.0 (Summer ‘22 Release)

You may think we’ve been quiet for a little while with AddressTools releases, but we’ve been hard at work to bring you AddressTools 8.0 🚀

We’re always aiming to provide a better product to our customers so in this post, we’ll go through the changes and improvements we’re bringing in this latest update of AddressTools.

Here’s what we’ll cover in this article:

Enhanced support for State & Country/Territory Picklists

At it’s core AddressTools has always been compatible with Salesforce State & Country/Territory Picklists. However we acknowledge that it was a real chore to configure and could lead to a world of confusion when deploying the tool.

We’ve streamlined this and drastically improved the experience to provide clearer support to the end user when Salesforce State & Country/Territory Picklists are enabled. You will now see picklists available in all AddressTools components and there is better compatibility between your AddressTools dataset and the Salesforce State & Country/Territory Picklists dataset.

With the upcoming custom address field type which is locked to using Salesforce State & Country/Territory Picklists, this update will streamline your setup time drastically. Keep your eyes peeled as we continue to improve this experience!

What’s changed so far?

  • Added support for Salesforce State & Country/Territory picklists in override page.
  • Added support for Salesforce State & Country/Territory picklists in record page component.
  • Improved the unison between datasets minimising the task of aligning the two.
  • Correct acknowledgement of inactive State & Country/Territory data.
  • Introduced support for the use of text and picklist fields simultaneously (Address field type ready!)

New Address Label data returned with address verification 

Do you send international mail and sometimes wonder how to format the address? In this release we have implemented a useful feature ideal for international mailing. Address Label outputs – enabling a hassle-free label, ready for printing.

When using verification, you will now be able to configure a text area in Address Blocks and it will automatically be populated with how the address should be formatted for the country it will be sent to, ready for postal services to handle. Check out the updated documentation here.

Improved page layout management

We always try to make life as easy as possible for our users. In this latest release, the AddressTools override page will place all required functional fields onto the page layout for you. 

No more wondering why the address status didn’t update, no more trawling through page layouts to ensure they have all the fields you need, no more confusion. Just a quick setup that’s ready to go out of the box. 

New storage information & installation options available in the AddressTools Administration Page

Storage-related issues have been the #1 cause of raised cases in the last few weeks. That’s why we’ve added some extra information and options when configuring the tool so that you can be your own data hero.

Users can now select what data points they want to install from the AddressTools dataset. Don’t need US County data? Then leave it unchecked during install! Just testing in a sandbox? Why not just use Country and State data.

We’ve also added your current storage size and total available storage to the overview panel so you have all the information to make the right decisions with no distractions.

And there’s more…

On top of the highlights we’ve explored here, AddressTools version 8.0 brings a ton of quality of life enhancements. If you want to see the full list of features and improvements, you can check out our release notes

How do I update to AddressTools 8.0?  

You can upgrade your version of AddressTools by installing the package from the Appexchange. 

💡 If you need a helping hand, here’s our blogpost on how to upgrade an AppExchange app in 4 easy steps.

Try AddressTools for free  

We provide a 14 day free trial here so you can try out AddressTools 8.0 for yourself! Start journey to better data today.


Updating your solutions for Legacy API Retirement in Summer ‘22

What Legacy APIs are Salesforce retiring?

As part of their Summer ‘22 Release, Salesforce has announced the retirement of a number of legacy APIs.

Versions 7.0 through 20.0 of the Salesforce Platform SOAP, REST, and Bulk APIs will be deprecated and no longer supported as of the Summer ’22 release.

This means that these legacy APIs, and third-party integrations that rely on them, will cease to function after the release.

When are the Legacy APIs being retired?

Salesforce announced that June 10 and 11 2022 is the final release weekend when all remaining Salesforce instances are upgraded if they haven’t been already.

Legacy API Retirements and ProvenWorks solutions

To ensure that you do not encounter any issues with AddressTools, SimpleImport, IndustryComplete or PhoneTools, we recommend ensuring that your current version is or is later than the versions listed in this post. If you need advice on how to upgrade an AppExchange managed package, please see the resources linked at the end.

We have listed the version of each tool, including a link to its latest AppExchange listing, that you must be on in order to be using supported APIs.

AddressTools Premium:

7.75+

AddressTools Free:

6.20+

Address Verification Flow Component:

1.72+

SimpleImport Free:

2.47+

SimpleImport Premium:

2.57+

ManagedImport:

1.15+

PhoneTools:

2.0+

IndustryComplete:

2.16+

Resources

Prepare for Legacy API Retirement in Summer ’22 – Salesforce Developers’ Blog

Salesforce Platform API Versions 21.0 through 30.0 Retirement – Salesforce Help

Salesforce Summer ‘22 Release — Here’s What to Expect – Salesforce News

Salesforce Summer ’22 Release Notes

Don’t Miss These Key Dates: Summer ’22 Sandbox Preview

How to upgrade your ProvenWorks solution

We wrote a handy four-step guide to walk you through how to upgrade your AppExchange solutions.

Contact us

If you’re worried about how the API retirements might affect you and your ProvenWorks solution, please don’t hesitate to contact us.

Prepare your address data for the Custom Address Field Type in Salesforce

If you, like many of us, have been eagerly awaiting the custom address field type in Salesforce (it’s only been like 10 years or so?), then you’ll be pleased to hear that Salesforce has announced it is in Beta from the Summer ‘22 release! 

At ProvenWorks we’ve been fortunate enough to participate in the closed pilot since day one so we have been able to follow its progress. We’re now excited to be able to share with you some information so that you can be prepared for its release.

Isn’t the custom address field just like the standard address field type?

Sort of – however, be prepared that State & Country picklists are enforced for all new custom address fields in Salesforce, regardless of your existing org settings. This is largely why we’re writing this article.

State & Country picklists provide a neat solution for ensuring clean data at the point of entry, but admittedly, we’ll be the first people to warn you about the integration issues, customization headaches, and maintenance anxiety you may face when using Salesforce State & Country picklists.

…Nevertheless we are address experts in Salesforce so we’re going to embrace State & Country picklists head on and let you know how to prepare if you wish to migrate from custom text fields to the new address field type.

Important: If you’re steering clear of State & Country picklists and you wish to remain using text fields then keep doing what you’re doing! There is no need to change if it works for you. The rest of this article may still be helpful to understand how to standardize data stored in State and Country text fields.

Standardization is critical

Keeping org data clean is the driving force behind Salesforce’s decision to enforce State & Country picklists for the new field type. If you, like many others, have been excited to migrate away from five custom text fields to a single address compound field, then we’re going to have to standardize that data before the migration process.

The rest of this article will walk you through a fast and efficient way to standardize your existing data from within Salesforce using AddressTools Premium. We’ll cover two approaches:

  1. Create a standardization trigger leveraging AddressTools and run a “mass update” to execute the logic.
  2. Export a standardized list of address data ready for reimporting back into Salesforce.

Both approaches require the same initial steps for configuring AddressTools’ standardization functionality so we’ll start there and break out into the two options later.

The use case

The scenario we’ll be following will be looking at a custom object called “Warehouse”. The Warehouse object contains five custom text fields that when put together create an address. We will refer to these fields collectively as an “address block”.

The five custom fields are:

  • Street
  • City
  • State
  • Postal Code
  • Country 

The fields are populated from a number of different sources – web forms, integrations and user entries – so we cannot guarantee that the data is standardized. 

To prepare this data we’re going to expedite the process by using AddressTools Premium available on the AppExchange. As users (and developers) of the package we have heaps of experience and even some hidden tricks that’ll save days. It shouldn’t take more than a couple of hours from start to finish.

Installing the AddressTools Premium trial

If you’re not already using AddressTools Premium in your organization you’ll need to first install it from the AppExchange. You can do this in a sandbox if you want to test the functionality before pushing it to production.

Note: AddressTools Premium is a paid-for product that comes with a 14-day free trial. This could save you days of work so the cost may be something worth considering, especially if you have wider address requirements.

  • Go to the AddressTools Premium AppExchange listing.
  • Select Get It Now.
  • You may be prompted to log in if not already.
  • Select Install in Production or Install in Sandbox depending on your requirements. It is best practice to test in a sandbox before moving to production.
  • Agree to the terms and conditions.
  • Select Confirm and Install.
  • You may be prompted to log in again. If so, log into the org you want to install the package to.
  • Select Install for Admins Only.
  • Press Install.
  • Check Yes, grant access to these third-party web sites.
  • Select Continue.

Let the process install the package. AddressTools Premium has a lot of features so it may take some time to install (you may receive a warning saying it’s taking a long time, this is normal). When the package has completed its installation you’ll receive a success email.

Once the package has been installed, navigate to the AddressTools App (via the App Launcher) and open the AddressTools Administration tab. You’ll immediately be on the Installation sub-tab.

  • Under the Installation tab, select Create Token.
  • A green tick will appear next to the first step.

Next we’ll want to install the AddressTools Premium dataset. This is a list of countries, states, alternative names, ISO codes, (and heaps of other address-related data).

Warning: This dataset is large. Ensure you have enough storage available if you’re testing this in a sandbox. If your allocated storage is low or you are unsure you can select Only install sample data but beware this will not populate any alternative country and state values that will be used to expand the acceptable standardization data for countries and states. This can be manually added later if you so wish.

  • Under Data Installation, select Get Started.
  • Optionally choose Only install sample data.
  • Select Install.
  • A final warning will appear in relation to storage size. When you’re ready press Yes.

This may take some time and will preconfigure some functionality for your org. Feel free to continue reading this guide so that when you’re done you’ll be ready to rock.

  • Once the installation has finished, refresh the page to see that green tick.

Disabling the out-of-the-box functionality

A trigger is provided out of the box for the Account, Contact, Contract and Lead objects. If this is a fresh installation of AddressTools Premium in your org we’ll want to disable these triggers so that we don’t impact current business processes when we begin enabling functionality further down the line.

After the data installation:

  • Select Settings from the left navigation.
  • Scroll to Trigger Settings.
  • Disable each of the trigger settings in this section.
  • Select Save.

If the address fields you want to standardize exist on one of the four objects, the triggers can be re-enabled at a later point.

Configuring the address block

As mentioned earlier we’ll be referring to the five custom text fields as an “address block”. We need to configure AddressTools Premium with each of the text fields. This will allow the tool to execute standardization on the custom State & Country fields. 

  • On the AddressTools Administration page, select Address Blocks from the left navigation.
  • Use the Add button in the top right.
  • Select the object where your address block exists. We’re choosing Warehouse__c.
  • If you have record types enabled on the object, leave None chosen.
  • Select Next.
  • Under Postal Address Fields, select the relevant fields for each picklist:
    • Country
    • State
    • City
    • ZIP/Postal Code
    • Street

With the object and address fields now specified, it’s time to choose the settings we want to enable for the block.

Whilst still on the new address block modal:

  • Scroll down to Global Settings.
  • Check Standardize Country.
  • Check Standardize State.

Note: there are plenty of other settings here that may take your fancy. A tooltip is provided next to each giving you some insight into what’s available. You can come back to this page at any time should you wish to explore the other capabilities of AddressTools Premium.

  • We’ll complete this step by selecting Save.

Configure standardization values

Standardization is the process of converting multiple acceptable values to a single value. For example let’s take a look at the country Egypt:

  • Full name – Egypt
  • ISO-2 – EG
  • ISO-3– EGY
  • Local name (Latin characters) – Miṣr
  • Local name (Native characters) – مِصر

Each of the above values are technically correct entries for Egypt but a picklist won’t allow all of these values to be entered. Using a text field to accept all the variations of the country name will ease the stress for end users, integrations and streamline future expansions of your org. It’s then best practice to standardize the values to a single preferred format for analytical purposes after the data is inserted.

To identify the acceptable values for each country we’ll take a look at the Countries object installed with AddressTools. This is one of the objects that the data installation will have populated records for and is fundamental to the standardization functionality.

  • Select App Launcher.
  • Search and select Countries.
  • Select All from the available list views.
  • To help understand the data, select the United States country record from the list view.

Looking at the Country record, you can find dedicated fields for:

  • Full name
  • ISO-2
  • ISO-3
  • Local name (Latin characters)
  • Local name (Native characters)

The good news is that each of these field’s values are automatically configured to be accepted in text fields configured with AddressTools Premium. When the AddressTools trigger functionality is enabled the values will be standardized to a defined format on insert and update.

Let’s take a look at another example for acceptable data by talking about United Kingdom, or do I mean Great Britain, or England?… You get where I’m going…

State & Country picklists don’t support the inputs of these variations, and these variations also don’t fit into the five dedicated fields on the Countries object. This is where we introduce Alternative Country Names.

  • Whilst still looking at your existing country record, select Related.
  • Select Alternative Country Names.

This list may be empty depending on the country you’re looking at or because you only installed the sample dataset. Don’t worry, you can add as many records here as you find necessary. 

To add a new Alternative Country Name:

  • Select New.
  • Write the value into the Alternative Country Name field.
  • Ensure the Original Country field is populated with the Country.
  • Is Obsolete: Unchecked.
  • Select Save.

And it’s that simple, you’ve now added an Alternative Country Name that AddressTools will be able to identify during the standardization process.

The State object is configured similarly. To access States navigate to the related list on the Country record. For example, navigate to the United States Country record, select Related, and here you’ll find a list of states belonging to the United States. 

Each State record has a:

  • Full name
  • ISO code

An Alternative State Name object is available where you can add a list of acceptable values. After all, we can’t seriously expect all our users to spell Mississippi correctly every time… So practically speaking if there are common misspellings or abbreviations you find in your org you can add them here to be standardized.

That covers configuring all of the acceptable values. Now we need to define the formats for the data to be standardized to.

Defining the standardized formats

Whilst we’re still looking at Country and State record data, we’ll configure the State format first. 

This is managed on the Country record and can be controlled on a per-country basis. 

  • Navigate back to a Country record (i.e. United States).
  • Enable or disable Use Subcountry Code in State field.

This option can be enabled/disabled to standardize the state value to either its full name or ISO value (i.e. Texas vs TX).

Lastly, we need to define the Country format. This is an org-wide setting and applies to all country values.

  • Go to the AddressTools Administration tab.
  • Navigate to Settings in the left navigation.
  • Use the pencil icon next to Standardization Enabled.
  • Check Standardization Enabled.
  • Edit the Country Standardization Format to match the desired format.
  • Select Save.

Note: These settings can be changed at a later date if you need to change your format. You’ll then need to run one of the following jobs to standardize the data to the new format.

It’s configured, now what?

We have two options to mass standardize the data:

  1. Enable a trigger on the object, run a mass update and have the trigger standardize all the data during the update.
  2. Invoke a job via the Developer Console to export a standardized list of data that can be manually reimported into Salesforce.

Choose the approach that best suits you. If you’re unsure what route to take we have instructions below walking you through both.

Option 1: Create a trigger on the object and run a mass update.

We’ve configured all the standardization settings so now we need to tell the object to follow them. As we’re working with a custom object in this example we’ll need to create a new trigger in the org to invoke the AddressTools functionality.

A trigger is provided out of the box for the Account, Contact, Contract and Lead objects. Follow the relevant steps to enable or create a trigger for the object where your address block exists.

If you’re working with either of the Account, Contact, Contract or Lead objects:

  • Navigate to the AddressTools Administrator tab.
  • Select Settings from the left navigation.
  • Scroll to Trigger Settings.
  • Enable the trigger on the object you’re standardizing.
  • Select Save.

If you’re working with an object that isn’t Account, Contact, Contract or Lead:

  • Go to Setup.
  • Navigate to Object Manager.
  • Locate the Object you want to create the trigger for.
  • Select Triggers and New.
  • In the box, replace the existing code snippet with the following:
trigger ValidateOBJECTLABELCountryFields on OBJECTAPI (before insert, before update) {
    pw_ccpro.CountryValidator2.Validate(Trigger.new, Trigger.oldMap);  
}
  • Replace OBJECTLABEL with the label name of the object you’re creating the trigger for.
  • Replace OBJECTAPI with the API name of the object you’re creating the trigger for.
  • Select Save.

With the trigger enabled for the object, we need to turn on the standardization setting in the AddressTools Administration tab:

  • Navigate to the AddressTools Administrator tab.
  • Select Settings from the left navigation.
  • Under Feature Enablement, check the box for Standardization Enabled.
  • Confirm that the Country Standardization Format is set as you desire.
  • Select Save.

Before we do a mass update we can test the standardization functionality on our address block. 

  • Navigate to a record where your address block exists.
  • Edit the record.
  • Change the country text value to a variation of the value currently present (e.g. if the country is United States, change it to USA or US).
  • Save the record.

The record will standardize to the format specified in the settings. (If you entered the desired format, the value won’t change on save as it’s already in the expected format. Try changing to another format to confirm the test).

Before save:

After save:

Now the test has been confirmed we need to invoke the trigger on all existing records. This will involve running an update on every record in the object. There are many different ways that you can achieve this so if you can already think of one then do what you know best.

If you need some guidance, we have a separate article on how to run a “mass touch” using Salesforce Flows. Check it out here.

Once the mass touch operation has successfully run, all State and Country values that matched the AddressTools dataset will now adhere to your defined standardization format.

There may be some leftover values and this will require some manual intervention. If you find a repeat offender you can add the value to the Alternative Country or State Name objects and re-run the process to catch them.

Option 2: Export the standardized data for importing later

Before we start, it makes sense to see the result of these instructions so let’s take a look at what our exported file will contain.

For every record on the configured object that can be standardized, the data will be exported with the following data in the file:

  • Record ID
  • Current text field values (Old)
  • Standardized versions of the text field values (New). 

Note: The export will ignore records that are already in the desired format or that contain data that cannot be standardized (i.e. an unrecognized value).

To prepare AddressTools Premium to execute this export:

  • Navigate to the AddressTools Administrator tab.
  • Select Settings from the left navigation.
  • Under Feature Enablement, check the box for Standardization Enabled.
  • Confirm that the Country Standardization Format is set as you desire.
  • Add your email address to the Batch Verification Alerts Email Address field.
  • Select Save.

This process will need permission to send an email to the email address configured in the previous section. You may need to change your org’s Email Deliverability settings to support this.

To check/change your Deliverability settings:

  • Go to Salesforce Setup.
  • Search for Deliverability in the left search.
  • Select Deliverability from the left navigation.
  • Make note of your existing Access level, you can revert the setting back to this once you’re done.
  • Change Access Level to All email.
  • Select Save.

For some of you reading this guide, you may not have worked with the Developer Console before so follow closely and let’s execute some Apex! 

Note: If this is your first time we recommend doing this in a sandbox so you don’t affect any production data.

  • Go to the cog in the top right of your Salesforce page.
  • Select Developer Console.

The Developer Console window will open in a new window.

  • Select Debug | Open Execute Anonymous Window.
  • Under Enter Apex Code, type the code below 
pw_ccpro.BatchValidateAndGenerateCSV M = new pw_ccpro.BatchValidateAndGenerateCSV('OBJECTAPI');
Database.executeBatch(M);
  • Change OBJECTAPI to the API Name of your Object. We’ll be typing ‘Warehouse__c’.
  • Select Execute.

This will now begin the standardization process. The length of time it will take to execute will vary depending on how much data you have in your org.

Once the job is complete you will receive an email with a .csv attachment containing all of the standardized data from the address block ready for importing either into the existing fields or ready to migrate into your State & Country picklists. 

And there you have it – your standardized file is waiting for you! When you’re ready to import this data back into Salesforce, use an importing tool* of your choice and ensure to update the records matching the Record ID found in column A.

Warning: Be vigilant when running mass update operations in a production environment. Where possible backup your data first.

*Pssst if you’re looking for a new favorite importing solution, why not try out SimpleImport for this import job!

Summary

So there you have it, we’ve walked through how to standardize your existing data ready for the new custom address field type in Salesforce using AddressTools Premium.

If you have found this guide to be helpful, please ensure you share it with others so that they can learn how to standardize their address data stored in text fields. If it has saved you time then it may save them time too!

If you have any questions about AddressTools and any of its capabilities we’d love to hear from you. Get in contact with us at info@provenworks.com.

Address Verification Flow Component: Installation Walkthrough

The Address Verification Flow Component for Salesforce is an extension available for AddressTools Premium and is the perfect component for user registration, e-commerce checkouts and service cloud flows. It’s a Lightning Web Component (LWC) that can be quickly added to a Salesforce Flow Screen, or be wrapped in your own custom component to truly fit your needs and can be deployed in minutes.

To leverage this component, your org must have AddressTools Premium installed from the AppExchange with Address Verification credits.

First-time initialization

Deployment to users

Add to a Salesforce Flow Screen

Understanding the parameters

Enable Street Line 2

Display Company Name in Address

Provide access in a Digital Experience

Apply custom CSS using Additional Styles

Address Verification Flow Component: Add the component to a Flow Screen

Adding the component to a Flow Screen

The component can be dropped into a flow screen in a place of your choice. It is designed to use the same variable names as the standard Address component provided by Salesforce allowing you to quickly “hot-swap” your existing address component with the Address Verification component.

  • Navigate to your Salesforce Flow in Salesforce Setup.
  • Double click an existing Screen element to open its editor or add a new Screen to your flow.
  • Search for Address in the Component search.
  • Drag the Address Verification by ProvenWorks component into the flow screen.
  • Fill in the desired parameters to meet your requirements.

When you’re done, save your flow and you’re ready to go!


Back to the Address Verification Flow Component installation walkthrough

Address Verification Flow Component: Create an authentication token

Create an authentication token

First, you will need to create an authentication token so that your organization can communicate with the address verification service.

  • Go to App Launcher | Address Verification Flow Administration.
  • Use the Create Security Token button.
  • If you need to update the security token in the future (which can be required after a sandbox refresh), select Update Security Token.

Now that your organization can communicate with address verification service, you can move on to implementing the component in your environment.


Back to the Address Verification Flow Component installation walkthrough

Get ready for PhoneTools 2.0 (Spring ‘22 Release)

We’re excited to announce that PhoneTools 2.0 (Spring ‘22 Release) has arrived!

PhoneTools lets you screen your numbers against the TPS and CTPS databases, keeping you compliant with UK data privacy laws – all within Salesforce! With the much-anticipated addition of flow functionality and brand new support documentation, let’s take a closer look.

Screen your numbers in a Salesforce flow

Let’s quickly recap PhoneTools so far. PhoneTools already allows you to schedule automated nightly record screening, specifically records that have not yet been screened or have their Next Screen Due Date in the past.

Whilst practical, this leaves a window of time after the record is inserted/updated where the numbers won’t be screened until the next nightly batch job or manual user interaction.

That’s where flows come in to fill the gap.

PhoneTools 2.0 can be used within the powerful process automation tool that is Salesforce flow. What does this look like in practice? This means that you can now queue an immediate TPS and CTPS screening job to get the numbers’ screening statuses in seconds*!

With the flow, PhoneTools will queue a screening job automatically so there’s no need to wait for a nightly screening job. Equally important, is that you no longer need to rely on the user to manually click ‘Screen Phone Numbers’. Crucially, this means you can remove responsibility from your users and automate the process… what a business win!

How can you use your flow? Our best practice recommendation is to queue your screening jobs on insert and update to make sure your org has a shorter period of time holding data without a valid screening status. The outcome? Streamline your sales team’s operations and let them focus on what they do best, selling!

*This relies on an asynchronous Salesforce Future Methods – times may vary depending on your org.

Does this replace my existing method of screening numbers?

This flow functionality is designed to be an additional method to screen numbers on top of what you already have configured. The nightly batch job is key for picking up those records when they’re overdue and the ‘Screen Phone Numbers’ button is helpful for re-opening old prospects. The flow functionality is designed to minimize the gap between inserting new data and providing a status as soon as possible without user interaction.

Tried and tested documentation

With the addition of flow capabilities, we’ve published some new documentation to walk you through our recommendation for configuring the PhoneTools flow.

By the end of the guide, you’ll have your own flow configured and ready to screen those inserted and updated numbers. With the flow, you’re good to go!

How do I access PhoneTools 2.0 (Spring ‘22)?

Great question! In order to access PhoneTools 2.0, you will need to upgrade your package version from the AppExchange. If you haven’t installed PhoneTools, why not use our two week free trial?

Need a bit more help? Check out our handy guide: How to upgrade an AppExchange App in 4 steps.

If you get stuck or have any questions, feel free to contact our Support team who are more than happy to help you: support@provenworks.com.


PhoneTools

Screen against UK TPS and CTPS databases to stay compliant and avoid fines. Learn more and book a demo.

How to fire a trigger for existing records in Salesforce using Flows

So you’ve just deployed a new trigger or flow and you want to push your org’s existing records through it. This can often be referred to as a “Mass Touch” or “Mass Update”. There are many different ways that this can be achieved, some involving exporting data using third-party tools, but here’s one approach that can be done completely within Salesforce, and with no code!

Create a new “Mass Touch” field

We’ll start the process by adding a new field on the object we want to fire the trigger on. This field will be used to update the record without touching its existing data.

  • Go to Salesforce Setup.
  • Select Object Manager.
  • Locate the object you want to execute a mass touch for and select it.
  • Go to Fields & Relationships.
  • Select New.
  • Data Type: Number.
  • Press Next.
  • Field Label: Mass Touch
  • Length: 1
  • Decimal Places: 0
  • Field Name: MassTouch
  • Help Text: This field should only be used to invoke an update on the record and should not be populated by user entry.
  • Press Next.
  • Only provide visibility to your profile (or the profile of the user completing this process).
  • Press Next.
  • Uncheck Add Field to prevent the field from being added to the page layout.
  • Select Save.

Your object now has a new field that can be updated without impacting existing business data.

Creating a scheduled flow

We now need to create a flow that’s going to look at all the records on the object and update the Mass Touch field just created. We’re going to do this using a Scheduled Flow as this will allow us to set a time for the process to fire. If your object has a lot of existing records it may be preferable to run this process out of hours.

  • Go to Salesforce Setup.
  • Search for Flows in the left navigation and select Flows.
  • Select New Flow.
  • Choose Schedule-Trigger Flow and select Create.
  • Select Set Schedule.
  • Choose a Start Date and Start Time that work for your org.
  • Set Frequency as Once.
  • Select Done.
  • There is no requirement to specify an object in the start element so leave this empty.

The start element in the flow is now configured. Let’s follow that up and add an Update Records element.

  • Press the + icon to open the Add Element view.
  • Scroll down to Data and select Update Records.
  • Label: Update Records
  • API Name: UpdateRecords
  • Description: Set the records' Mass Touch field to a new value.
  • How to Find Records to Update and Set Their Values: Specify conditions to identify records, and set fields individually.
  • Under Update Record of This Object Type, search and select the Object you want to perform the mass touch on.
  • Under Filter Object Records, you can add conditions to only mass touch a selection of records, or have this set to “None” which will update all. We’ll use None for this example.
  • Under Set Field Values for the Object Records, choose the Mass Touch (MassTouch__c) field.
  • Value: 1. (If you’re running the mass touch on this object again in the future you can change this value to 2, or 3 and keep cycling the number for each mass touch you want to complete, it just needs to change from its previous value).
  • Select Done.

With the flow configured, we now need to save it and name it.

  • Select Save from the top right.
  • Provide a Name and Description for the flow so that you will be able to identify it in the future should you wish to run it again.

Validation rule management

Before running a mass touch job on the object we need to consider validation rules. Flows do not have an elegant way to bypass validation rules so keep an eye out for any flow errors when the job runs. An email will be sent to your own user account’s email address containing the errors faced during the flow allowing you to manually correct the conflicting errors (see image below).

If there are some common offending validation rules consider disabling them temporarily to complete this task but remember to re-enable them when you’re done!

Run the flow

The flow is now fully configured and ready to be activated. Use the Activate button in the top right to enable the flow. The mass touch operation will begin when the scheduled time configured in the Start element is met.

If you don’t want to wait for the scheduled time you can run the flow immediately by selecting Debug. Make sure that you uncheck “Run flow in rollback mode” to ensure that the mass touch’s changes persist after the flow has been executed.

Remember, check your emails after the flow has run to review any errors as the update can roll back multiple records even if a single record fails.

Summary

We hope that you have found this article to be helpful for your organization and just a reminder to be vigilant when running mass update operations in a production environment, where possible backup your data first.

If you’d like to find out more about what ProvenWorks do, check out our homepage.

PhoneTools: Queue a Screen Immediately with a Salesforce Flow

Automated phone screening functionality covered so far in this installation walkthrough will screen records nightly that have not yet been screened or have their Next Screen Due Date in the past. Whilst practical, this leaves a space of time between the record being inserted/updated where the numbers won’t be screened until the next nightly batch job or user interaction.

That’s where flows come in to fill the gap.

Create a flow to screen the record

  • Go to Salesforce Setup | Flow.
  • Select New Flow.
  • Choose Record-Triggered Flow.
  • Search and select the object that you are configuring the process for.
  • Set Trigger the Flow When to A record is created or updated.
  • Select Done.

The flow will now be ready to start adding elements to.

  • Select the Decision Logic and drag it under the Start element.
  • Label: Is NULL or Overdue
  • API Name: IsNULLorOverdue

Under New Outcome:

  • Label: True
  • Outcome API Name: True
  • Condition Requirements to Execute Outcome: Any Condition Is Met (OR)
  • Resource: {!$Record.pw_pss__NextPhoneScreenDue__c} Note: this field will be the Next Screen Due Date field which may be custom dependant on your configuration.
  • Operator: Is Null
  • Value: {!$GlobalConstant.True}
  • Select Add Condition
  • Resource: {!$Record.pw_pss__NextPhoneScreenDue__c}
  • Operator: Less Than or Equal
  • Value: {!$Flow.CurrentDate}
  • Select Done

The decision element will now be shown in the flow and needs connecting to the start element.

Select and hold the connecter point on the Start block and drag it to the Decision element. This will create a connection between the two elements.

Now we need to add the Phone Screening element to the flow.

  • Select the Action Interaction and drag it under the Decision element.
  • In Action, search for Phone Screening and select the suggested item.
  • Label: Screen Phone Numbers
  • API Name: ScreenPhoneNumbers
  • ID of Record to Screen: {!$Record.Id}
  • Select Done.

The Screen Phone Numbers element will now be shown in the flow and needs connecting to the Decision element where the outcome is True.

  • Select and hold the connecter point on the Decision block and drag it to the Screen Phone Numbers element.
  • A modal will appear with an Outcome option. Choose True.
  • Select Done.

The flow is now configured and ready to Save and Activate. Repeat this process for each object that needs the functionality enabling for.

Summary of the functionality

When inserting or updating a configured record in Salesforce, this flow will now queue a task to screen the record immediately. This functionality relies on Salesforce Future Methods. Due to this dependency the results may not always appear visible immediately after record insert or update and the page may need to be refreshed before the statuses update. It is still advised to rely on the automated batch job to pick up all overdue records on its nightly run.


Back to the PhoneTools installation walkthrough