Blog

Head in the Clouds: What are the Salesforce Clouds?

Salesforce has a huge variety of clouds (platforms built on Salesforce CRM) available to use, designed to serve different industries and business goals.

We know that knowledge is key when it comes to Salesforce, so with that in mind, here are the clouds we’ve explored and explained so far. In each post, we take a look at key terminology, business values of using that cloud and specifically what you can do with the functionality available to you!

Happy learning!

The Salesforce Clouds!

What cloud do you want to learn more about?

Want us to explore any more clouds? Why not send us a message or come join the conversation on LinkedIn!

About ProvenWorks

We mean it when we say we’re Salesforce experts. We work exclusively in the Salesforce ecosystem and our solutions are built 100% for Salesforce.

What is Salesforce Nonprofit Cloud and what can you do with it?

Nonprofits are by no means left out of the Salesforce ecosystem. As the title of this article says, we’ll be looking into Salesforce’s very own Nonprofit Cloud, a cloud designed and dedicated to optimising nonprofits’ internal and external operations.  

Stick around as we delve into the facts and functions of Nonprofit Cloud – you may just discover a new cloud to use or recommend!

What is Nonprofit Cloud? 

Nonprofit Cloud is one of Salesforce’s constituent management solutions, tailored for charity and nonprofit organisations. Nonprofit Cloud enables users to connect every function of their nonprofit organisation (including but not limited to fundraising, marketing, operations, grants and donations), and holds all this information in one central place – Salesforce!  

Within Nonprofit Cloud is the Nonprofit Success Pack (NPSP). This is a set of managed packages that sits on top of your Salesforce org and is preconfigured for the types of use cases that nonprofits organisations need. NPSP provides users with custom objects like ‘Donations, Households, Organization*, etc, everything specifically designed for nonprofits! 

How does Salesforce Nonprofit Cloud fit into the wider Salesforce ecosystem?

Salesforce Nonprofit Cloud was built with nonprofits in mind. However, this isn’t to suggest that nonprofits are in any way sidelined or prevented from scaling up with the full power of Salesforce. Since it’s built on the same world-leading platform, Nonprofit Cloud can work together with other clouds. For example, Marketing Cloud and Marketing Cloud Account Engagement (Pardot) can be added to Nonprofit Cloud to enhance its overall performance for effective donor engagement. 

So Nonprofit Cloud integrates with other Salesforce Clouds and provides access to other powerful resources too. Here are some of our favourite Cloud combos, functionality and resources that work well with Nonprofit Cloud: 

  • Salesforce.org – The social impact centre of Salesforce.com, focused on “partnering with the global community of nonprofits and schools to tackle the world’s biggest problems.”
  • Sales and Marketing Cloud– Nonprofit-compatible Salesforce Clouds that work to provide personalised marketing content and help you manage sales data.
  • The Power of Us Hub – the portal for Salesforce.org product documentation, how-to videos, webinars, and community groups of all kinds… and the place to get 10 free nonprofit licenses! 
  • Marketing Cloud Account Engagement (Pardot)– is a marketing software as a service (SaaS) marketing automation platform for Salesforce to empower marketing teams.  
  • Digital Experiences– an external, interactive platform that sits on top of your Salesforce CRM to enhance external user experience. Check out our blog on Experience Cloud for more information!

💡 Top tip: Using Nonprofit Cloud can increase Total Online Giving by 130% through its donor centricity!  

Why should you use Salesforce Nonprofit Cloud?

With Nonprofit Cloud, nonprofit organisations get a centralised constituent management hub for all their internal and external communication, interaction and monitoring. Onboarding and administration can also be centralised so donors receive a more personalised experience, plus, users can get a better overview of personnel management, such as volunteer data. Nonprofit Cloud is scalable, which means that you can grow your Salesforce implementation as your nonprofit organisation grows.  

For clarity, here are the main benefits of using Nonprofits Cloud: 

  • Scalable, customisable and centralised;  
  • Sustainable and secure;  
  • Global access for users; 
  • Easily adoptable and user friendly; 
  • Free licence opportunities from Salesforce; 
  • The Power of Us Hub, a support hub that is Nonprofit Cloud specific with communities and how-to videos.

