Data Validation Superbadge Unit

Prework and Notes

Sign Up for a Developer Edition Org with Special Configuration

To complete this superbadge unit, you need a special Developer Edition org that contains special configuration and sample data. Note that this Developer Edition org is designed to work with the challenges in this superbadge unit.

1. Sign up for a free Developer Edition org with special configuration.

2. Fill out the form. For Email address, enter an active email address.

3. After you fill out the form, click Sign me up.

4. When you receive the activation email (this might take a few minutes), open it and click Verify Account.

5. Complete your registration by setting your password and challenge question. Tip: Save your username, password, and login URL in a secure place—such as a password manager—for easy access later.

6. You are logged in to your superbadge Developer Edition org.

Now, connect your new Developer Edition org to Trailhead.

1. Make sure you’re logged in to your Trailhead account.

2. In the Challenge section at the bottom of this page, select Connect Org from the picklist.

3. On the login screen, enter the username and password for the Developer Edition org you just set up.

4. On the Allow Access? page, click Allow.

5. On the Want to connect this org for hands-on challenges? page, click Yes! Save it. You are redirected back to the Challenge page and ready to use your new Developer Edition org to earn this superbadge.

6. Now that you have a Salesforce org with special configuration for this superbadge unit, you’re good to go.

Tips

• Some of the terminology used in this superbadge is descriptive and may not match the name as it appears in the user interface (UI). This is to test your knowledge of Salesforce features and ability to select the correct feature to satisfy a business need.
• Where possible, solutions will be evaluated based on the expected outcome instead of specific formula syntax. We recommend using sample data to test and validate your activated solutions.
• All solutions in this superbadge unit must be built with declarative, out-of-the-box functionality.
• Descriptions must be set for all data validation solutions in order to pass the challenges.

Use Case

The fashion company Rambunctious Armadillo Socks (RAS) is a large retailer with more than 1,000 employees (who knew armadillo socks were in such high demand!). RAS has a large volume of leads, opportunities, and accounts in its Salesforce database and the organization has been experiencing a number of problems with its data. Leads are created with duplicate information, opportunities have been lost due to inaccurate data, and customers are becoming frustrated with the customer service experience.

As a Salesforce admin at RAS, you’ve been asked to use out-of-the-box functionality to improve data quality and enforce data standards for the highest priority records: accounts, contacts, leads, and opportunities.

Business Requirements

This section represents the requirements for RAS’s data validation needs.

Enforce Customer ID Format

Each account RAS works with has a unique customer ID tracked within a custom field, Customer_ID__c, on the Account object. In order to sync with customer data in other systems, it’s important that the customer ID listed here follows a specific format. Some accounts will not have a customer ID populated; your solution must only enforce the format described in this section if data is entered in the field.

The customer ID should include the 2-character billing country code, a dash, and an 8-digit number (for example, US-12345678). Each customer ID must be exactly 11 characters in length with zero spaces. Use the information provided below to show a relevant error to the user if the data entered doesn’t follow the expected format.

Billing Country Code: The 2-character billing country code is based on the country listed in the account’s standard billing address field. Here are several items to consider when building your solution.

• Your special org has state and country/territory picklists enabled.
• Billing Country is configured as a required field using the Billing_Country_Is_Required_Field validation rule in your special org.
• Billing_Country_Code__c is a custom formula field used to display the standard BillingCountryCode portion of the compound BillingAddress field in the UI. This field is intended to help end users quickly find the correct country code.

The customer ID will typically come from an external system but there are occasions when a user may need to enter the value manually. Your solution should enforce the format described above no matter where the data originates.

Create and activate a solution with the name Customer_ID_Format to meet the requirements described in this section. Use the error message information below.

Error Message	Location
Oh snap! Make sure the format is 'XX-NNNNNNNN' where X is the 2-character billing country code and N is an 8-digit number.	Next to the Customer ID field

Note: You will not need to adjust any field settings for Customer_ID__c in order to pass this challenge.

Validate Opportunity Data

Verified Accounts

In recent quarters, RAS has had a number of deals fall through even after a sales contract was signed and the related opportunity was marked as Closed Won. We’ll spare you the details, but the RAS legal department has asked that you prevent opportunities from being Closed Won unless the account associated with the deal is verified by their team.

