Show a customer’s permitted cases across portal Divisions

A customer may be authorized to see a case that belongs to a different Division from the ones selected for the current portal. Show unrestricted Cases can address that specific scope problem. In current Core, it bypasses the portal’s Division/category filter for cases the customer is otherwise permitted to view. It does not remove Contact/Company authorization or make every case visible to every customer.

Separate the layers of customer case visibility  ·  Confirm that Division scope is the actual problem  ·  Change Show unrestricted Cases  ·  Handle secondary Contacts separately  ·  Verify permitted and excluded scenarios  ·  Example: a customer works with Product Support and Billing  ·  Troubleshoot an unexpected result

Separate the layers of customer case visibility

The setting acts on the Division/category layer. It does not grant company-administrator rights, turn an internal case into a public case or authorize a Contact to read another customer organization’s unrelated work. Some older descriptions say it removes standard Contact/Company restrictions; that is not the behavior of the current Core case access query.

Confirm that Division scope is the actual problem

1. Identify the exact customer Contact and the Case ID they should be able to see.
2. Verify the customer relationship and the intended permission to view that case. A similar Company name is not enough.
3. Review whether the case is public and eligible for the customer workflow. Investigate merged/Trash or other lifecycle exclusions separately.
4. Open the intended Community and review Visible divisions. Compare the case’s Division with that scope.
5. Decide whether the portal should show all otherwise-permitted customer cases across that Division boundary, rather than changing the customer relationship itself.

If the case is not authorized for the Contact, this switch is not the correction. Resolve the actual relationship or access requirement through the normal customer administration process. Keep the narrowest operational reason for the change clear.

Change Show unrestricted Cases

1. Open Settings → Self-Service → Customer portal using an administrator with Administer communities authority.
2. Open the intended Community and select Setup.
3. Review the existing Visible divisions and customer audience before changing anything.
4. Set Show unrestricted Cases to the intended value. Enable it when this portal should include otherwise-authorized cases beyond its selected Division/category scope.
5. Choose Save Changes.
6. Reopen the Community and verify the saved value. Then test the actual customer case list and case detail using the procedure below.

Handle secondary Contacts separately

Allow secondary contact Case visibility is a different choice. When enabled, it can allow a Contact explicitly listed as a secondary Contact on a particular Case to see that Case, while the other portal and case checks still apply. It is not permission to view all cases belonging to the Company.

For example, a customer’s implementation lead may be added as a secondary Contact on one integration case. Verify that specific relationship and the portal setting. Do not assume that the same person should also see every billing or personnel-related case for the customer organization.

When investigating a missing case, distinguish a Division mismatch from a missing secondary-contact relationship. Enabling one setting does not replace the other requirement.

Verify permitted and excluded scenarios

1. Use a representative Contact and identify an eligible case inside the portal’s selected Divisions. Confirm that the customer can open the list entry and detail.
2. Identify another case that the same Contact is otherwise authorized to see, but whose Division falls outside the portal selection. Compare its visibility with Show unrestricted Cases off and on in an approved test configuration.
3. Verify an unrelated customer’s case remains unavailable. This is a boundary check, not a reason to expose private records during testing.
4. Check that internal/non-public, merged or Trash cases do not become visible merely because the switch is enabled.
5. If secondary-contact access is intended, test a Case where the Contact is explicitly linked and a same-company Case where they are not.
6. Record the portal, customer test identity, relevant case references, configuration and result through the approved internal process. Avoid including private records in public documentation.

Changing the setting affects a live customer experience. Use approved test identities and a safe test configuration, and coordinate with the portal owner. Do not experiment on an unknown customer’s access just to find a case.

Example: a customer works with Product Support and Billing

A business customer has permitted cases in Product Support and Billing. Its portal is initially scoped to Product Support. The customer’s authorized account contact should use that portal to follow both kinds of work, but a Billing case is missing because it falls outside the selected Division scope.

The administrator confirms the customer relationship and case eligibility, then uses Show unrestricted Cases for that portal. The same customer’s eligible Billing case becomes available if the remaining access rules pass. A different organization’s Billing case remains excluded. The setting changes which Divisions are considered, not whose cases the Contact is entitled to read.

Troubleshoot an unexpected result

Continue learning

• Review the complete portal configuration
• Build and test a customer portal
• Understand Company and Contact relationships
• Separate Divisions from customer authorization