Salesforce Nonprofit Cloud and ProvenWorks in action

How can ProvenWorks, a Salesforce ISV, work with Nonprofit Cloud? First off, we’d like to highlight that nonprofit organisations get a discounted price for any of our paid solutions that take their fancy! Secondly, we love (we really mean it!) working with nonprofits. We won the Salesforce Partner Innovation Award 2021 in the Nonprofit category for our work with Malala Fund

Our solutions work seamlessly with Nonprofit Cloud and empower you to: 

  • Import donor and recurring donations data easily; 
  • Verify address data from the point of entry;  
  • Ensure compliance for marketing calls to UK donors and partners.  

Manage and organise donor data with SimpleImport 

SimpleImport does what it says: it makes importing into Salesforce simple. Do you have volumes of donor data or recurring donations from external platforms that need centralising in Salesforce? SimpleImport and its intuitive Lightning component, ManagedImport, empowers you and your team to import this data quickly with a simple drag & drop. It’s quick to adopt and fast to use, so no vital time is lost from your nonprofit goals.  

Verify and authenticate address data at the point of entry with AddressTools   

AddressTools verifies your constituent address data to ensure only clean data lives in your org. Need a postal address format for donors, volunteers and partners? We’ve got you covered! Working with the UK Gift Aid process? AddressTools helps keep any manual updates within this process to an absolute minimum (<0.05%*) enabling efficient and timely processing of Gift Aid claims. 

Ensure compliance for marketing calls to UK donors with PhoneTools 

Cold calling donors or potential donors for your nonprofit? The UK has strict data privacy laws against cold calling, allowing UK residents to register to the Telephone Preference Service (TPS) and UK businesses to the Corporate Telephone Preference Service (CTPS). PhoneTools is a native Salesforce solution that screens your donor numbers against the TPS and CTPS lists to tell you directly if you can call that phone number. 

So what’s next? The choice is yours.

You can either go back to the first blog in our Head in the Clouds series: What is Experience Cloud and what can you do with it? Or… you can access all the blogs in the Head in the Clouds series.

The world is your oyster!

What is Salesforce Education Cloud and what can you do with it?

Education Cloud is a platform built on Salesforce CRM aimed at the education sector, including schools through to higher education institutions like universities and colleges. This cloud is aimed at keeping students, alumni and staff connected.

Our blog will take you through the key aspects of Education Cloud to provide you with more knowledge on what you can do with this Salesforce Cloud, and more importantly, to decide whether this is the right cloud for you. Let’s get started!

What is Education Cloud? 

According to Salesforce, Education Cloud is intended to ‘deliver the personalised engagements, proactive advice, and connected experiences students expect’. Education Cloud has a few extra benefits such as the Power of Us hub, K-12 focus, K-20 focus and Education Data Architecture. All of these features enable Education Cloud to better connect students, staff, schools, districts and universities, as well as give schools and universities a 360-degree holistic view of the education journey.   

Quick glossary:

We’ve mentioned a few key terms for this cloud already so welcome to the glossary! Here we’ll define some of the terms we mentioned above. 

Power of Us hub: A community support hub that helps Education Cloud users access 10 free subscriptions and find discounts on other subscriptions, products and services from Salesforce. 

K-12: Refers to the term given to the school years for children from Kindergarten to 12th grade in high school. However, in this respect it shows the type of institution this CRM platform is aimed at, with the ability to scale as the school grows. It also acts as a ‘single source of truth’ for each student and their family with all their data held in one place, making it easier to personalize interactions between school, student and the student’s family. 

K-20: Refers to the term given to the school years for children from Kindergarten right through to degree. This means that both K-12 and Higher Ed institutions can use Salesforce’s Education Data Architecture to create a connected holistic view of their students. For Higher Ed, this means giving universities a flexible way to ‘track dual enrolment, universal learner profiles and more’ with a focus on lifelong learning.  

Education Data Architecture: This is Salesforce’s flexible architecture that provides the foundation of Education Cloud. It’s designed for higher education institutions to get started with Salesforce faster by providing objects, logic and automation tailored towards student data, program enrolment, alumni, engagement and more. This trail on Trailhead is a great place to learn more!

