When a customer or contact needs to use more than one website, the login experience depends on how NetSuite, SuiteCommerce, customer records, contacts, subsidiaries, and website permissions are configured. Customer access across multiple websites works best when one customer identity is mapped to the permitted sites while each website separately controls catalog visibility, pricing, order access, and account features.
The key distinction is between authentication and authorization. Authentication confirms who the person is. Authorization determines what that person can see and do on each website. A shared login does not automatically mean shared product access, pricing, order history, checkout permissions, or customer-specific content.
This matters in multi-site B2B commerce. A single contact might purchase through one branded storefront, access a separate regional website, and use another site for a different product range. NetSuite can support that structure, but only when the customer record, contact relationship, website configuration, subsidiaries, roles, and SuiteCommerce logic agree.
Why customers need access to multiple websites
Multiple websites are useful when one business operates distinct storefronts without wanting customers to maintain unrelated identities. The sites might represent different brands, regions, product catalogues, currencies, sales channels, or customer segments.
A customer could need access to:
Two brand-specific ecommerce sites owned by the same organization
Regional sites with different currencies and fulfilment rules
A trade portal and a public ecommerce store
Separate sites for different product categories
A distributor portal alongside a direct-order site
A website for ordering and another for support or account services
The requirement sounds simple, but it creates several data questions. Should the customer see the same order history on every site? Should a contact retain the same purchasing permissions? Should pricing follow the customer account, the subsidiary, the website, or a combination of all three?
These decisions should be made before implementation. Otherwise, teams tend to treat a multi-site problem as a login problem when the real issue is account context.
For the broader questions around registration states, password handling, and login validation, see our SuiteCommerce login and registration QA framework. This article focuses specifically on what happens after one customer or contact needs to move between separate websites.
How should customer access across multiple websites work?
Customer access across multiple websites should use a controlled identity model in which the customer or contact is recognized consistently, while each site applies its own eligibility, catalogue, pricing, transaction, and content rules.
In practice, the same person should not receive unrestricted access simply because they can authenticate. Each website should evaluate the session against relevant data, including:
The customer or contact record
The associated company or parent account
Subsidiary and location
Website or domain eligibility
Customer category and price level
Role or purchasing authority
Item and catalogue availability
Credit, order, and checkout restrictions
This model separates who the user is from what the user is entitled to access. It also provides a more reliable audit trail. Orders placed through different sites can still relate to the same customer account, while the front end presents only the transactions and functions appropriate to that website.
A strong implementation defines these rules explicitly. It does not assume that NetSuite’s customer record alone determines the complete user experience.
Customer versus contact: which record should control access?
The customer record should represent the business account, while the contact record should represent the individual person who signs in or acts on behalf of that account.
This distinction becomes important when several people from one organization access multiple sites. A purchasing manager, finance contact, and service contact may all belong to the same customer account but require different permissions. The customer record might control account-level pricing and financial terms, while the contact relationship determines whether a person can view orders, place purchases, or manage other users.
A practical access model answers four questions:
Which record authenticates the user?
Which account owns the commercial relationship?
Which permissions belong to the individual contact?
Which websites accept that identity?
A common mistake is creating duplicate customer records for every website. That approach can produce fragmented order history, inconsistent pricing, duplicate contacts, and difficult account maintenance. Separate records are justified only when the underlying commercial relationships genuinely differ and the business needs independent financial, subsidiary, or operational treatment.
What changes when one contact uses multiple SuiteCommerce sites?
When one contact uses multiple SuiteCommerce sites, the application must preserve identity while recalculating the site context. The same email address does not by itself guarantee identical access on every domain.
Each site may apply its own rules for:
Product and category visibility
Customer-specific pricing
Login-required pages
Checkout eligibility
Payment methods
Shipping addresses
Order history
Reorder functions
Quote or request forms
Content and promotions
The site context also matters when a business operates multiple subsidiaries or catalogues. An item available on one website might not be available on another because of website assignment, subsidiary availability, inventory rules, customer eligibility, or product status.
This is why a contact can successfully log in on Site A but see a different catalogue on Site B. That outcome is not necessarily a defect. It is correct when the sites represent different commercial rules. It becomes a defect when the difference is caused by an unintended mismatch in account mapping or permissions.
The session should therefore be tested as a combination of identity and site, not as identity alone.
| Access layer | Main question | Typical consequence |
|---|---|---|
| Authentication | Can NetSuite or SuiteCommerce identify the person? | Login succeeds or fails |
| Account relationship | Which customer account does the contact represent? | Orders and account data use a specific owner |
| Website eligibility | Is the account permitted on this site? | Site access is allowed or denied |
| Catalogue rules | Which products are visible here? | Search and product pages differ |
| Commercial rules | Which prices and terms apply? | Pricing and checkout differ |
| Transaction permissions | What can the user view or submit? | Orders, quotes, and reorder tools differ |
Should customers use one login or separate logins?
A shared login is generally the better experience when the websites belong to the same commercial account structure and the organization wants a consistent customer identity. Separate logins are more appropriate when the sites represent legally or operationally independent relationships.
One login reduces password fatigue and prevents customers from creating duplicate profiles. It also makes it easier to associate activity with one contact and one customer account. However, a shared login requires careful authorization checks. The application must not treat successful authentication as permission to access every website or every record.
Separate logins provide stronger isolation. They can be suitable when:
Websites serve unrelated subsidiaries
Each site has a separate customer database
Financial terms must remain independent
Different legal entities own the customer relationship
The same email address belongs to different authorized users
Order history must not cross organizational boundaries
The decision should be based on data ownership and access governance, not only on convenience. If one person needs access to several sites but those sites use separate customer records, the design needs an explicit account-linking process. That process should define which profile is authoritative and how conflicts in email addresses, permissions, addresses, pricing, and order visibility are resolved.
How do pricing, order history, and permissions behave across sites?
Pricing, order history, and permissions should be tested independently because they do not always follow the same rule.
A customer might receive the same contract pricing on two sites while seeing different product selections. Another customer might access both sites but retain order history only for the site or subsidiary that owns the transaction. A contact might browse both sites but have purchasing rights on only one.
Pricing
Pricing can depend on the customer, price level, currency, subsidiary, item, quantity, promotion, and website context. The displayed price should be validated for both logged-in and logged-out states where relevant.
Do not test only a single product. Use products with different pricing rules, including an item with customer-specific pricing, an item unavailable on one site, and an item affected by quantity or promotion logic.
Order history
Order history should follow a clearly documented ownership rule. If transactions are stored against one customer account, the front end must decide whether both websites display them or whether each site filters transactions by website, subsidiary, channel, or transaction type.
The most important test is not whether an order appears. It is whether the contact can see only the orders they are authorized to see. Administrative access is not a substitute for a customer test because administrative roles can bypass restrictions that apply to ordinary users.
Contact permissions
The contact’s permissions should remain consistent where the business expects a shared identity. If the contact can place orders on one site but only request quotes on another, that difference should be intentional and visible in the requirements.
A permissions matrix is more reliable than verbal assumptions. Record the expected result for each website, contact type, subsidiary, and action, then compare the actual result against that matrix.
What should you test when a customer accesses multiple websites?
Testing should cover the complete transition between websites, not just the first successful login. A customer may authenticate correctly and still receive the wrong catalogue, price, account data, or checkout behavior.
Test the following scenarios as one connected journey:
Login on the first website
Logout and login on the second website
Moving between domains in the same browser
Opening a bookmarked account page directly
Using an expired session
Resetting a password from one site and signing in to another
Accessing an unauthorized website
Switching between contacts linked to the same customer
Viewing orders created through different sites
Adding products that exist on only one site
Checking customer-specific pricing
Submitting an order with restricted payment or shipping terms
Cross-domain behavior deserves particular attention. Cookies, session state, redirects, and return URLs can behave differently when websites use separate domains or subdomains. A login that appears successful can still create a broken experience if the session is not available to the destination site or if the site silently falls back to an anonymous state.
The test should also inspect the network and application response, not just the visible page. Confirm that the request carries the expected customer context, that restricted data is not returned to the browser, and that the user is not relying on hidden interface controls as the only security mechanism.
Common failure points in multi-site customer access
The most common failure is an incomplete identity model. The organization decides that one email address should work everywhere but does not define the customer account, contact relationship, or site eligibility behind that email.
Other failures include:
Duplicate customer records. Separate records may solve an immediate access issue while creating long-term problems with order history, reporting, credit management, and customer service.
Incorrect website assignment. A customer can authenticate but be rejected by the destination site because the account is not included in that site’s access rules.
Stale browser state. A browser may retain a session, cart, or cached page from another site. This creates misleading results during testing.
Overly broad permissions. A user receives access to a second website and unintentionally gains access to pricing, orders, or account functions that should remain restricted.
Incomplete subsidiary logic. The customer exists in NetSuite, but the site uses a subsidiary or location context that does not match the user’s permitted records.
Frontend-only restrictions. A button is hidden from the user interface, but the underlying endpoint still returns data when called directly. Security must be enforced on the server side and in the data query.
For a related example of tracing site, item, customer, and transaction conditions through a SuiteCommerce issue, see our guide to diagnosing missing reorder items through the data path.
A practical framework for designing the access model
Start with the business relationship, not the website URLs. List the legal entities, customer accounts, contacts, subsidiaries, sites, catalogues, and transaction types involved. Then identify where the same identity should be reused and where separation is mandatory.
Next, define the access decision for every site. The decision should include authentication, website eligibility, customer account, contact permissions, catalogue visibility, pricing, and transaction access. These are separate controls even when they use some of the same NetSuite data.
Then document expected behavior in plain language. For example, “the contact can sign in to both sites, sees site-specific catalogues, receives account pricing on both sites, and sees orders associated with the shared customer account.” This statement is more testable than “the customer has multi-site access.”
Finally, validate the model with negative tests. Attempt to access a site the customer should not use. Try to view an order belonging to another subsidiary. Test an inactive item, a restricted price, an unauthorized contact, and a direct URL to an account page. A secure model proves both permitted and denied behavior.
If the current architecture has inconsistent records, unclear site rules, or repeated login defects, contact Versich to discuss the access model and testing approach.
Conclusion
Customer access across multiple websites in NetSuite should be designed as an identity and authorization model, not as a simple login feature. The strongest approach keeps the customer or contact identity consistent where appropriate while allowing each SuiteCommerce site to apply its own catalogue, pricing, subsidiary, order, and purchasing rules.
Start by deciding which account owns the relationship, which contacts can act for that account, and which websites each identity may use. Then test cross-domain sessions, site eligibility, pricing, order history, catalogue restrictions, and direct access to protected pages. This prevents duplicate records, confusing customer experiences, and security gaps while giving customers a more predictable way to work across your websites.
