Community Portal

Required for your chosen channel: customer portal · Connect support channels

A community portal is the customer-facing site where people can find approved knowledge and submit or follow support requests. It is separate from the agent workspace. Set up the basic customer journey before spending time on advanced visual customization.

Before you begin

Use an administrator with portal-editing permission and the required community/portal module enabled. Have a monitored queue, approved reply identity, customer access decision and test contact ready. Use a controlled mailbox for registration and actual email tests; the fictional Harbor address is not usable for delivery.

Configure the basic portal

1. Open Settings → Self-Service → Customer portal.
2. Open the intended existing portal. If a separate portal is genuinely required, select New Community, enter an internal Name and a unique Alias for its hosted supportbench.net address, choose the intended theme, then select Create portal. Plan its audience before creation; reuse the existing portal when it already meets the need.
3. In Setup, review Name, Description and Active. Name and Description identify the portal internally; Browser title controls the browser-tab/search title. Use Northstar Support — training for the fictional internal name.
4. Set the appropriate Default division, Default queue and Reply address for portal-created work. Northstar’s example uses Customer Support and Support Queue; the existing demo screenshot has different saved defaults and is not a recommendation to copy them.
5. Choose the Default landing page: Home, Cases or New request. Home suits a knowledge-led experience; New request puts intake first.
6. If you offer knowledge, turn on Enable knowledge base and review Show all containers (containers are knowledge topics). If using a selected list, choose only the intended topics. Start with reviewed starter content. Turning knowledge off hides article/topic/search/AI-answer experiences and opens Cases.
7. Select Save Changes and reopen Setup to verify the intended choices. These settings apply immediately; Publish is for design drafts and is a separate action.

Saved demo portal Setup. Its Clients/APAC defaults are existing demo values; choose Customer Support and Support Queue for the Northstar example.

Customer portal configuration is the complete reference. A saved portal setting, design draft and page-template change can have different publication behavior.

Decide who can enter and what they can see

1. Review Require sign-in. It applies even when anonymous case submission is allowed.
2. Review Allow anonymous case creation only if your process is designed to accept them.
3. Review Visible divisions and Customer roles, then article/topic access in the KB Security chapter.
4. Keep Show unrestricted cases off for an ordinary customer-specific support portal unless a reviewed business requirement explicitly calls for broader access. That setting can remove the standard contact/company restriction.
5. Review Allow secondary contact case visibility against the customer relationships you intend to support.
6. Save and test with an intended customer and an unrelated customer. An administrator’s preview does not prove isolation.

Unsaved access example: Show unrestricted cases is off. Review all audience settings before saving; the existing demo portal was not changed.

A contact record does not automatically establish a working portal login. Open the saved contact’s Profile tab, select Create profile, and confirm Create a portal profile for this Contact? to create the portal profile when access is appropriate. This does not send a password email. Test the configured external sign-in separately; the permission-gated Open as Contact action is not an external login test. Review the contact’s Community and Roles settings through Customers → Contacts, and use the configured customer registration/sign-in process. Contact and portal-access administration explains the supported identity options. Leave SAML or custom authentication to a separately verified identity setup if you do not need it initially.

Verify the complete customer experience

1. Open the portal’s actual saved URL as a customer.
2. Check the landing page, useful knowledge and the way to submit a new request.
3. Submit the harmless report-export request using a controlled contact. Fill the fields required by the Portal Open case policy.
4. In the agent workspace, confirm the resulting case, customer, division and queue.
5. Reply through the approved channel and verify what the customer can read. Confirm internal notes remain internal.
6. Check the portal on a narrow screen as well as desktop.

Customer-facing demo portal header and knowledge search. This signed-in view does not prove external customer isolation.

Use the hosted portal URL while onboarding if it works for your needs. A custom domain requires its own DNS and certificate validation. Do not change an existing template just to explore: replacing a template or publishing a design can affect the live customer experience.

Recover common failures

If the portal is unavailable, check Active, the saved URL and sign-in requirements. If knowledge is missing, inspect Knowledge base, included topics, topic public/active state, article publication and audience. If a request goes to the wrong queue, inspect the portal default and subsequent workflows.

If an unrelated customer can see Harbor’s case, stop customer rollout and correct the access rules before continuing. If a visual change is absent, confirm whether it is still a design draft and use that surface’s actual publication control.

Completion check

• The portal has a clear customer purpose and working URL.
• Request routing and customer identity are verified.
• Public and restricted content behave as intended.
• Internal notes and unrelated customers’ cases stay excluded.
• Desktop and narrow-screen customer journeys work.

Previous: Email Domain Authentication · Next: Set up chat and test the customer handoff