What can you build with Salesforce Education Cloud?

Salesforce Education Cloud is a set of functionality built on the powerful Salesforce CRM platform. This means that when you’re using Education Cloud to manage your data, support your students and create an online community,  the world is your oyster! 

Here are some real-life examples of things you can do with Education Cloud to enhance your student and staff experience: 

  • Streamline student services on one platform to deliver unified experiences
  • Manage the entire admissions process
  • Provide external users with an interactive and beautiful looking interface for all your community interactions – think student registration portals! Check out our blog on Experience Cloud to learn more
  • Engage with prospective students, students and alumni with personalised marketing material to build lifelong relationships
  • Create beautiful reports and dashboards on recruitment and admissions data

💡 Top tip: Using Education Cloud can increase enrollment by 10%

Why should you use Salesforce Education Cloud?

With students and families now expecting a unified online journey, having a system in place that facilitates more time on education and personalising the student experience and less time on non-academic needs is vital.  

Since Education Cloud is student, teacher and family centric, it provides one single platform on which to manage and support the full learning experience, from admissions to alumni.  

Put simply, Education Cloud:  

  • Enables you to give students and their families, prospective students and staff applicants a personalised and centralised journey for an optimum experience;  
  • Gives you access to Power of Us hub – a support community network; 
  • Secures an internal and external communications hub; 
  • Enables you to access 10 free licenses and discounted services from Salesforce; 
  • Is scalable, customisable and compatible with other Salesforce Clouds, integrations and third-party vendors to help you deliver an exceptional education experience for students; 
  • Is built specifically for schools and universities. 

Salesforce Education Cloud and ProvenWorks in action

Education Cloud empowers the education industry with a world-leading single platform that adds great value to your institution. It creates endless new and improved opportunities for interactions between your students, alumni and staff.  

ProvenWorks offers solutions that work seamlessly with Education Cloud to:  

  • Open up import jobs to external users simply and securely 
  • Empower internal and external users to in put verified addresses at point of entry 

Open up importing jobs to your internal and external users safely

Regularly importing volumes of student-related data is time consuming, but it doesn’t have to be. SimpleImport empowers users and admins to quickly import files –  XLS, XLSX, ODS & CSV – into your Salesforce CRM. No more wasting time on manual administrative tasks.  

Empower users to provide verified address data from the point of entry 

Ensuring your mailed communication gets to the right individual is crucial. Incomplete address data contributes to a poor admissions or student experience and increases failed delivery costs! AddressTools empowers users to enter verified addresses at the point of entry, even on student registration portals. Our solution solves your address data concerns, so you remain focused on giving students and their families the best education journey possible.   

We’ve got more to come!

The next Salesforce Cloud we’re going to delve into is Nonprofit Cloud. Check it out now!

What is Salesforce Health Cloud and what can you do with it?

Salesforce recognises how vast and vital the healthcare sector is to everyone, and has established a cloud focused on this sector to improve patient and internal user experiences. 

In this blog we’ll look into what Health Cloud does and what you can gain from using it.

What is Health Cloud? 

Health Cloud is built on Service Cloud, one of Salesforce’s most popular offerings. Health Cloud is a set of functionality that allows patient liaisons and healthcare professionals to monitor, segment and prioritise patient data. This cloud partnership provides the healthcare sector with improved and personalised customer service, as well as, internally, showing healthcare professionals a 360-degree holistic view of their patients. These advantages are possible through features such as smart case management functionality, EHR-to-Salesforce API connections and secure record management. 

Now that we’ve covered an overview of Health Cloud, let’s define some of the key terminology!

Quick glossary:

Service Cloud: The key Salesforce Cloud that Health Cloud is built on. It enables users to create a tailored and personal customer experience, to ‘increase satisfaction, retention, and lifetime value’. Want to learn more about Service Cloud, check out Trailhead’s Service Cloud Basics module!

Smart case management: According to Salesforce: A case management system lets a company collect and organize customer service interactions that occur on any channel.” What makes it smart? “Modern case management platforms pull customer requests into a database, where customer service agents can view and respond to them…” 

