Last updated

The Customer and Company Model

This article explains how Norce Commerce models customer and company data, how the two entities relate, and what integrators need to know to import and maintain them correctly.


Two Entities: Customer and Company

Norce Commerce uses two separate entities to represent the people and organizations that buy from your store.

EntityRepresentsUnique identifier
CustomerAn individual person — a B2C buyer or a contact at a companyEmailAddress (default lookup)
CompanyAn organization — a business, division, department, or business unitVATNumber / OrganizationNo (default lookup)

A B2C order has a Customer and no Company. A B2B order has both — the Customer is the contact person placing the order on behalf of the Company.

The same Customer can do both. A person can place an order as a private individual and later place an order as a contact for a company. Norce supports this without needing two separate customer records.


The Customer Model

Roles

A Customer in Norce Commerce serves two roles depending on the order:

  • B2C buyer: The customer is the end buyer. No company is involved.
  • B2B contact: The customer is a contact person associated with one or more companies. The company is the buyer; the customer represents who placed the order.

Customer ↔ Company: Many-to-Many

The relationship between Customer and Company is many-to-many. A customer can be linked to multiple companies — one marked as their primary company (e.g. their employer), plus others they are allowed to purchase on behalf of (e.g. client projects as a contractor). A company has many customers (contacts).

Built-in Fields

The table below lists the commonly used fields. See the full Customer schema for a complete reference.

FieldNotes
EmailAddressUnique identifier; default lookup key
CodeExternal identifier — typically the ERP or CRM customer number
FirstName, LastName
InvoiceAddressOne per customer
DeliveryAddressesMultiple allowed
FlagsBoolean tags for segmentation (see below)
PriceListsOptional; for loyalty-based or custom pricing
AccountsOptional login credentials per application
AdditionalInfoInfoTypes — extensible custom fields

Customer Flags

Customer flags work like product flags but on the customer register. Use them for:

  • Loyalty segmentation (Gold / Silver / Bronze)
  • Interest or preference tagging
  • Campaign targeting — flags can be used as conditions in Norce campaign functionality

Price Lists

Customers can be linked to specific price lists, giving them access to custom prices or restricted assortments when they identify themselves. Less common than company price lists, but useful for loyalty programs.

Accounts

Accounts are Norce's built-in login mechanism. An account is tied to a specific application and holds a login name, role, and hashed password. This is optional — many solutions use a third-party identity provider instead. When using third-party auth, the authenticated user's email address or customer code is used to look up the correct customer in Norce after login.

InfoTypes (AdditionalInfo)

The customer model can be extended with custom fields via InfoTypes (called AdditionalInfo in the Connect contract). Examples: clothing sizes, delivery preferences, opt-in flags for personalisation. These can be imported and maintained via ImportCustomers.


The Company Model

Built-in Fields

The table below lists the commonly used fields. See the full Company schema for a complete reference.

FieldNotes
VATNumber / OrganizationNoUnique identifier; default lookup key
CodeExternal identifier — typically the ERP company/customer number
Name
InvoiceAddressOne per company
VisitAddressOne per company
DeliveryAddressesMultiple allowed
ParentCompanyCodeOptional; for hierarchy (see below)
FlagsBoolean tags for segmentation
PriceListsCommon in B2B for contract prices and restricted assortments
CompanyDiscountsReal-time discount rules applied on top of price list
DeliveryMethodsOptional company-specific delivery options
PaymentMethodsOptional company-specific payment options
AdditionalInfoInfoTypes — extensible custom fields

Parent Company Hierarchy

Norce supports a parent-child hierarchy between companies via ParentCompanyCode. This is a structural model only — there is no automatic inheritance of prices, discounts, or settings between parent and child. Use it to represent organizational structures (holding company → subsidiaries) that your storefront or integration logic can act on.

Price Lists and Assortments

Company price lists are common in B2B. They serve two purposes:

  • Customer-unique prices: The company sees prices from its contracted price list rather than the standard price list.
  • Customer-unique assortment: Certain products are only visible or purchasable for specific companies.

Important: Price lists must exist in Norce before they can be linked to a company. Create them via the Management API first, then reference them by code in ImportCompanies.

Company Discounts

Company discounts are category- or flag-based discount rules applied on top of the price list, calculated in real time at checkout. They are not stored as explicit prices and do not appear in price exports. They are visible when a logged-in user fetches prices via the Query or Storefront APIs.

