User roles and permissions in a B2B ordering portal: how NZ wholesale distributors manage multi-contact accounts

A single shared login is how most wholesale distributors start with a B2B portal. One username and password per customer account, shared by whoever happens to be placing orders that week. It works fine when a customer has one buyer and one person who cares about order history. It stops working when the account has a purchasing manager, a warehouse team, a finance contact who needs invoices, and two branch locations — all of whom need different levels of access, and none of whom should be sharing credentials.

User roles and permissions are one of the most under-specified requirements in B2B portal projects. They rarely surface in early conversations because "who can log in" seems obvious, but the operational reality for most wholesale accounts is more complex than it appears. Getting the model right before go-live avoids a class of problems that are awkward to fix once customers are already using the system.

The account vs the user: two distinct layers

The starting point is separating two concepts that are often conflated in early portal discussions: the trading account and the user login.

The trading account corresponds to the debtor record in your ERP — a single customer entity with its own credit limit, pricing tier, delivery address set, and order history. This is how your business thinks about the customer. It maps one-to-one with the record your accounts team manages in Accredo, MYOB, or whichever ERP you run.

A user login is an individual person who has been granted access to that account on the portal. One trading account can have multiple users. Each user has their own email address, their own password, and their own role that determines what they can do within the account.

This separation matters because the account is the unit of trust from your ERP's perspective — it holds the credit limit, the pricing, the delivery rules. The user is the unit of access control from the portal's perspective. Both layers need to work together: a user's permissions are bounded by what their account is entitled to, and the account's rules apply regardless of which user is placing the order.

Common user roles in a NZ wholesale portal

The exact role names vary by implementation, but most production wholesale portals settle on three or four distinct permission levels:

Account administrator

The administrator has full access to the account. They can place orders, view the full order history across all users on the account, manage other users (invite, assign roles, deactivate), and update account-level settings such as preferred delivery addresses and notification preferences. Most accounts have one or two administrators — typically the purchasing manager or business owner.

The administrator role is also the one your customer service team interacts with when account changes need to happen. If a customer calls to add a new staff member, your team points them to their administrator — or, if the administrator has left the business and no one else has that role, your team steps in to reassign it.

Buyer

A buyer can browse the catalogue, place orders, and view their own order history. They cannot see orders placed by other users on the account, cannot manage other users, and cannot change account-level settings. This is the right default for most purchasing staff — they need to order, not to administer.

Depending on how the portal is configured, buyers may also be subject to order approval — their orders are submitted but held for an administrator to confirm before passing to the ERP. This is the model for accounts where purchasing authority is internally managed, or where orders above a set value require sign-off.

Read-only / viewer

A read-only user can log in, view the catalogue and pricing, and see order history — but cannot place orders. This role is useful for a few specific scenarios: a finance contact who needs to download invoice records from the portal, a business owner who wants visibility without being in the ordering workflow, or an account that is being onboarded and has not yet completed credit approval. Read-only access lets the customer familiarise themselves with the portal before they can transact.

Sales rep (internal)

Some wholesale portals include an internal role for your own sales reps — staff who can log in on behalf of a customer account to place or check orders. This is distinct from customer-facing roles: a rep using this login is identified as acting on behalf of the account, not as the account itself. The order history shows who placed the order (the rep or the customer), and the rep's access doesn't expose other customers' data. This is relevant for distributors where reps still take orders by phone or on the road and enter them through the portal on the customer's behalf.

Order approval workflows

An approval workflow adds a confirmation step between a buyer submitting an order and that order being passed to your ERP and warehouse. The buyer places the order; it sits in a pending state; the account administrator — or a designated approver — reviews it and either confirms or rejects it. Only confirmed orders flow through to your ERP.

This is useful in several common scenarios for NZ distributors:

• A hospitality or food service account with multiple site managers who can order, but whose orders need sign-off from the head office purchasing manager before confirmation.
• An account that has given ordering access to a warehouse team who raise replenishment orders, with a business owner who wants to confirm before anything is committed.
• A policy of requiring approval for orders above a certain value threshold — routine top-up orders proceed automatically; large orders need a second pair of eyes.

The approval workflow is separate from your credit limit check. Both can apply to the same order: a buyer's order might be held for approval, and then when the approver confirms it, the portal checks the account's credit position before passing it to the ERP. They are complementary controls, not alternatives.

For distributors managing credit carefully, the approval workflow also reduces the risk of a buyer committing the account to an order that pushes it over its limit — the approver can catch this before the order is confirmed. How credit limits and approval workflows interact in a well-designed portal is covered in detail in our credit limit management guide.