EHR-to-Salesforce API connections:  An add-on API Salesforce extension specifically for Health Cloud. These connections enable your Salesforce CRM to receive and translate EHR, and other sources of medical data, for patient records. 

What can you build with Salesforce Health Cloud?

Salesforce Health Cloud is a set of functionality built on the Salesforce CRM platform. This means that when you’re using Health Cloud to communicate patient needs, collaborate with other healthcare professionals and track and monitor patient progress, everything is in one place!

Popular examples of things you can do with Health Cloud:

  • Care plan tracking
  • Patient marketing campaigns 
  • Patient acquisition and monitoring
  • Medical professional recruitment 
  • Patient outreach and engagement management

💡 Top tip: Trailhead has some handy modules for you to learn more about Health Cloud so you can Deliver Great Patient Care with Health Cloud.

Why should you use Salesforce Health Cloud?

With Health Cloud, you can access the right health information about patients from a range of sources, including EHR systems and wearables. Healthcare professionals can prioritise tasks and segment patient lists, provide real-time and collaborative messaging for providers, patients, family members, and care teams. All this enables patients to receive the best and most personalised care possible.

Health Cloud is native to Salesforce, so there is no requirement to switch between solutions which can lose you time or worse, cause confusion in interpreting and working with siloed data.

Put simply, Health Cloud allows you to: 

  • Remain on Salesforce – everything you need is in one place!
  • Personalise patient services
  • Receive and manage all medical data records and contacts in one, central and secure system
  • Engage with health liaison officers, patients and more using community hubs
  • Tailor, configure and scale your cloud as you grow 

Salesforce Health Cloud and ProvenWorks in action

As a set of functionality, Health Cloud adds tremendous value to your healthcare practice by creating endless new and improved opportunities for you to interact with your patients and partner healthcare providers. 

ProvenWorks offers solutions that work seamlessly in Health Cloud to:

  • Empower internal and external users to provide verified addresses at the point of entry
  • Open up import jobs to partners simply and securely

Import data into Health Cloud efficiently

Is data importing a pain point impacting your and your patients’ experience? SimpleImport enables simple and secure importing into Salesforce without losing precious time for patients or healthcare professionals. 

Empower internal and external users to provide verified addresses

Managing patient information and keeping records clean with up-to-date data is essential for the healthcare industry. AddressTools ensures all address data is verified from the point of entry. AddressTools solves your address data concerns, while you focus on treating your patients.

So what’s next? We’ve got more Clouds for you.

The next Salesforce Cloud we’re going to explore is Education Cloud. Check it out now!

What is Salesforce Experience Cloud and what can you do with it?

You might hear people talk about “Community Cloud”…
You might be wondering how a Digital Experience is different to Salesforce Experience Cloud…
Or you might be asking yourself where a partner portal fits into all of this…

Don’t worry, we’ve got you covered in this article!

What is Salesforce Experience Cloud?

Salesforce Experience Cloud is a set of functionality built on the Salesforce Customer Relationship Management (CRM) platform. Experience Cloud enables you to build beautifully-branded “digital experiences” that are connected to your CRM with a key focus on engaging customers and empowering partners. You can use Experience Cloud to create multiple sites and experiences within your Salesforce org to address different purposes.

We’ve already thrown in a few tricky words so why don’t we take a quick pause to define some key terms.

Quick glossary:

Salesforce CRM platform: More than a database, this powerful software is your single source of truth for managing your customer relationships. It’s for you and your business.

Salesforce Experience Cloud:  Formerly known as “Community Cloud”, it’s a set of functionality to deliver external-facing digital experiences (see below) that sit on top of your CRM. It’s for you, your business and your external stakeholders.

Salesforce Community Cloud: The old name for Salesforce Experience Cloud.

Digital Experience: The external-facing ‘site’ you can build with Salesforce Experience Cloud.

Site: Another name for a Digital Experience instance.

Partner portal: One example of a Digital Experience.

Help forum: Another example of a Digital Experience.

DXP: You might see Experience Cloud referred to by this acronym; it is Salesforce’s digital experience platform (DXP).

With those definitions in mind, Salesforce’s online learning platform, Trailhead describes digital experiences and Experience Cloud:

