For Salesforce organizations with Person Accounts enabled, there may be the need to populate data from the person account to other Salesforce records.

What’s a person account, you may ask? Let’s quickly get everyone up to speed…

By default, Salesforce accounts are business accounts. Business accounts store store information about companies or other entities. Person accounts are used to store information about individual consumers. Note: Person accounts must be enabled by Salesforce support by submitting a case for feature activation. So, once enabled, it cannot be disabled. Person accounts do not have contacts. For person accounts, Salesforce takes information you typically find on the contact record like first name and last name and is placed on the person account. Essentially, a person account is a combination of an account and contact record. For differences between person accounts and business accounts, see Person Account Behaviors. One thing to note, Lightning Experience currently does not work with Person Accounts.

The use case we’re covering here is to populating data from the person account in an address change case. This use case solved by clicks instead of code in Salesforce Classic. As noted above, person accounts currently do not work in Lightning Experience. (Safe Harbor: this is a Lightning Experience roadmap enhancement.)

Here are a few lessons learned from implementing this use case:

• Create a new record type to support different processes. You can assign a different page layout for each record type.
• The data for person account fields are stored in separate fields from those of the business accounts.
• Provide descriptions, where provided, in Salesforce. This may be tedious step, I know, but your future self will thank you when you are trying to remember what you configured or assist other/future admins when troubleshooting or enhancing what was built. This includes noting the data stored in a custom field, noting where a visual flow is invoked from, the purpose of a flow variable, etc.
• For any data actions (fast and record lookup, create, update and delete actions) performed in visual workflow, best practice is to include a flow element to send an email to your Salesforce administrator about the fault.

Flow trick: To getting the Fault connector to appear, either draw the regular connector link to another flow element or connect it to a temporary flow element. Draw the fault connector to the Send Email element. Then, go back and delete the regular connector.

Business Use Case: Addison Dogster is a system administrator at Universal Container. Sammy Sunshine is an Operations Manager who requested that a CSR be able to track address change cases in Salesforce. To minimize the data entry needed by the CSR, upon saving the address change case, the case should be populated with the mailing address on the user’s account record (In this case, the Salesforce organization is using person accounts.)

Solution: Being the Awesome Admin that she is, Addison was able to help Sammy through declarative actions. Addison considered using a formula on the case to reference the person account mailing address. However, she decided against it since they want the person account’s address at the time of the change address request, not the current address in the system when viewing the case information. Her solution involves the creation of 8 custom case fields, a case record type, a case page layout, process builder and a visual flow.

Quick Steps:

1. Create 8 custom fields (Customize | Cases | Fields), create the following new fields.

Data Type: Text

New Mailing Street	Previous Mailing Street
New Mailing City	Previous Mailing City
New Mailing State	Previous Mailing State
New Mailing Zip	Previous Mailing Zip

Best practice tips:

• Don’t forget to provide a description so you and other/future admins know what these fields are used for.
• Set the FLS (field level security) for each profile. Only make the field visible and editable for the profiles that need it. Do not just click the “Next” button when you are on the screen.
• Select only the page layouts that the new fields need to be added to. By fault, new fields are added to all page layouts.

2. Create a new case record type called Address Change (Customize | Cases | Record Types)

Best practice tip: Don’t forget to provide a description so you and other/future admins know what these fields are used for.

Note: Record types allow you to offer different business processes, picklist values, and page layouts to different users based on their profiles. In our case, the Operations Manager wants to have a case page layout for address change.

3. Create a new case page layout called Address Change (Customize | Cases | Page Layouts). Customize the page layout per your needs. Include a new section called Address Change with the 8 custom fields created earlier. Set the two column order to top down so when the CSR is entering the new address, they can tab from the street field to the city to the state and lastly, zip.

4. Create a visual workflow (Create | Workflows & Approvals | Flows). This flow to update the previous mailing address fields from the person account will be invoked from process builder to update a Salesforce record with the person account fields.

Salesforce Idea for Process Builder to work with Person Account Fields: https://success.salesforce.com/ideaView?id=08730000000DwHCAA0

