In this blog post, weâre going to show you how to create a Salesforce-integrated FormAssembly form to automate the process of enrolling external customers to your Salesforce Community.
This FormAssembly use case allows more controlled automation of the creation and provisioning of community licenses, and lets you fully custom brand the enrollment form and publish it anywhere as opposed to Salesforceâs self-enrollment that takes place only on the community login page.
Using this method, you could engage with new and existing customers through a portal that provides them all account information, manage partner relationships by allowing partners to automatically add new hires or employees to the Salesforce Community, and create a helpdesk-type platform. See how our customer California Quivers is using FormAssembly with Communities here.
Keep reading for a step-by-step explanation of how to execute this in your FormAssembly account.
Form Setup
To implement this use case, the first thing youâll want to do, of course, is set up your form.
For this example, Iâll use just required fields and some basic information – First Name, Last Name, Phone, and Email on the Contact record. For the Account information, this will all be prefilled, which weâll get to in a little bit.
One of the best FormAssembly tricks is using a hidden field for Object IDs. Here, since we know that the Account will already exist in Salesforce, I have added a hidden field for the Account ID so itâs easy to reference when weâre mapping the connectors.
Now that we have all the data points, letâs move on to mapping the connectors.
Connector Setup
First, letâs add both the Prefill and Submit Salesforce connectors to our form.
Once we have those in place, weâll map the Prefill connector then the Submit connector.
Prefill Connector Setup
For this example, weâre only going to prefill against an existing Account — any Contact can use this form to enroll. The mapping I have here can be expanded to prefill any Salesforce record, so we could use this form for Contact-specific Communities enrollment.
Submit Connector Setup
The submit connector is where most of the work will be done.
The first thing weâll want to do is perform a Lookup on the Account record so that we can dynamically assign it to the Contact that is updated or created. Thankfully, with the hidden field that we prefilled, this is pretty simple:
Moving on, weâll want to Update a Contact in Salesforce. This Update function will allow us to optionally Create the Contact record if he or she does not exist already. To make sure we catch all cases, weâll want to map âIF NO MATCHâ to âCreate a new record insteadâ.
The lookup parameters Iâve set up are Email, First Name, and Last Name, but these can be configured to match whichever parameters your org uses for deduplication.
Then, simply map in the fields from the form to Salesforce. Youâll notice that I am dynamically assigning this Contact to the Account we found in step 1. This is done by mapping the Account ID field to âthe ID of an object aboveâ and selecting â1. Accountâ:
Now that we have the Contact record updated or created, we can assign them to the Customer Community. To do so, weâll want to Create a User:
Creating this User object is admittedly a bit fickle — Salesforce likes to push through a ton of fields when you first select the object. The fields above are the only ones you need to map, as there are a good bit of system defaults that will auto-populate on the Salesforce side.
A few fields to point out as extra-important:
- Profile ID: This will be mapped as âformula or textâ to the Salesforce ID of the profile that you want to assign. For my demo, I chose Customer Community User.
- Alias: For this field, Iâm using their first initial and first 4 letters of their last name. This is done with a quick @CONCATENATE function in the FormAssembly field editor.
- Time Zone: This gave me trouble for the longest time. Youâll need to map in the TIMEZONESIDKEY (a list of all of them is provided by our friend Salesforce Ben here) as a formula or text.
- Locale and Language: Again youâll need to use the Salesforce local code (full list here) as a formula or text
- Email Encoding: The last âcodeâ required field, has the following options: UTF-8, ISO-8859-1, Shift_JIS, ISO-2022-JP, EUC-JP, ks_c_5601-1987, Big5, GB2312 — all mapped in FormAssembly as formula or text. UTF-8 will capture all possible unicode characters, so I went with that as the default across all users.
Test Response
Now letâs test it! If everything goes according to plan, we should be assigning users in no time. To begin, letâs load our prefilled form with a URL parameter:
And then fill in some test (or live) data:
And submit! Nothing else needed to push the data through.
Check the Logs
Now that weâve submitted, letâs make sure everything ran properly by having a look at the logs (this will also expose the Salesforce IDs, easily allowing us to navigate to the proper records). In this case, Michael Jones already existed in our org, so we simply updated his record without creating duplicates!
Looks like everything processed properly, so letâs take a look at the impact in Salesforce.
View Salesforce Records
Again, from the logs we can find the Salesforce record IDs, so letâs have a look at the Contact that we updated:
And the associated User record:
And, finally, the User detail to make sure everything set up properly:
You can see in this screenshot that we mapped the proper profile (Salesforce will automatically match the User License, thankfully!). The User is marked Active, is a Customer Portal User, and has all the proper code fields mapped properly.
Now we have total self-service portal enrollment! You can publish the form on an intranet, public-facing page?, or send out invite emails, however youâve structured and pitched the Salesforce Community value.
Donât have a FormAssembly account?