“A digital experience built using Experience Cloud provides a window into your Salesforce world.”

 From Get Started with Experience Cloud

So hopefully we’ve cleared up some terms and their definitions. Now let’s investigate what this means in reality!

What can you build using Experience Cloud?

Salesforce Experience Cloud is a set of functionality built on the powerful Salesforce CRM platform. This means that when you’re using Experience Cloud to build a digital experience, the world is your oyster!

You can create a digital experience for any situation where you want to present a beautiful external-facing interaction with your Salesforce CRM.

Popular examples include:

  • Partner portal
  • Account portal
  • Storefronts
  • Microsites
  • Industry solutions
  • Customer service hub
  • Help centres
  • Support site
  • Mobile app

💡 Top tip: Salesforce has created Lightning Bolts. These are pre-built industry-specific Digital Experience templates (amongst other things!) created to help you go to market quicker.

Why should you use Experience Cloud?

With Experience Cloud, you’re giving stakeholders what they need. Not only this, but you’re doing this completely integrated with your CRM. This means you’re maintaining and cultivating a single source of truth with an even bigger picture of your business, your customers and your partners.

We keep repeating that it’s built on the Salesforce platform… but that’s because it’s important! By building on the Salesforce platform, you’re building your partner portal or support forum on world-leading software that is scalable, secure, customizable and centralized.

A few more perks to consider at a glance:

  • Go to market fast with industry-specific customizable themes
  • Create multiple experiences for specific needs
  • Design for every device since all digital experiences are 100% mobile optimized and fully responsive

Partner users cannot import data to Salesforce in a digital experience

Standard Salesforce does not allow users to import data in a digital experience.

We’ve seen that Salesforce themselves describe Digital Experiences as a “window” into your Salesforce world.

However, many businesses and organisations need more than a window; they need a door.

Salesforce Digital Experiences (Communities) built on Experience Cloud have been growing in popularity. It’s easy to see why they’re so popular, since digital experiences can be used in so many contexts: partner portals, e-commerce sites, help centres and even franchisee hubs.

With so many different digital experience audiences come lots of reasons why users need to import data.

It’s worth bearing in mind that standard Salesforce does not allow digital experience users to import data.

Experience Cloud and ProvenWorks in action

In case you can’t tell, we love Salesforce Experience Cloud. As a set of functionality, it adds tremendous value to your business by creating endless new opportunities for you to interact with your stakeholders.

However we’re not just fans of Experience Cloud; as a team of Salesforce experts who create data management solutions to save you time, we see the powerful potential of Digital Experiences.

We’ve created solutions that work seamlessly on Digital Experiences to:

  • Open up import jobs to partners and business users simply and securely
  • Empower external users to provide verified addresses at the point of entry

Empower external users to import safely and simply via a digital experience

Think partner deal registrations or subsidiary sales information. Safely empower users to import data into your Salesforce through preconfigured mappings using our two-step drag and drop wizard – introducing the ManagedImport component.

Reduce cart abandonment and improve user registration with fast address verification

Think user registration portals and ecommerce checkouts. Create powerful user experiences with our Address Verification Flow Component that verifies address data at the point of entry in 5 key strokes or less.

So what’s next? We’ve only just begun!

The next Salesforce Cloud on our adventure will be Health Cloud. Stick around and learn something new!

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.

How to handle sanctioned states within Salesforce

As of February 2022, US companies must adhere to imposed restrictions on economic relations with the non-government controlled areas of the Donetsk and Luhansk oblasts in eastern Ukraine. AddressTools Premium customers can quickly and automatically identify Leads, Accounts and Opportunities in Salesforce that should be flagged in relation to the executive order.

The AddressTools ‘State’ object is pre-populated with Ukrainian province (oblast) values. The package ensures that all addresses in these regions use a standard state value for reporting purposes.

A custom checkbox field can be added to the State object to flag “Sanctioned Regions”. Using the package’s built-in trigger, a formula field can be populated on records in these regions. Any new record created in these regions would be automatically flagged.

Before getting started

This guide assumes that you are leveraging the Lookup Field Population functionality available in AddressTools Premium. To find out about the Lookup Field Population functionality please refer to the relevant section in the Installation Walkthrough.