A. We need to create variables that will be used in the visual workflow per the screenshots below.

Best practice tip: Don’t forget to provide a description so you and other/future admins know what these variables are used for.

varCaseID: The SFDC case ID will be passed from process builder. This will also be referenced to update the case record with the person account mailing address information.

varAccountID: The SFDC account ID will be pass from process builder. This will also be used to lookup the person account to pull/save the mailing address information into the mailing field variables.

B. Create a Record Lookup element of the Account object using the AccountID that will be passed in the varAccountID from Process Builder. Once found, it will take the person account mailing address information into the variables created for the person account mailing street, city, state and zip.

Best practice tip: Don’t forget to provide a description so you and other/future admins know what the record lookup is supposed to do.

Note: You can look up standard Person Account fields by typing “Person”

C. Make sure this flow element is “Set as Start Element.”

D. Create a Record Update flow element to update the Case where the ID matches the varCaseID that will be passed from the process builder. This will update the custom case fields created for the previous mailing address and update them with the values stored in the person account mailing address variables.

Best practice tip: Don’t forget to provide a description so you and other/future admins know what this record update flow will do.

E. As a best practice, where there is a DML action (fast or record create, update, delete or lookup action) in a flow, you should also include notification of a flow fault.

Note: To avoid “hardcoding” email addresses in a fault email, refer to a post Using Custom Metadata Type in Visual Workflow Fault Emails.

Select the Send Email flow element that is listed under Static Actions, not under Quick Actions.

Configure the body to show the fault message, subject and email address(es).

Body: Fault Message: {!$Flow.FaultMessage}

Subject: Error – Update Person Account Mailing Address

Best practice tip: Don’t forget to provide a description so you and other/future admins know what this send email element is supposed to do.

You will need to draw a connector line between the Record Update and Send Email elements.

Can’t seem to get the fault connector to appear? Create a temporary flow element (circled below), draw your first connector to that temporary flow element. Then, draw another connector to the send element. This connector has the word “FAULT” in it.  

Once that is completed, delete the temporary flow element you created. This is the end result.

F. Provide a name for your flow and ensure that the type is flow since this will be initiated via a button.

Best practice tip: Don’t forget to provide a description so you and other/future admins know what this visual flow is used for, where it is invoked from.

G. Click the “Close” button.

H. On the flows screen, activate the flow.

5. Create a process builder (Create | Workflows & Approvals | Process Builder). Click on the New button.

Best practice tip: Don’t forget to provide a description so you and other/future admins know what this process builder is used for.

A. Select the Case object and to start the process “only when a record is created” as we want to run this upon case record creation..

B. For the node criteria, provide the criteria name and set it to “No Criteria – just execute the action!”. Or, you can set this to only execute if the Record Type ID equals the 18 character SFDC ID of the Account Change record type.

C. In the Immediate Actions box, select to “Launch a Flow”, provide an action name, select the visual flow we created above. Set two flow variables.

• varCaseID reference [Case].Id
• varAccountID reference [Case].AccountId

Click the Save button.

D. Click the Activate button in the upper right hand corner. Click the “Ok” button.

That’s it. Congrats, you’ve implemented the solution!

Now, before you deploy the changes to Production, you need to test your configuration changes.

1. Login as a customer service rep and navigate to a person account.
2. Create a new case – select the Account Change case record type.
3. Provide the case information, leaving the previous mailing address fields blank. Save the record.
4. Upon save, confirm that the previous mailing address fields are updated with the person account’s mailing address.

Deployment Notes/Tips:

• The case custom fields, case record type, case page layout, visual flow and process builder can be deployed to Production in a change set.
• The field level security for the custom fields will need to be manually updated post deployment. I would caution against adding the related profiles in the changeset for deployment as the results of deploying a profile are not reliable. If you have a tool like Snapshot by Dreamfactory, you can use the tool to deploy field permissions.
• Activate the visual flow and process builder after they are deployed in Production as they are deployed as inactive.