Setting up a customer portal in Salesforce Experience Cloud allows your external customers to securely access FieldKo data (such as Visits, Tasks, and Surveys) in real time. Using Salesforce’s standard Experience Cloud functionality, you can create a branded site where customers can log in to view and update relevant records.
This guide walks you through creating a customer portal using Customer Community or Customer Community Plus licences (external user licences), covering how to enable Experience Cloud, configure customer accounts and users, assign permissions, and control data access. We focus on out-of-the-box Salesforce features to ensure a secure, maintainable solution.
Enable Experience Cloud and Create a Site
Enable Experience Cloud: In Salesforce Setup, search for Digital Experiences (formerly Communities). Go to Settings and tick Enable Digital Experiences. You'll be prompted to choose a domain name for your Experience Cloud site (this becomes part of your portal URL, and it cannot be changed later). For example, you might use
yourcompany.force.comas the domain.Create a New Experience Cloud Site: Once enabled, click New to create your first site. Select a template that fits a customer self-service portal (e.g. Customer Account Portal or Customer Service template). Give your site a name (e.g. FieldKo Customer Portal), a URL (e.g. /customers), and create it. Salesforce will provision the site with default pages.
Add Members (Profiles) to the Site: After creation, navigate to Administration > Members in the Experience Cloud Workspace or Experience Builder settings. Add the profile(s) or permission set(s) that your external customer users will use, so they gain access to the site. For example, include the Customer Community User profile if using Customer Community licences, or a custom profile for Customer Community Plus users. Only users with those profiles/permission sets will be able to log in to this site.
Publish the Site: Initially, your site is in preview mode (visible only to admins). When you’re ready for customers to use it, activate or publish the site from the Experience Builder or Experience Workspaces. You can also set the site to Active under Administration > Settings. This makes the portal accessible at the chosen URL.
Set Up Customer Accounts and Contacts
To grant portal access, your external customers must exist as Account and Contact records in Salesforce (each community user is tied to a Contact on an Account):
Create Accounts for Customers: Ensure each company or individual customer is represented by an Account record in Salesforce. For business-to-business scenarios, you might have one Account per customer organisation. For direct consumers, you might use one Account as a placeholder (like “Individual Customers”) or Salesforce’s Person Accounts if enabled (though Person Accounts are typically supported with Customer Community Plus).
Create Contacts for Portal Users: Under each Account, create Contact records for the individuals who need portal access. For example, if you have a client company "ABC Corp" (Account) and two people at ABC Corp who will use the portal, create two Contacts under ABC Corp.
Tip: The Account owner (internal user) should have a role in Salesforce (any role in the role hierarchy) before enabling contacts as users. This is required by Salesforce for external user sharing and security model.
Enable Contacts as Community Users
Once the contacts are in place, convert them to community users:
Open Contact Detail: Go to the Contact record for a person who will be a portal user. Ensure the contact has a valid email address and is associated with the correct Account.
Enable Customer User: Click the Enable Customer User action. (In Lightning Experience, this is in the dropdown on the contact’s record page. In Classic, it’s under the Manage External User button).
Fill User Details: A user creation screen appears. Fill in the new user’s details:
Username: Must be in email format and unique across all Salesforce orgs (e.g.
[email protected]). Often, using their email as username is convenient.Alias and Nickname: These auto-fill, but you can adjust if needed.
Email: It will default to the Contact’s email – ensure it’s correct, as login info will be sent here.
User Licence: Select Customer Community or Customer Community Plus depending on which licence you purchased for this user.
Profile: Select the profile for this user (e.g. Customer Community User profile, or a cloned custom profile with appropriate permissions for FieldKo objects). The profile is tied to the licence type (only profiles compatible with the chosen licence will be available).
Do not check "Generate new password" yet if you plan to set up multiple things first – you can reset passwords in bulk later. Otherwise, leave it checked to email the user a login link.
Save: Click Save to create the external user. Salesforce will create a user record linked to the contact. You now have an active portal user. Repeat this for each contact that needs portal access.
Note: For Customer Community Plus, when you enable the first external user for an Account, Salesforce will automatically create a role for that account in the background (e.g. a role like Account Name Partner/User/Executive, even for customer licences). This puts the external user into an external role hierarchy. You don’t need to manually create roles – it’s handled by Salesforce. Customer Community (the basic licence) users do not get individual roles (they are high-volume users).
Assign Permission Sets for FieldKo Data Access
By default, the profile for external users may have limited access. To allow your portal users to work with FieldKo objects (Visits, Tasks, Surveys), you should grant proper permissions:
Create a Permission Set: Create a permission set (or permission set group) that includes access to the FieldKo custom objects and fields. For example, a “FieldKo Customer Access” permission set could grant Read access to Visits, Tasks, and Surveys, and Create/Edit permissions if you want customers to log new information or update records. Also include any necessary field-level security (FLS) so they can see and edit the relevant fields on those objects.
Assign to Users: Assign this permission set to each external user (or better, use a permission set group or profile if managing many users). This layered approach (profile + permission set) allows you to keep the profile basic and use permission sets for specific object access, which is easier to maintain. For example, give all external users a base profile, and then use permission sets to grant FieldKo-specific permissions.
Ensure the Tabs or navigation for these objects are also enabled for the profile or permission set. In Experience Cloud, you might expose the data via custom pages instead of Salesforce Tabs, but having tab visibility set to “Default On” or “Available” for those objects in the profile helps if you use standard navigation menus.
Configure Data Sharing and Access Control
Setting the correct sharing model is critical so that each customer sees only their own data. Salesforce security involves Organization-Wide Defaults (OWD), Role hierarchies (for Plus users), Sharing Rules or Sharing Sets, and manual sharing. We will use Sharing Sets for Customer Community users and Sharing Rules/roles for Customer Community Plus, to automatically share FieldKo records related to each customer.
Set External Org-Wide Defaults: First, review the Org-Wide Default sharing settings for your FieldKo objects. In Setup > Sharing Settings, you’ll see two columns for each object: Default Internal Access and Default External Access. Set the external access to Private for Visits, Tasks, Surveys (and any other object you plan to expose), if not already. This ensures that by default, portal users have no access to records except their own. (Standard objects like Cases or Tasks might automatically be set to private for external by Salesforce.)
Sharing for Customer Community (Sharing Sets): Without roles, Customer Community users rely on Sharing Sets to get record access. A Sharing Set grants portal users access to records by matching fields like Account or Contact between the user and the record. For example, you can create a sharing set that says: give users with profile “Customer Community User” read/write access to all Visit, Task, and Survey records where the record’s Account field matches the user’s Account. This way, if Jane Doe (Contact on Account ABC Corp) logs in, she can see Visit records tagged to ABC Corp (her account). To set up a Sharing Set:
In Setup, navigate to Digital Experiences > Settings > Sharing Sets (or Communities Settings > Sharing Sets).
Click New, then select the profiles that the sharing set will apply to (e.g. your Customer Community profile).
Select the object to share (e.g. “Visit”). For each object, define the matching criteria: e.g. User: Account = Visit: Account, meaning the portal user’s account must match the Visit’s Account lookup field for them to access the record.
Specify the access level (Read or Read/Write). For instance, you might give Read/Write on Visits so customers can update certain fields (or create child records), whereas maybe only Read on Surveys if they shouldn’t modify past surveys.
Repeat within the same Sharing Set to add rules for Tasks and Surveys objects. Save the sharing set.
Result: All users with that profile now automatically can see records for their account without needing individual sharing rules. Sharing Sets are powerful for simple account-based sharing scenarios.
Sharing for Customer Community Plus (Roles & Sharing Rules): Customer Community Plus users have roles, enabling standard sharing rules and role hierarchy access:
Role Hierarchy: When a Plus user is created, Salesforce assigns them an external role under their Account’s hierarchy. By default, users in higher roles (like a “Customer Manager” or the Account’s portal role) can see records owned by users in lower roles. Also, the internal Account Owner (your internal user who owns the Account record) sits above these external roles, so that internal user can see all data owned by the account’s external users automatically. This means if you (internal) own the account, you will by default see the Visits, Tasks, etc. that the external users at that account create or own.
Sharing Rules: To share horizontally or more broadly, you can use sharing rules. For example, you might create a criteria-based sharing rule: share all Visit records where Account = ABC Corp with the group of external users of ABC Corp. In practice, you can often use public groups or roles for this. You could put all external users of an account into a public group (or simply use the automatically created role for that account) and then create a sharing rule that grants Read/Write to that group for that account’s records. However, if all records are tied directly to the account, the role hierarchy may already cover managers seeing subordinates’ records. Use sharing rules if, say, you want every external user on an account to see each other’s data at the same role level (since role hierarchy alone only shares upward, not sideways).
Example: If two external users at the same role level need access to each other’s Survey records, create a sharing rule: criteria Account = ABC Corp (or Owner in role = ABC Corp’s portal role) shared with ABC Corp’s portal role (or a public group of those users). This ensures all contacts on the same account with Plus licences see the account’s collective data.
No Sharing Sets Needed (optional): Note: Plus users can use Sharing Sets as well, but typically if you have Plus, you’ll leverage the role-based sharing for more flexibility. Sharing sets are most useful for the basic licence or very simple sharing needs.
Verify Access: After configuring sharing, it’s good practice to test with a test user. Use the Experience Builder’s Preview as User feature or actually log in as the external user (you can use the Login As function from the contact’s user detail, if you have the “Manage External Users” permission). Confirm that the user can see only the records they should. For example, a customer from ABC Corp should see only Visits/Tasks/Surveys related to ABC Corp, and not data from another account.
Additional Considerations
Sharing Groups (Internal Access to External Data): If your external users will be creating records (e.g. submitting new surveys or updating tasks), you may want internal staff to see those records. For Customer Community licence users (who don’t have roles), you can use a Share Group to share records owned by external users with internal users. A Share Group is set up as part of the Sharing Set configuration: it lets you add internal user profiles or public groups that should get access to records owned by the sharing set’s users. For instance, you could add your internal FieldKo support team to the share group so they can see cases or tasks that customers log. (Customer Community Plus users’ records are usually visible to the account owner and their management via roles, so share groups are less common for Plus.)
Super User Access: For Customer Community Plus, you can optionally enable Super User Access if you want certain external users to see more data within their account beyond default. For example, a “Customer Manager” user with super user enabled could see peer users’ records at the same account. This is turned on in Digital Experiences > Settings by enabling Partner Super User Access (applies to Customer Plus as well), and then enabling Super User on the contact’s user record. Use this carefully if needed for collaboration between customer contacts.
With these sharing configurations, your portal is securely controlled. Customer Community users will only see records tied to their account or their own contact as defined by your sharing set. Customer Community Plus users can leverage roles and rules to see records according to your sharing policies. Notably, Customer Community users cannot have sharing rules (since they have no roles) – if you need complex sharing, that’s a sign you should use the Plus licence for those users.
Summary of Setup
By following the above steps, you have: enabled Experience Cloud, created a site, set up accounts and contacts for your customers, turned those contacts into external users with appropriate licences, assigned them permission sets for FieldKo object access, and configured sharing via either sharing sets or sharing rules. The result is a secure customer portal where each customer can log in to your FieldKo Experience Cloud site and interact with their data (view their upcoming Visits, update Tasks, fill out Surveys, etc.) in a controlled way.
Finally, be sure to provide your customers with the portal URL and perhaps a user guide on how to use the site. They will receive an email to set their password when you enabled them. Once logged in, they’ll have access to the FieldKo information you shared, with a user experience you can brand and tailor to your needs.