These instructions will demonstrate displaying whether the Account Billing Address exists within a sanctioned region. The steps can be replicated across any address block configured with AddressTools.

When you’re ready to proceed, continue through the guide using the steps below.

Step by step guide

Create a Sanctioned Region checkbox on the State object

First create a checkbox field on the AddressTools State object and name it Sanctioned Region. This field will be used to flag regions under sanction.

Add this field to the State object’s page layout in order to maintain the value with ease.

With the field created, relevant regions can be set to TRUE by navigating to the State record via the parent Country in Salesforce. For example, navigate to Countries then select Ukraine. Finally click Related and find the impacted state in the list.

Create a formula field to display the Sanctioned Region value on an Account

To display the Sanctioned Region value on a record where the address exists, we’ll use a formula field to reference the associated State record.

Create a Formula field on the object where the address exists. We’ll choose Account for this example. When choosing the Formula Return Type, choose Checkbox and name the field Sanctioned Region.

Use the Advanced Formula tool to insert the custom Sanctioned Region field located on the related State object (this is where the Lookup Field Population functionality comes in).

Save the field and optionally add it to your page layout for quick referencing.

Save and test

When we save a new Account, the Billing State Lookup field populates on save using AddressTools’ Lookup Field Population functionality. When viewing the saved record the formula field will traverse the lookup and present the Sanctioned Region value on the Account.


Get in touch

If you have any questions or concerns about handling sanctioned states in your Salesforce org, please don’t hesitate to get in touch with us.

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.

When is a Salesforce Field no longer useful?

One of the many advantages of CRM systems is that it is very easy for business users to add additional fields. One of the main disadvantages of CRM systems is that it is very easy for business users to add fields without giving thought to the ‘bigger picture’.

In this blog post we will discuss our approach for determining when to remove fields from the system.

TLDR: The basic principal is that when a field is no longer trustworthy, is there any point in keeping it in your production system?

Can we trust this field?

A field is untrustworthy if you (and anyone else) cannot find a consistent process for populating or maintaining that field despite reasonable efforts to do so.

Let’s take an example of an Account field that says “Number of employees at this location” and some of the questions we’d ask to determine how much we trust it:

1. Who collects/populates it?

Is it the Sales Rep? Is it the marketing department? Is it from a third party data provider?
– Don’t know and can’t find out? Back it up and delete it!

2. When is it collected?

At time of record creation? When the Account becomes a customer? When there’s an opportunity?
– Nobody knows? Remove it.

3. When was it first ‘put into production’?

This is vital if we are doing any kind of historical analysis.
– If the field is only there for trend analysis and the data appears patchy then it’s useless.

4. When was it last updated?

What’s the worst case?
– No historical value? Lose it.

5. Do we actually understand what the field means?

Is it unambiguous?
– If no one can understand what the field means, it’s useless.

Do we understand what the field means?

If you’re interested in a deep dive on field naming, see our previous post on field naming conventions.

In short, what we must do is look at the field name/label and determine if the question used to populate the field is at all ambiguous.

Even if the IT/IS/Sales Ops department understands the meaning of the field, do the people who are actually populating it? What about users who primarily speak different languages?

We work with a number of organizations and see lots of different field naming conventions. An example of an ambiguous field we saw recently was on an account that simply said “MSP Customer”. MSP means Managed Service Provider. Due to the client’s channel sales model, it was not clear if this field meant the account was a “Managed Service Provider” themselves or if this account was effectively an indirect customer since they purchased through a Managed Service Provider.

If we cannot understand what the field means, we cannot fulfil its purpose. Ultimately this not only wastes time but can also lead to inaccurate reporting, misinterpretation and misinformed business decisions.

What is the purpose of having a field anyway?

Let’s finish up by reminding ourselves of the basics. We believe there are two key purposes for having a field in a CRM:

  1. To mark a record as being at a certain stage in a process and/or
  2. To record data for later analysis (reporting).

If a given field is not adding any value to a current business process and it has no historical value for the reasons listed above, back it up and delete it before someone makes a business decision based on its content!

About ProvenWorks

