Branded Experience: You can customise the portal’s look and feel to match your organisation’s branding, providing a seamless experience for your customers.

Real-Time Data: The portal is live with your Salesforce data – when internal staff update a FieldKo record, your customer can immediately see the changes on the portal, and vice versa.

Security and Trust: Salesforce’s robust security model ensures that each customer sees only the data they’re supposed to, no more, no less. Data is stored safely in Salesforce and served over secure connections.

No-Code Customisation: Using the Experience Builder, admins can design pages and components with clicks, not code, to display information and enable interactions.

Customer Community licence: This is the standard licence for high-volume B2C scenarios. It has a simpler sharing model — no roles for users, and thus no native sharing rules​. Customer Community users’ access to records is primarily controlled through sharing sets (and their profile/permission sets). This licence is cost-effective and great for large numbers of users who only need access to their own data. However, it cannot access certain advanced features (for example, limited reports or certain objects) and is restricted in sharing complexity. It’s equivalent to the old “High-Volume Customer Portal” user in Salesforce​.

Customer Community Plus licence: This is an enhanced licence that includes more advanced sharing and functionality. Users get roles in the system, enabling role-based sharing and ownership like internal users​. With Plus, you can use sharing rules, role hierarchy, and even manual sharing to open up record access as needed. It also generally allows access to more Salesforce features (e.g. reports/dashboards, content, maybe more custom objects). This licence is suited for scenarios where you might have multiple contacts at one account who need to collaborate or see each other’s data, or you require more complex data visibility rules. It’s akin to a “Customer Portal Manager” or the partner community user in terms of capability. Plus licences are often used in B2B contexts or more involved customer service situations where advanced sharing is essential​.

Customer Community: uses Sharing Sets (match on Account/Contact) for record access; no role hierarchy. Simpler, good for one-contact-per-account or strictly separate data access.

Customer Community Plus: uses Roles and Sharing Rules for record access; data can roll up in hierarchy and be shared across users. More flexible for complex sharing (e.g. many contacts per account, need to share some records across those contacts).

Object Permissions: Through the profile or permission set assigned to your external users, grant at least Read access on these objects. If you want customers to perform actions (e.g. create a new Task or update a Survey response), give Create and/or Edit permissions as appropriate. For example, you might allow Edit on Task so they can update certain fields, or Create on Survey if they need to submit a new survey record.

Field-Level Security: Within those profiles/perm sets, review the field permissions. You might have internal-only fields on Visit that you don’t want the customer to see (set those to hidden for the external profile). Ensure that all fields the customer should view or update are visible/editable for them. This prevents any sensitive internal data from leaking onto the portal page.

Related Records Access: If a FieldKo object has related child records (for instance, maybe a Visit has related Task records), keep in mind the customer needs access to the parent to see the child. Salesforce will enforce object permissions and sharing down the line. Generally, if you share the parent (Visit) via sharing sets/rules, and the external user profile has access to Task, they will see related Task records that are associated. You might need to explicitly share child records too depending on their relationship (master-detail inherits parent sharing automatically; lookup does not).

Use a Template: If you started with a template like Customer Service, it may already have some pages (Home, Contact Support, etc.). You can repurpose pages or create new ones for your FieldKo objects. For instance, you might create a Visits page to list upcoming or past visits for the logged-in customer.

Page Creation: In Experience Builder (accessible via the “Builder” link in Experience Workspaces or by clicking “Edit” on the site), use the Pages menu to add new pages. You can create a Object List Page or Object Detail Page for your custom object:

Navigation: Update the navigation menu (often a top menu or sidebar) in Experience Builder to include links to these new pages. For example, add a menu item “Visits” pointing to the Visits list page, “Tasks” to tasks, etc., so that customers can easily find them.

Branding and Design: Use the Theme panel to apply your logo, colours, and fonts so the portal matches your branding. You can add rich banners, adjust page layouts, and include text or image components to guide users.

