Help center Core configuration Customers & support levels Manage contacts and customer portal access Updated Thursday, October 29, 2026 · Marc Staine Contacts identify the people your team supports and connect them to companies, communication details and portal access. Accurate contact relationships help agents choose the correct customer and avoid misdirected communication. Applies to: Supportbench Core. Location: Customers → Contacts. Access and available controls depend on your role and account capabilities. Before you begin You need permission to create or edit the intended Contact. The applicable customer policy can hide optional fields/panes.Search by the person’s actual email and Company before creating a record. Portal access and Company relationships deserve deliberate review.Review the saved result and a controlled example in the consuming workflow. Configuration, customer access and actual delivery or processing are separate checks. Configure and verify Open Customers → Contacts and search for the person. Choose New Contact only when a new identity is needed.Enter the required First name and primary Email; add Last name and other visible identity details where appropriate. The Contact form has no generic Name/Description pair.Select the intended primary Company and verify the actual organization. Review Status, Type, support details, managers and contact methods as appropriate.Review Disable community access, Community administrator, Company watcher, Related companies and Roles only for the responsibilities this person should receive. Do not grant administrative or broader customer access merely to make a missing page appear.Choose Save Contact, reopen the record and confirm identity, Company and access-related settings.For a portal-access change, use the intended customer identity to check allowed and excluded records and direct links. Agent visibility and a saved Contact are not proof of correct customer authorization. Settings reference Identity and contact detailsSettingWhat it controlsHow to chooseFirst name / Last name / EmailFirst name and primary email are required.Confirm the person and address before saving.Primary company / Status / TypeCompany association and configured contact classifications.Choose the actual organization and lifecycle category.Support level / ExpiryContact-specific support entitlement.Review the intended relationship with the company’s support arrangement.Title / Department / Bio / AvatarProfessional context and identification.Store relevant, verified information.Secondary emails / Phone / Extension / MobileAdditional communication channels.Confirm ownership and avoid shared addresses unless intentional.Tags / Managers / Timezone / LDAP username / ActiveClassification, relationship ownership, regional and supported directory context.Set only applicable values and review access before deactivation. Mailing, social and fieldsSettingWhat it controlsHow to chooseUse company mailing addressUses the associated company’s mailing details where supported.Use when this is the correct business address.Address / City / State / Country / PostalContact mailing address when separately maintained.Keep the full address consistent.Social URLs / Twitter handlesSupported social profile references.Use verified professional links.FieldsContact custom fields selected by the applicable policy.Follow each field’s intended data type. Community and relationshipsSettingWhat it controlsHow to chooseDisable community accessPrevents supported customer portal access for the contact.Confirm the intended restriction before saving.Community administratorGrants supported portal administration capability.Assign only to an authorized customer representative.Company watcherReceives supported case notifications for the company, beyond the contact’s individual case participation.Enable only for a customer representative who should receive company-wide case updates.Related companiesAdditional company relationships.Verify the person is entitled to the resulting company context.Roles / IntegrationsCustomer-role associations and conditional integration information.Review audience and integration effects independently. Behavior to knowPortal access depends on more than an email address: contact flags, relationships, roles and portal configuration all matter.Customer policy can hide or rearrange fields without deleting stored values. Recommended use Use verified identity and Company relationships. Put relevant professional context in Bio when available; the Contact form has no generic Description field.Grant Community administrator, Company watcher, Related companies and Roles only for agreed responsibilities. Each can have a wider operational effect than editing a phone number.Verify the customer’s actual allowed and excluded experience after access-related changes. An agent being able to open the Contact is not a customer-access test. Worked example: onboard a customer’s equipment-service coordinator Alex Chen is a fictional service coordinator at Northstar Manufacturing. In an approved test context, search for the person by their verified address and Company before choosing New Contact. Use only an address you control for any sign-in or notification test.Enter First name, primary Email and the relevant identity fields. Choose the correct primary Company and confirm its relationship before saving. Add a short Bio describing the service responsibility if useful; avoid private notes or unnecessary personal data.Review support details against the actual agreement. Inspect Roles on the Contact and those derived from its Company. Do not add a duplicate or broader entitlement simply because a knowledge page is missing.For an ordinary service contact, review Disable community access for the intended sign-in outcome. Enable Community administrator or Company watcher only if Alex is authorized for those broader responsibilities; a routine portal user does not automatically need them. Add Related companies only when the relationship is confirmed.Choose Save Contact and reopen it. Verify identity, primary Company and every access-related choice. With the controlled customer identity, check the intended knowledge and Case context, then test a direct link to material the person should not receive.If unexpected customer history appears, stop sharing that material and inspect primary/related Companies and applicable customer permissions. If knowledge is missing or excessive, inspect both Contact and Company-derived roles with the portal/article rules. Do not solve either problem by granting administrative access. Troubleshooting ProblemWhat to checkThe form rejects the new ContactCheck required First name and primary Email and the displayed validation result.A field or Roles tab is missingReview the Contact field policy and editing permission; a hidden control does not prove the underlying value is absent.The person sees unexpected knowledgeReview both Contact roles and roles inherited from the associated Company, then article/portal restrictions.The person cannot use the portalReview Disable community access, supported identity/sign-in mapping and the actual portal’s access rules.The wrong customer history appearsVerify the actual primary/related Company relationships and intended customer permissions before sharing additional information. Related configuration Customers → Manage companies and customer organization detailsCustomers → Configure company and contact field policiesCustomers → Configure contact statesCustomers → Configure contact typesCustomers → Configure customer rolesSelf-Service → Configure a customer portalManage companies and contacts with the full support relationship in viewSign in to your customer portal: password, Microsoft, Google and recovery steps Was this article helpful? Yes No Thank you for your feedback.