Where commerce fits for a Cin7 partner

More than most partners assume, and Cin7’s own help documentation is specific about it. Read on 20 August 2026, the B2B portal settings article describes portals that can be created more than one at a time and selected from the top of the screen, each with its own domain name that can be changed later, a location assigned for fulfilment, an assigned sales representative, and contact details in the footer.

On pricing display, the portal lets you set the price listA price list is a named set of prices that can be attached to customers, groups or currencies. ERPs and commerce platforms both use the term, and they rarely mean exactly the same thing by it. tier shown to guest users, or hide prices from guests entirely, and separately set a tier used to show a recommended retail price, which defaults to not showing one. Customers can download a custom price list. Guest visitors reach the home page only; placing an order requires an accepted invitation.

On catalogue behaviour, the settings cover whether backorders are allowed, whether out-of-stock items are visible, whether minimum and maximum order quantities are displayed, how product families are presented as separate products or as a matrix, sorting options, and whether customers see only their own attachments.

On payment, the documentation lists eight payment method types including cash on delivery, money transfer, purchase order and customer credit, with third-party options covering PayPal, Stripe, Authorize.net, QuickBooks Payments, Pinch and Cin7 Pay. Taking payment on account requires the sale to be created as an authorized invoice. The portal needs at least one active shipping method before it can be activated.

That is a working wholesale ordering channel. A partner who dismisses it has not read the settings page.

When the client matches this profile, tell them to switch it on and spend the difference on product photography. This is the honest recommendation and it is the one that makes your next recommendation believable.

The profile: a wholesaler or brand selling a catalogue in the hundreds rather than the tens of thousands, priced from tiers rather than from individually negotiated agreements, to buyers who already know what they want and are reordering. Fulfilment runs from one location. Nobody in the business owns marketing for the trade channel and nobody wants to. There is no requirement for public search visibility, because the buyers are invited rather than found.

For that client, an external commerce platform adds licence cost, an integration to build and maintain, a second system to support, and a content practice they do not have. It buys them presentation and control they have not asked for. Switching on a portal they already pay for is a better use of the same money, and a Cin7 partner recommending it will be trusted the next time they say a project needs more.

Pricing depth first. Cin7’s help documentation says Cin7 Core supports up to 10 price points for each individual product, with tiers assigned on the customer record or on an individual order, and order-level assignment taking priority. Alongside tiers there is a separate custom pricing feature for setting specific product prices for selected customers, which takes precedence over standard pricing, plus discounts at product, customer group and individual customer level and a blanket percentage discount per customer.

What Cin7’s pricing and price tier documentation does not describe is quantity-break pricing, so a client who needs a different price at 10, 50 and 200 units should have that tested rather than assumed, and tested before anything is promised. This is the requirement that most often turns a Cin7 Core portal conversation into a platform conversation, and it turns up late because clients describe it as "our usual volume discount" rather than as a pricing model.

Then product content and search. The portal presents what is in the item record. A trade buyer who knows the code is well served. A buyer who is searching by application, specification or fitment is not, because there is no place in the ordering system for the content that would answer them, and no tooling for the people who would write it.

Then everything that involves control. Multi-brand and multi-region presentation, marketing pages, landing pages for campaigns, custom checkout steps, quote to orderQuote to order is the process where a buyer asks for a price, a person or a system prepares a quote, and the accepted quote becomes an order. In much of B2B it is the normal way to buy, not an exception. with approval routing, punchoutPunchout is a way for a buyer to shop on a supplier’s website from inside their own procurement system. The buyer clicks out, builds a cart, and the cart is returned to their system as a requisition for approval. and EDIEDI, or electronic data interchange, is a long-established set of standard message formats businesses use to exchange purchase orders, invoices and shipping notices system to system. Large retailers and distributors often require it from their suppliers. buyers, and any front end the client wants to change without raising a ticket. A portal that is part of an inventory system will always be shaped by the inventory system, which is the correct trade-off for the client above and the wrong one for a client whose channel is a growth strategy.

Cin7’s own end of life page for Omni modules and integrations, read on 20 August 2026, lists Legacy B2B (v1) with an end of life date of 23 November 2026 and an end of support date of 31 October 2023. The same date applies to Products v1 and CRM v1. Pick n Pack is listed with its end of life date still to be confirmed.

The support date matters as much as the end of life date. Legacy B2B has been out of support since October 2023, so any Omni client still on it has been running an unsupported ordering channel for close to three years, and the November date is the point where it stops working rather than the point where the risk begins.

The part partners miss is that this is not only a portal migration. Products v1 and CRM v1 retire on the same day, which means any integration built against those APIs needs work in the same window. A client with a Legacy B2B portal and a middleware integration reading Products v1 has two projects, not one, and the second is invisible until someone audits the integrations. Do that audit now rather than in October.

There are two honest paths and the choice is not close for most clients. Moving to Omni’s current B2B online store is the low-friction path and suits clients whose portal is an ordering channel. Moving to a commerce platform is the right answer where the client’s trade channel is a growth strategy, where they need content, search and campaigns, or where pricing has outgrown what the portal models. Decide it on those grounds rather than on the deadline, because a deadline-driven migration lands the client in the same place 18 months later.

Wider than most Cin7 partners claim and narrower than an agency will tell the client. Four pieces are yours by default.

The pricing setup is yours, because it lives in Cin7 and because getting tiers, custom pricing and discounts to agree with what sales actually promised is a Cin7 problem before it is a storefront problem. The product data is yours to structure, even where someone else writes the copy, because families, units of measure and codes are decided in the inventory system. The order and fulfilment flow is yours end to end. And the availability logic is yours, because what "in stock" means for a client running assemblies or multiple locations is a Cin7 question with a Cin7 answer.

What is not yours by default is the storefront experience, search, content operations, and anything requiring a front end nobody at your firm maintains. Those are real disciplines with real staffing implications, and a Cin7 practice that takes them on casually ends up with one developer who cannot go on holiday.

The split that works is that the partner owns everything inside Cin7 and the interface it exposes, and requests for changes inside Cin7 come through the partner rather than being made by whoever is building the storefront. Write that down before anyone is introduced to the client.

Take 20 of the client’s real customer and item combinations, chosen by the sales manager rather than by you, and weighted towards the awkward ones. Include at least three with a quantity break if the client claims to have them, two priced in a second currency if they sell in one, and two sold in a unit of measure other than the base unit.

Set each one up in a Cin7 sandbox using tiers, custom pricing and discounts as documented, then look at the portal or the storefront signed in as that customer and compare the displayed price with what the client says the customer should pay. Record each one as a match, a mismatch or a workaround.

Anything in the workaround column is a maintenance commitment, not a solved problem. Two workarounds are usually tolerable. Six mean the pricing model does not fit the tool, and that is a finding worth being paid for and worth delivering plainly.

Run this before the platform conversation rather than after it. A partner who arrives at the platform discussion with 20 tested price combinations is in a different conversation from one arriving with a feature comparison.