Components and Flexibility: Experience Builder supports standard Lightning components. You can add charts, list views, knowledge search, etc., as needed. For FieldKo data, perhaps a dashboard component showing summary of their open tasks or a chart of survey scores might be useful (note: Customer Community Plus users could have access to certain reports or dashboards if you enable that, whereas base license might not allow dashboard access – keep the licence limitations in mind).

Account Separation: Typically, portal users from one account cannot see data from another account. The sharing rules or sharing sets you configured enforce this. For instance, a sharing set gave access to Visit records where record.Account = user’s Account – so by definition, they can’t see other accounts’ Visits. In the UI, this means when they log in, any list views or record lists will inherently only show their records. If they search, global search results will be scoped to what they have access to.

Sharing Model Recap: For Customer Community users, the sharing set ensures they see records tied to their account or contact. For Customer Community Plus, the role hierarchy and any sharing rules determine their view. Important: Customer Community users cannot suddenly gain access to unrelated data because the system simply doesn’t link them to it (no accidental broad sharing since no roles exist to accidentally put in a sharing rule)​. Conversely, with Plus users, you have more power – you might intentionally or accidentally share more, so design your sharing rules carefully.

Test Different Scenarios: It’s good to test with multiple test users from different accounts to confirm that each sees only their own. For example, user from Account A should not see anything for Account B in Visits page. Use Salesforce’s Login As User for external users or create dummy accounts for testing.

Record Ownership and Creation: If you allow external users to create records (say fill a survey or create a task), be aware of ownership. A record created by a Customer Community user will be owned by that user (who has no role). It will automatically satisfy the sharing set criteria (it’s their account’s record), so other contacts on the same account with Customer Community licence – if they also log in – will also get access to that record if your sharing set is based on account. (This is great for collaboration: all contacts on the same customer account can see each other’s submissions, as long as the sharing set is account-based.) With Plus, if one user creates a record, their role and hierarchy might allow peers or just their manager to see it. You might use a sharing rule or enable super user to let peer contacts see it. Consider whether customers from the same company should see each other’s entries or not, and configure accordingly.

Secure Guest Access: Ensure pages that list data are not accessible to guest (unauthenticated) users. By default, Experience Cloud will not show object data to guests unless you intentionally set it. Double-check that your site’s Guest User profile has no access to these objects, so that data is truly behind login. (This is usually default, but worth verifying in Administration > Pages or Guest User profile.)

Real-Time Visibility: Because the portal is directly reading from your Salesforce org, any updates are immediate. For example, if your internal team completes a Visit and marks it as Completed in FieldKo (Salesforce), the customer could refresh their Visits page and see that updated status right away. There’s no overnight sync or delay. This real-time aspect improves transparency and customer satisfaction – they are always looking at the latest data.

Two-Way Interaction: Not only can customers see data, but with the proper permissions, they can interact (post comments via chatter if enabled, update tasks, answer surveys). These changes are instantly saved in Salesforce. Your internal team will see customer-entered data without needing to import or re-key – it’s truly a unified system.

Data Security: All data in transit between the user’s browser and Salesforce is encrypted via HTTPS. Salesforce handles user authentication (with options for multi-factor authentication, login IP restrictions, etc., which you can enforce for extra security). Moreover, every action the user takes is under Salesforce’s governance – for example, if they try to access a record they shouldn’t, they’ll simply get an error or no data. By leveraging standard Salesforce sharing (sharing sets, rules, profiles), you inherit a tested security framework​. You do not have to write custom code to hide records – Salesforce does it for you.

Compliance and Auditing: All portal logins and actions are recorded like normal user logins. You can run reports on what your external users are doing if needed. And because you’re not exporting data outside Salesforce, you maintain compliance (all data stays within the Salesforce cloud). If your industry has compliance requirements, using Salesforce communities can help meet them since Salesforce offers compliance certifications and features (e.g. field history tracking on objects can log changes made via the portal).