B2B self-service portal: buyer roles and repeat orders

A buyer repeats a previous order, but now works with a different branch, and some products are sold in new pack sizes. If a B2B self-service portal simply copies the old cart, the error carries over into the purchase. A reliable customer account first checks which company the person is acting for, what they are allowed to do, and which terms apply now. These are the rules worth documenting before choosing a platform and design.

The main question is which routine purchases a customer can make without an account manager and where the process needs to stop. We will look at roles and delegation for existing buyers, not supplier registration or approval of a commercial proposal.

Start with the company, branch, and individual

One legal entity may have several delivery locations and different purchasing staff. Do not reduce them to a single “purchasing department” login. The company defines the contractual context, the branch determines the available product range and address, and the user identifies who performed a particular action. These relationships are needed both for convenience and for investigating errors: who created the order and for which department.

The Shopify B2B documentation describes a company, its location, and the buyer as separate entities. A location can have its own prices, addresses, and payment terms. This is an example of a data model, not a requirement to choose Shopify. For your portal, first establish where these relationships are already stored and who is entitled to change them.

Display the active branch beside the cart. After a context switch, check the address and price list again. Access to a branch alone does not confer the right to make purchases on its behalf.

Separate operational roles and delegation boundaries

Buyer roles in a B2B customer account should be built around actions, not job titles. A person may view the catalogue, prepare a cart, place a purchase order, read invoices, or manage colleagues. These are different permissions. In Adobe Commerce, for example, company permissions separately cover checkout, viewing orders, and user management. The specific set depends on the solution and configuration.

Refine the illustrative starting matrix below together with buyers. “Subject to a rule” means a separate configuration, not automatic access.

The customer administrator must not grant themselves every permission

Delegated administration means the customer maintains their own staff list, but only within boundaries set by the seller. Document which roles they may assign, which branches they may add people to, and whether they may create another administrator. If the right to manage colleagues automatically grants the right to spend money, the boundary of responsibility becomes unclear.

An invitation should lead to an individual account and have a defined acceptance deadline. For temporary cover, store the date the authority expires and who granted it. Do not address a buyer’s holiday by sharing their password. After the employee returns, temporary permissions must end according to a predefined rule.

Check permission at the moment of action

OWASP distinguishes authentication from authorization: a successful login confirms identity, not permission to perform any operation. For a portal, this means checking access to the specific order, document, and branch on the server. A hidden button is no substitute for this check.

A separate scenario is an employee being blocked while their cart is already open. The system must check their authority again before submission rather than trust the old screen. Likewise, check invoice downloads via direct links. A role change must affect access, not just the appearance of the menu after the next login.

Repeat the purchase contents, not the previous terms

Reliable reordering starts with a new draft based on order history. The old document remains a historical record, while the new cart is checked against current rules. The price, minimum order quantity, pack-size multiples, product availability, and address may have changed. The buyer should see the difference before submission, not after receiving an invoice.

Divide the check results into clear groups: ready to purchase, needs correction, and unavailable. Each problematic line needs an explanation and an action. “Unable to reorder” does not help explain whether the SKU has disappeared or catalogue access permission is missing. Do not substitute a similar product or round the quantity up to a full pack without an explicit decision by the user.

Even ready-made platforms have nuances in how reordering behaves. The Adobe documentation on reorders describes availability checks and the fact that products already in the cart may remain after a reorder is added. So, during acceptance testing, do not test only an empty cart: establish whether the system adds lines, merges them, or creates a separate draft.

Hypothetical example: a replacement buyer and a new pack size

Suppose a chain of workshops orders consumables from a distributor. This is a training scenario, not a GL.ua case study. The buyer for the “North” branch is on holiday, and a colleague is temporarily covering for her. He has been allowed to buy only for this branch until a specified date, without access to invoices from other departments or the right to invite new employees.