Use the existing Verified__c checkbox field on the Account object to create an active validation solution with the name Verified_Account_for_Closed_Won_Opp. Make sure the user sees a relevant error explaining why they can’t update the opportunity.

Error Message	Location
Oh snap! Opportunities can only be marked as "Closed Won" for verified accounts.	Top of the opportunity record

Reopen Closed Opportunities

On a related topic, it has also come to the attention of leadership that some opportunities have been reopened after being Closed Won or Closed Lost. While there are legitimate reasons an opportunity may need to be reopened, only a subset of users should be allowed to do so.

Mustafa Haider, the director of direct sales at RAS, is the only user in your special org that’s allowed to reopen closed opportunities. In contrast, Maham Hoss and the system administrator (that’s you!) should be prevented from reopening them and should see a relevant error message.

Create a solution with the name Limit_Access_to_Reopen_Closed_Opp that will allow a user with the Executive Access to Reopen Closed Opportunities permission set to reopen a closed opportunity and prevent all other users from doing so. This permission set already exists in your special org and has been fully configured to work with your solution. You won’t need to update the permission set but you’ll need specific information from it to include in your solution.

Error Message	Location
We hit a snag! Reopening a closed opportunity is not allowed.	Top of the opportunity record

Identify and Resolve Duplicate Leads

The sales team at RAS has come across a large number of duplicate leads in the Salesforce org. Duplicate lead data has led to some awkward customer conversations and frustration among sales team members. But have no fear, the #AwesomeAdmin is here!

Lead data comes from several sources such as web-to-lead, email-to-lead, and other pipeline generation activities. RAS leadership recognizes the potential value of all leads, no matter the source or quality. For that reason, you’ve been asked to build a solution to help identify and monitor potential duplicate leads without blocking incoming data.

Build a matching solution with the name Match Leads based on Email, Company, and Website and unique name Match_Leads_based_on_Email_Company_and_Website that meets all of the following criteria to identify potential lead duplicates.

1. Company Name: Leads should be identified based on an approximate match for company name.
2. Website: Leads should be flagged if separate records have identical websites listed.
3. Email: Lead records that have the same email address should be included as potential matches.
4. Blank Fields: For the criteria above, blank fields should not be treated as matches.

Then, configure and activate a solution named Duplicate Lead based on Email, Company, and Website that will identify potential duplicates based on the criteria above. This solution should not prevent potential duplicate records from being created. Instead, it should alert the user that the created or updated lead may be a duplicate, and it should flag the potential duplicates to be included in the existing Duplicate Leads Report. Regardless of record visibility, this solution should detect duplicate leads and display the alert message, "We're sorry, but the lead you're attempting to submit is a duplicate entry in our system."

While testing this solution, you realized the duplicate solution was preventing your web-to-lead solution from creating leads. As a team, you decided to add the custom 'Allow Duplicate Records' checkbox to the user record to allow the Web-to-Lead integration user to skip this solution. Update your solution so that it won't run for any user with the 'Allow Duplicate Records' box checked.

Finally, use the Duplicate Leads Report to identify and merge all of the duplicate lead records that came in your special org. Note: You don't need to merge any duplicate records you create for testing purposes.

Prevent Duplicate Contact Records

Duplicate contact data is another pain point for the RAS sales team. Account executives regularly come across duplicate contact records with disparate data, and it’s unclear which record has the most accurate or up-to-date information.

You’ve been asked to build a solution to prevent duplicate contact records from entering the Salesforce org. Build a matching solution with the name Match Contacts based on Name, Email, and Role and unique name Match_Contacts_based_on_Name_Email_and_Role. This solution should identify potential duplicates if all of the following criteria are met.

1. First Name: Contacts should be flagged with an approximate match on the first name.
2. Last Name: Contacts with identical last names should be considered.
3. Email: Contact records with the same email address should be included as potential matches.
4. Role: Contacts with identical roles should be addressed in this solution.
5. Blank Fields: For the criteria above, blank fields should not be treated as matches.

Finally, create and activate a solution named Duplicate Contact based on Name, Email, and Role that will prevent contact records from being created if the matching criteria above is true. This solution shouldn't prevent users from editing potential duplicates; instead it should warn them about the potential duplicate and add the contact to a report. Regardless of record visibility, this solution should prevent duplicate contacts and display the alert message, "We're sorry, but the contact you're attempting to create is a duplicate entry."