User management: who controls access

There are two approaches to who manages the user list for a customer account, and both have trade-offs.

Customer-controlled. The account administrator can invite new users, assign roles, and deactivate access without involving your team. When someone joins the customer's business, the administrator adds them. When someone leaves, the administrator deactivates them. Your customer service team is not in the loop for routine changes, which scales much better as your account base grows.

Distributor-controlled. All user management goes through your customer service or operations team. A customer calls or emails to add someone, and your team creates the login. Every change is handled internally. This gives your team complete visibility and control, but it creates a bottleneck — and at scale, it becomes a material operational cost.

Most NZ wholesale portals use a hybrid: the customer's administrator manages day-to-day user changes, but your team retains the ability to override, reset, and deactivate any account at any time. This means your team is never locked out, but you're also not the gatekeeper for every routine access change.

The go-live user setup problem

A detail that creates friction at every portal launch: who sets up the initial users for each customer account?

At go-live, your portal has accounts but no users. Each customer needs at least one person — ideally the account administrator — to be invited and activated before they can log in. This sounds simple, but across 200 or 300 customer accounts, it is a meaningful operational task. Three approaches work:

• Bulk invitation. The portal sends an automated invitation email to a nominated contact email address for each account — typically sourced from your ERP customer master. The nominated contact receives a link, sets their password, and is automatically assigned the administrator role. They can then invite their own team from there. This is the most scalable approach and avoids manual setup for each account.
• Phased customer activation. Rather than inviting all customers at once, you activate accounts in batches — starting with your most tech-comfortable accounts or your highest-order-volume customers. Each batch gets direct onboarding support. This is slower but produces better activation rates than a bulk email, particularly for customers who are less familiar with self-service ordering.
• Manual setup by your team. Your customer service team creates logins for key accounts directly. Only practical for a small account base — it does not scale to hundreds of accounts.

The go-live approach feeds directly into the customer-facing experience of the launch. A portal that works beautifully but that customers haven't been properly onboarded to doesn't generate adoption. User setup is a project management task as much as a technical one, and it needs to be planned before go-live, not after.

Four failure modes to design out

These are the predictable problems that appear when user roles are treated as a configuration afterthought rather than a design requirement:

• Shared credentials. One username and password shared among an entire buying team. When something goes wrong — an order placed incorrectly, a dispute about who authorised something — there is no audit trail. Individual logins are not a feature, they are the mechanism for accountability.
• No account administrator left on the account. A purchasing manager who is the only administrator leaves the business. No one at the customer can add new users, deactivate the departed employee's login, or change the notification email. Your team gets a call asking you to fix it. Preventable by ensuring every account has at least two administrators, and by giving your team a clear override path when it happens anyway.
• Approval workflow disconnected from ERP flow. Orders held for approval sit in the portal but are not visible in the ERP. If your warehouse picks and packs from ERP orders, pending-approval orders don't appear — and if they're approved at 4pm and you have a cut-off at 3pm, the order may not make the run. Approval workflow timing needs to connect to your order cut-off rules and delivery scheduling logic.
• No read-only path during onboarding. A new customer completes credit approval, their account is activated, but their buyer login is live before you've confirmed their pricing is correct. The customer can see the wrong price and place an order. A read-only activation state during onboarding — where the customer can browse but not order until you've confirmed the account setup — prevents this class of error.

What to resolve before build starts

User roles and approval workflows sound like portal configuration, but the decisions behind them are business policy decisions that need to be made before the build starts — because they affect the data model, the ERP integration, and the customer-facing onboarding flow.

The five questions worth answering early: which role types your account base actually needs (administrator, buyer, read-only, rep); whether approval workflows apply to all accounts or only specific account types; who owns user management (customer admin, your team, or hybrid); how go-live user setup will work across your full account base; and what the escalation path is when a customer's administrator access becomes unreachable.

These decisions connect directly to the other account-level controls a production wholesale portal manages. How the portal surfaces per-customer catalogue visibility, resolves customer-specific pricing, and enforces credit limits all operate at the account level — and the user roles layer sits on top of all of them, controlling which people within an account can act on what the account is entitled to.

The Provender B2B ordering platform that Zeabyte builds and operates includes a full user role and permissions system — account administrators, buyers, read-only users, and internal rep logins — integrated with the Accredo debtor model and the other ERP and accounting systems Zeabyte connects to. If you're scoping a B2B ordering portal for your wholesale or distribution business and want to understand how user management would work for your specific account structure, reach out to the Zeabyte team.