The colleague opens a previous order: gloves, wipes, and cleaner. The gloves now ship in different pack sizes, the cleaner is unavailable, and the wipes can be purchased on current terms. The correct result is a new draft with all lines and highlighted discrepancies. The wipes are ready; an allowed quantity must be chosen for the gloves; the cleaner must not silently disappear from the purchase.

After corrections, the buyer sees a summary of changes and confirms the new contents. If he switches to the “West” branch, the portal does not allow the cart to be used beyond his granted authority. If the cover period expires before submission, the action stops with an explanation. The account manager receives an exception request but does not have to manually reconstruct the entire purchase from correspondence.

Acceptance criterion: the purchase is made on behalf of the correct branch, a prohibited action does not create a document, and changes are not lost. Also define who receives the drafts when the cover period ends.

After clicking the button, the buyer needs a definite outcome

Self-service does not end with a “request sent” message. Show acceptance by the portal, transfer to the back-office system, and order confirmation separately. If the response is delayed, explain the current state and next action. The buyer should not have to guess whether to click again or call the account manager.

In the technical specification, define a shared operation identifier and a rule for recognizing resubmissions. This is a proposed integration requirement, not an automatic feature of every portal. Test the situation where the back-office system accepted the document but its response did not arrive. A retry should first establish the outcome rather than unconditionally create a new order.

Responsibility boundaries between systems should be considered separately from buyer roles. If it is unclear where the authoritative status is stored, the article on when an online store needs an OMS can help. A non-standard purchase with individual terms belongs to a different process: B2B proposal approval. Do not combine these routes in a single “reorder” button.

Run a pre-launch test using operational roles

For the pilot, choose existing customers with routine purchases. Prepare anonymized history, test accounts, and expected outcomes. A demonstration using an administrator account does not prove branch isolation.

1. Log in as a buyer from one branch and try to open an order from another, including via a direct link. The expected outcome is denial without disclosing the document.
2. Invite a colleague through the buyer administrator. Check the permitted scope and an attempt to grant broader permissions than the administrator is entitled to delegate.
3. Open the cart, then revoke checkout permission. A submission attempt must undergo a fresh check and end in a controlled denial.
4. Repeat a purchase with changed prices, pack sizes, and availability. Check every line and explanation; also test a non-empty cart.
5. Simulate a lost response after the back-office system accepts the document. Check the retry, outcome lookup, and absence of an extra order.
6. End the cover period, block the user, and check access to documents. Check the action log and the handover route for unfinished drafts.

Assign owners and repeat tests for deviations. Access to other people’s documents, purchases beyond granted authority, or silent loss of lines are reasons to postpone launch.

How to contain timelines, costs, and operational risks

Timelines depend on the readiness of the company directory, the quality of order history, and the rules in your ERP — enterprise resource planning system. First test one end-to-end purchase using test data. Then expand roles, branches, and exceptions. A calendar estimate made before integration testing hides the main uncertainty: whether current terms and an unambiguous submission outcome can be obtained.

Include permission analysis, cleanup of customer–branch relationships, a discrepancy interface, integration, access tests, logging, and training in the estimate. Assess support, licences, infrastructure, and post-launch rule changes separately. Do not confuse savings on manual entry with a guaranteed reduction in all costs: some work will shift to maintaining data and access.

If routine purchases are infrequent and terms are individual every time, a full portal may be premature. Start with personal order history and controlled draft creation. Complex branch structures require a more flexible solution, but choosing Drupal or another platform does not itself create the right permissions model. It will need to be designed and tested.

After the pilot, measure the share of purchases completed without manual intervention and the reasons for stoppages. Compare the same types of orders to distinguish an interface problem from an outdated catalogue.

Start with a map of authority and one complex reorder, not a list of desired widgets. To discuss B2B customer account development with GL.ua (Glyanets), prepare your branch structure, a list of roles, and an anonymized example of a purchase with changes. This provides a basis for defining the pilot’s scope and making a concrete assessment of the integration.