We mean it when we say we’re Salesforce experts. We work exclusively in the Salesforce ecosystem and our products are built 100% for Salesforce.

Field naming convention for Salesforce and database tables

Joel Mansford is the Founder and Managing Director of ProvenWorks. With many years experience working within Sales & Marketing building databases, reports and customising CRM systems, he considers himself a techie at heart.

In this blog I’ll take you through a variation of a field naming convention for Salesforce that we use at ProvenWorks and recommend for use within Salesforce systems. To be clear we’re talking about the API name (or underlying table names) and not the labels that are exposed to users.

I want to stress that the most important thing is to have a field naming convention; what that convention actually is is of secondary importance. You will know that you have a good convention when you get the field/API name correct >90% of the time without actually knowing the table well simply because you know how it would have been named by its purpose.

Name your fields

If you’re reading this then you’ve probably already determined that you need to think about the naming convention of your fields. On a new field creation, Salesforce first asks for the label. It then creates an API name based on this label. This means you can get:

Label=”Last 2 letters of Mother’s maiden Name”,

API name = “Last_2_Letters_of_Mother_s_maiden_Name__c”

Note that the spaces and apostrophe all become underscores, making the ‘s’ stand on its own and the API name overly long (those underscores aren’t helping us at all). Also if the label changes (e.g. “2”->”two”) then confusion ensues because developers using this ‘convention’ will always assume that the API name matches the label.

Naming conventions

Field names should use Upper Camel Case or Pascal casing. Here’s an excerpt from http://en.wikipedia.org/wiki/CamelCase:

“CamelCase (also spelled “camel case” and sometimes known as medial capitals[1]) is the practice of writing compound words or phrases in which the words are joined without spaces and are capitalized within the compound — as in LaBelle, BackColor , or iMac. The name comes from the uppercase “bumps” in the middle of the compound word, suggestive of the humps.”

Try to avoid using abbreviations unless they are very widely used i.e. Id is fine instead of Identifier, Pro_Serve is not a good abbreviation of Professional Services as it is not consistent in its number of characters for each word and “Serve” is not a known abbreviation of “Services”. We’ll get onto verbosity in naming later.

Acronyms are treated as if they were words, so SFDC Account Id would become SfdcAccountId – whilst this one isn’t intuitive it is necessary to properly separate the words out correctly. If SFDC were treated as all capitals, many tools would (like SSRS) convert it to “S F D C Account Id” which is ‘more’ wrong. In this example, “SalesforceAccountId” would be best.

Grouping

The underscore (_) character can be used after a field prefix to logically group fields together, for example:

  • Software_Amount becomes Amount_Software
  • Maintenance_Amount becomes Amount_Maintenance
  • Training_Amount becomes Amount_Training

This grouping means that when fields are sorted alphabetically, logically-related fields appear together – very useful in implementations with >150 fields! Grouping is easily achieved by slight word re-arrangement. For example, although we would usually verbally say “Date Created” here we name the field CreatedDate.

Grouping (underscore) isn’t absolutely necessary for field ‘pairs’ for example CreatedBy and CreatedDate or Contact.AccountId and Contact.AccountType (as the two fields will always be populated together). However, if you anticipate other fields being added to this theme then grouping can be beneficial and makes reviewing the column/field list much easier.

Choice of words & verbosity

This blog only outlines the conventions for naming. The actual choice of words is a task best proposed by one individual and then reviewed by others to ensure that the words are a good reflection of the purpose of the field without extra clarification. It is very rare that an individual gets the field naming right alone. Bounce the ideas and then finally make sure the actual text is reviewed for typos(!).

However great the temptation to “quickly create a field”, you should always resist. Spending literally a few minutes carefully considering the naming will at a minimum save you time later and more importantly prevent a field being misinterpreted and thus wrong business decisions being made.

Remember it is better to be unambiguous and have a long field name than a short field name that is open to interpretation. If a developer complains that it takes too long for them to type a long field name then I’d suggest they’re in the wrong profession if they struggle typing a dozen extra characters.

About ProvenWorks

We mean it when we say we’re Salesforce experts. We work exclusively in the Salesforce ecosystem and our products are built 100% for Salesforce.