B2B Approval Flow

In B2B implementations, the ERP typically owns the company register (contracts, credit limits). A common pattern:

  1. Company is created in Norce when an organization registers on the storefront.
  2. Integration sends the new company to the ERP for approval.
  3. ERP returns the CompanyCode and a verification flag (e.g. "approved to buy on contract").
  4. Integration updates the company in Norce via ImportCompanies with the ERP code and any linked price lists.

Until the ERP code is set and the company is approved, they cannot purchase on contract terms.


Identification and Lookup Keys

Customer

Norce looks up existing customers by EmailAddress by default. If a customer is imported with an email address that already exists, Norce updates the existing record rather than creating a duplicate.

Code (CustomerCode) is the external identifier — the number assigned by the CRM or ERP that owns the customer register. This must be globally unique across all applications regardless of the application-unique setting (see below).

Company

Norce looks up existing companies by VATNumber (also called OrganizationNo). Code (CompanyCode) must also be unique and is used as the external identifier from the ERP or CRM.


Application-Unique vs Client-Unique

The customer and company register lives at the client level — accessible across all applications by default. However, you can configure customers and companies to be unique per application in the client settings.

SettingBehavior
Client-unique (default)One shared register. An email or VAT number matches the same customer/company regardless of which application the request comes from. Use when there is one shared CRM or ERP across all applications.
Application-uniqueSeparate registers per application. The same email address can exist as different customers in different applications. Use when each application has its own CRM or customer master.

Note: This setting applies to both Customer and Company simultaneously — you cannot have different settings for each within the same client.

Warning: CustomerCode and CompanyCode must be globally unique regardless of the application-unique setting. The application-unique setting only controls whether duplicate email addresses / VAT numbers are treated as the same record across applications.

Do not change this setting yourself

Changing the Is application unique setting on an existing client is highly destructive — it will cause existing customer and company lookups to behave differently across all applications immediately. If you believe this setting needs to change, contact Norce support rather than making the change yourself.


Importing via Connect

Both ImportCustomers and ImportCompanies are asynchronous operations — a job ID is returned for status tracking, identical to product imports.

ImportCustomers

Accepts a list of Customer objects. You can include:

  • All built-in fields (name, addresses, email)
  • AdditionalInfo (InfoTypes / custom fields)
  • Accounts (login credentials)
  • Price list codes (price lists must already exist)
  • Company associations — by Code or Id; set IsPrimary on the primary company relationship

You cannot create companies via ImportCustomers. Companies must already exist before linking.

ImportCompanies

Accepts a list of Company objects. You can include:

  • All built-in fields (name, addresses, VAT number)
  • AdditionalInfo (InfoTypes / custom fields)
  • Price list codes (price lists must already exist)
  • CompanyDiscounts
  • ParentCompanyCode
  • Delivery method and payment method associations (must already exist)
  • A full Customers list — you can create or update customer records inline when importing a company. This is the recommended approach when onboarding a new company and wanting to create a default admin contact in the same operation.

GDPR and Anonymization

Norce has built-in anonymization functionality that scrambles all personal data for a given customer across the entire data store — customer records, orders, and baskets. After anonymization:

  • Internal IDs and relationships are preserved (so order history structure remains intact).
  • All PII fields are overwritten and can no longer be read back.

Important for integrations: If an external system pushes customer data back to Norce after anonymization (e.g. a scheduled sync), the customer record will be re-populated with PII. Anonymization must be coordinated across all systems that hold customer data simultaneously. Norce does not prevent a re-import of data for an anonymized customer.


Common Pitfalls

PitfallDetails
CustomerCode not globally uniqueEven with application-unique customers enabled, CustomerCode must be unique across the entire client. Duplicate codes cause one record to silently overwrite the other.
Linking to non-existent price listsPrice lists referenced in ImportCustomers or ImportCompanies must already exist. Create them via the Management API before the import.
Creating companies via ImportCustomersNot possible. Companies must be created via ImportCompanies first.
Re-importing after anonymizationA scheduled sync from ERP can inadvertently re-populate anonymized records. Coordinate anonymization across all systems.
Wrong application-unique settingChoosing application-unique when a shared CRM exists (or vice versa) causes duplicate records or unexpected merging. Align the setting with your system landscape before the first import.

Further Reading