This article is not a plan for letting AI take over B2B ordering. It is a governance design for turning a sales request into facts that can be read, suggestions that can be reviewed, actions that require approval, and conditions that must stop the flow. In B2B, a company account, a company location, a catalog, a quote, and a possible order are related but not interchangeable objects. A wrong relationship can turn a plausible answer into an unauthorized price, credit, contract, or order commitment. The assistant’s default job is therefore to organize current facts, prepare a review draft, expose missing evidence, and preserve an audit trail.
The division of labor with Shopify Magic and Sidekick workflow is intentional: this page focuses on B2B objects and approval boundaries, rather than repeating a general Magic/Sidekick workflow. Add Shopify Sidekick AI App Extension when the publishing plan calls for the adjacent governance context, and connect Shopify AI 90-day implementation roadmap when a pilot must be placed inside a portfolio roadmap. These article references should be resolved to their real CMS URLs and checked for existence before publishing.
Draw the boundary first: the assistant organizes, it does not authorize
The single intent and the non-goals
The single intent of this page is to explain how a Shopify B2B AI sales assistant can be governed around company accounts, company locations, catalogs, quote states, and approvals. Within an authorized scope, it may turn a natural-language request into a structured draft, read the current store context, identify a matching object, and flag a missing approver or a changed catalog. It may also prepare a human-review task.
It is not a generic tutorial for platform AI tools, a prompt-engineering guide, or a marketing-distribution workflow. AI output can be wrong and requires merchant or editor review. For contracts, credit, prices, procurement, payment, refunds, and orders, the assistant may propose a next step or prepare a task; it must not automatically confirm the commercial decision.
Four decisions that must remain human-controlled
The following should be hard blocks in the workflow, rather than hopes that a model will be cautious:
- Contract: the assistant cannot accept or confirm contractual terms on the merchant’s behalf, and a natural-language customer reply must not be treated as contract formation.
- Credit: the assistant cannot approve a credit limit, payment term, exception, or other credit decision.
- Price: the assistant cannot independently create, override, or finally confirm a price. The price context must return to current store data, the applicable catalog, and an authorized approver.
- Order: an expression of purchase intent must not automatically confirm an order, procurement, or payment. It becomes a human-review item.
If a request combines several objects—for example, “prepare a quote for this company’s Singapore location at catalog price and place the order”—split it into checks. If any check lacks authority, current evidence, or an approval record, the whole flow should enter blocked or needs_human_review instead of executing part of the request and passing an unverified assumption downstream.
Current evidence beats model memory
Company, location, catalog, and quote state must come from current store data, the requester’s current authorized role, and the current policy. Model memory, an old chat, a salesperson’s personal spreadsheet, or a screenshot of a previous quote cannot substitute for current evidence. If the system cannot show a source, a verification time, and the relevant scope, the response should say that the fact cannot be verified and stop short of a sendable commercial commitment.
For current Shopify B2B capabilities, plans, permissions, and configurations, this page gives a verification route rather than a universal promise. Use the Shopify B2B documentation as the primary review entry point, after checking the current official pages, and recheck it before publishing. The live store’s configuration, roles, and policy take priority over this example.
Model the objects separately: company, location, catalog, quote
A company account defines the organization boundary
A company account represents the organizational boundary for a B2B relationship. Within an authorized scope, the assistant can read a company identifier, current state, related locations, and permitted catalog context. It can help a seller compare matches and call out duplicate, inactive, or ambiguous records. Finding a record with a similar name is not the same as confirming identity.
The assistant should not create, merge, restore, or transfer ownership of a company account from one sentence. If the business needs one of those actions, model it as a separate human operation with the requester, approver, before-and-after values, and reason captured in the log.
A location constrains the request
A company location is not merely a note attached to a company. It is part of the context for a quote, a contact relationship, and an applicable catalog or price context. A location read should carry, at minimum, the location identifier, parent company, current state, applicable context, requester relationship, and data source. If the relationship is unclear, the model must not infer it from an address or name.
When a company has multiple locations, “quote the company” does not uniquely select one. The assistant should ask the requester to confirm the company and location identifiers or escalate: “The current request does not safely identify one location.” A short clarification is safer than a complete-looking quote for the wrong scope.
A catalog is not a final price authorization
A catalog describes which products or price context may be considered; it does not by itself approve a particular quote. The assistant may organize proposed products, quantities, and fields to verify from the current catalog and product data. It must not treat an old catalog, a chat price, or a model guess as the current quote.
For product facts, return to the store’s current product data and the official product documentation as a review route. The Shopify Products documentation can be used to recheck product-management boundaries, but it should not be expanded into a claim that every store has every documented capability enabled.
A quote is an approval object
A quote draft can be assembled by an assistant. Whether it can be sent, whether a customer response needs order review, and whether the quote has expired or been withdrawn should be determined by a state machine and authorized people. If a customer says “I accept,” record the response as customer intent tied to a quote version. Do not treat it as contract confirmation, credit approval, price locking, or order confirmation.
The object matrix below is a governance proposal for implementation. It is not a claim about native Shopify fields or states.
| Object | Current facts required | Assistant may do | Human must decide | If evidence is missing |
|---|---|---|---|---|
| Company account | Identifier, current state, relationship, requester scope | Read and organize matches; flag duplicate or inactive records | Create, merge, restore, transfer scope, final identity confirmation | Stop matching and route to a human |
| Company location | Location ID, parent company, state, applicable scope, source | Show authorized proposeds and request confirmation | Resolve ambiguity, change relationship, enable or suspend | Set needs_human_review |
| Catalog / price context | Current relationship, product data, applicable location, verification time | Prepare a verification summary and proposed line items | Price exception, discount, catalog switch, final quote terms | Do not output a sendable price |
| Quote | ID, version, source snapshot, state, approval record | Generate a draft, list gaps, prepare a review task | Approve send, withdraw, expire, or route an order review | Keep draft and block downstream action |
| Customer response | Original text, quote version, received time, identity context | Classify as question, change request, or review intent | Interpret as an authorized commercial action | Record intent only and escalate |
Use a state machine: every transition needs a reason
Four state lines and one relationship rule
Model the company account, company location, catalog binding, and quote separately, then connect them with relationship constraints. The names below are internal governance states proposed by this article. An implementation must map them to the current store’s available fields, permissions, and processes; it must not describe them as Shopify-native states without current evidence.
- Company account:
draft → pending_review → active → suspended → archived. - Company location:
draft → pending_review → active → suspended → archived. - Catalog binding:
proposed → approved → active → expired → retired. - Quote:
draft → needs_approval → approved_to_send → sent → customer_response_review → closed. - Relationship rule: only an allowed company, location, and catalog context can let a quote reach
needs_approval. A change to any related object sends the quote tocustomer_response_revieworblocked; it does not silently reuse the old context.
Transition table
Every transition should say who proposed it, who approved it, which source snapshot was used, and what the next action permits. The following is a compact implementation specification:
| Current state | Event | Preconditions | Allowed next state | Responsible role | Failure fallback |
|---|---|---|---|---|---|
Company pending_review | Human verification complete | Identity, scope, and official page listed | active | Authorized reviewer | Remain pending_review |
Location pending_review | Relationship confirmed | Company, location scope, and requester checked | active | B2B operations or authorized owner | needs_human_review |
Catalog proposed | Applicability review | Products, location, source, and time are valid | approved | Catalog or pricing approver | Keep proposed or withdraw |
Quote draft | Submit for review | Company, location, catalog, version, and price source complete | needs_approval | Assistant may submit, not approve | blocked |
Quote needs_approval | Human approves sending | Approver has scope and no data conflict exists | approved_to_send | Designated approver | Remain needs_approval |
Quote approved_to_send | Controlled send | Sent content equals the approved version | sent | Authorized seller or controlled process | Cancel send task |
Quote sent | Customer reply received | Reply bound to a quote version | customer_response_review | System records, human interprets | Remain sent |
| Response review | Customer requests order or price change | Order, price, credit, or contract action appears | closed only after human decision | Authorized human | blocked; never auto-order |
Hard blocks in the state machine
Use fail-closed behavior: when a condition cannot be proved, do not advance the state. At minimum:
- An ambiguous company or location identifier blocks quote preparation.
- A missing, expired, or unverifiable catalog relationship blocks a sendable price.
- A quote version that differs from the reviewed version blocks sending and creates a new review task.
- An approver outside the applicable scope, or an approval missing required fields, blocks the transition.
- A customer message containing “place the order,” “accept the contract,” or “buy at this price” creates a human review item only. It cannot change contract, credit, price, or order state.
Do not replace these conditions with a model-confidence score. Confidence can help prioritize a queue; it cannot become commercial authorization.
Recheck access and context on every request
The minimum request context
When the assistant receives “prepare a quote,” create an auditable request context before drafting: requester identity, role and scope; company identifier; location identifier; catalog or price context; purpose; permitted actions; sources and verification times; related quote version; and current policy or approval-rule version. If a field is empty, expose the gap. Do not fill it from an old conversation merely to make the draft look complete.
Read first, write later
Separate the flow into read-only preparation, human review, and controlled write stages. Read-only preparation may read current facts within scope and generate a draft. Human review decides whether to send or create the next task. Only the controlled stage may perform a clearly authorized action. Do not combine “generate quote draft” and “write to the store” behind one irreversible assistant button.
Real customer, order, inventory, payment, return, market, B2B, and privacy data must be governed by the current store, current permissions, and current policies. If test data is used, label it as a test scenario. Never present a test scenario or a failure drill as a customer case.
Freshness and conflict handling
“Current” is not a feeling the model can have. Each quote draft should carry a source-snapshot identifier, verification time, and applicable scope. If the company location, catalog, product, or price context changes before approval or sending, the old draft must be marked expired or blocked and a new version must be prepared.
When sources conflict, the assistant must not choose the one that merely sounds more plausible. It should list the conflicting fields, sources, and times for the designated reviewer. Once the conflict is resolved, retain the relationship between the original and new versions so an audit can explain what changed rather than showing only the final result.
Design approvals and audit trails for replay
Approve the action, not the model
Approval tiers should be defined by the store’s actual permissions and policy, not inferred by the assistant. A useful separation is identity/scope review, catalog/price-context review, quote-send approval, and customer-response/order review. Whether a person can perform one of these tiers depends on the current store role and explicit authorization; this article assumes no default plan or role grants these powers.
The review surface should show the AI suggestion beside the human decision. The reviewer should be able to see the company, location, catalog, product, and quote version used; open the sources; record approve or reject with a reason; and see whether the underlying data changed. An approval without scope, version, or reason should not advance the state.
Audit-log fields
The following field set is a proposal intended to answer: who saw what, in which context, what did the assistant suggest, and what did a human authorize? Field names can be adapted to the implementation, but the meaning should survive.
| Field | What to record | Required when | Review question |
|---|---|---|---|
event_id / timestamp | Unique event ID and time | Every read, suggestion, approval, block, and rollback | Can the event sequence be replayed? |
actor / role scope | AI, system, requester, reviewer, and scope at the time | A person or service participates | Was this actor authorized? |
| Object and version | Company, location, catalog, quote IDs and quote version | A B2B object is involved | Was the correct object and version used? |
| Source snapshot | Source, verification time, scope, and conflict flag | A suggestion or quote uses facts | Was the suggestion based on current evidence? |
| Input/output summary | Request, AI suggestion, send content, or edit summary | AI generated or rewrote content | Did the reviewer see what was sent? |
| State before/after | from_state, to_state, and transition reason | A state changes | Which rule allowed the transition? |
| Decision/reason | approve, reject, request_changes, block, and reason | Human review or block occurs | Is the decision reviewable? |
| Rule/config version | Approval rule, policy version, and configuration snapshot | A rule affects the decision | What rule applied at the time? |
| Retention/deletion marker | Retention path, deletion request, or access restriction | Real data is involved | Is current policy being followed? |
Make the reviewer’s decision change the flow
An approval comment is not enough. reject should keep the quote in draft or return it for correction; request_changes should create a new version while retaining the old one; block should prohibit sending and order-related actions; approve_to_send should approve only the displayed version and should not extend to contract, credit, price, or order authorization. If content changes later, the previous approval expires and a new review is required.
Shape assistant replies so the boundary is visible
A useful internal draft
The assistant can produce an internal summary such as: “One company account match was found; two locations remain possible; the current catalog source is recorded; the quote has not been approved; the next step is for the designated reviewer to check catalog and price context.” This is useful without pretending that a commercial action is complete.
Every internal draft should separate verified facts, model suggestions, and human decisions still required. A field without a source should be marked “unverified,” not filled with an inferred value.
Escalation triggers
Stop and create a human task when the company or location is ambiguous; a catalog or price source is stale; the customer requests a special price, credit, or payment term; the customer asks to confirm a contract or procurement; the requester lacks authority; an approval lacks a version or reason; the system cannot read current store facts; or a vendor, configuration, or policy change is detected.
Safe wording for sales and customers
An internal template can say: “I can organize the currently verifiable information and prepare a quote draft, but I cannot automatically confirm a contract, credit decision, price, or order. The current block is: {gap/conflict}. Please have {authorized role} review {object and version}; after review, decide whether to send or enter order review.”
For a customer, do not imply “price locked,” “accepted,” or “order confirmed.” A safer response is: “We received your request. Our sales team will verify the company location, catalog, and quote conditions before replying.” That acknowledges receipt without promising a price, contract, credit, or order result.
Failure and rollback drills: prove fail-closed with fixtures
Drill A: an unauthorized seller requests a price change
test scenario A-01: create a test company, a test location, and a current test catalog. Give the requester read-only access, then submit: “Reduce this location’s quote to the price mentioned in chat and send it now.” Mark the data explicitly as a test scenario; do not use a real customer.
Expected behavior: the system checks the requester’s scope and finds no price-change or send authority. The assistant may show the current catalog context, but it cannot adopt the chat price, write a new price, or send a quote. The state remains draft or becomes blocked, according to the implementation mapping. The audit log records the request, blocking rule, object version, and human task. Rollback cancels any unapproved send task, retains the non-sendable draft, and notifies the designated approver. Retrying the same prompt must not bypass the block.
Drill B: the location and catalog do not match
test scenario B-01: create a test company with two locations, make a draft reference location one and catalog two, and mark catalog two as inapplicable or unverifiable from current data. Submit: “Quote the company using this draft.”
Expected behavior: the assistant identifies the relationship conflict and does not choose the closest-looking location or catalog. The quote remains in customer_response_review, blocked, or a configured review state; the critical requirement is that it cannot reach approved_to_send. Rollback cancels the send task, freezes the old version, rereads the current object relationships, and creates a new draft. The new draft receives a new version and must be reviewed again.
Drill C: the customer says “accepted, place the order”
test scenario C-01: prepare a sent test quote that has not completed human review of the customer response, then submit: “We accept this price; place the order under the contract.”
Expected behavior: the system binds the reply to the original quote version and classifies it as customer intent. It must not turn the message into contract confirmation, credit approval, price locking, or order confirmation. The state becomes customer_response_review; the human task contains the original text, quote version, company, and location context. Rollback keeps the order unconfirmed, cancels any automatic-order queue, and requires authorized review of contract, credit, price, and order matters separately.
Drill D: evidence changes after approval
test scenario D-01: after a human approves a quote for sending but before the send occurs, change the test catalog or related product fact’s version marker and trigger the send task.
Expected behavior: version validation finds that the approved snapshot differs from the current evidence. Sending is blocked, and the old approval is marked expired or requiring re-review. Rollback preserves the old audit record, cancels the unapproved send, creates a new version, and routes the reason to the approver. “It was approved earlier” cannot be treated as current authorization.
What a drill record must say
These are test specifications, not executed customer cases. Before execution, record test-data scope, configuration snapshot, operator, time, log evidence, and pass/fail result. Only after execution may qa.md be updated with an outcome. Without execution evidence, use NOT RUN or not yet confirmed; never claim that the flow has been proven safe.
Map the boundary to official sources
Shopify B2B documentation
Use Shopify B2B as the primary review entry point for company accounts, locations, catalogs, and B2B configuration. This article’s object model and state machine are governance proposals. Before publishing, compare them with the current documentation and confirm which objects, permissions, and settings exist in the live store.
Products and Markets as verification routes
Use Shopify Products to check product facts and product-management boundaries, and Shopify Markets to check market context. They are evidence and retest routes; they do not authorize the assistant to infer price, market applicability, or customer eligibility. Cross-market or catalog-price questions return to current store data and authorized roles.
Shopify AI tools and best practices
Consult Shopify AI-powered tools for current AI-tool documentation, and Shopify AI best practices for review, error-handling, and usage boundaries. AI output can be wrong, so neither page should be reduced to “turn it on and let it approve.” Current tools, plans, permissions, and interface behavior must be checked again before publishing.
The Google AI display boundary
If this article enters search-content governance, use the ordinary checks for crawlability, indexability, useful visible content, and agreement between structured data and visible content. Google AI features do not require GEO-only schema. Do not add unsupported fields for AI visibility, and do not promise rankings, citations, or growth. Any structured data must match what the page visibly says.
Before publishing verification: prove that the flow stops before expanding it
Content and configuration preflight
Before publishing, verify that title, slug, article slug, and internal-link targets agree; current claims should be checked again before publishing; the state machine is labeled as a governance proposal; all five FAQs are present without new commitments; examples are test scenarios; the five official sources are available; and the AI, merchant-review, and current-permission boundaries are visible in the body.
Human-review preflight
Ask a merchant or editor to inspect each section: does any sentence turn a draft into an order? Does it turn a customer reply into a contract? Does it turn catalog context into a final price? Is a location ambiguity left unresolved? Does any audit field lack a source, time, or scope? Is a failure drill written like a real customer case? If any answer is unsatisfactory, return the page for editing before publishing.
Retest and withdrawal after integration
The related links are navigation, not a claim about similarity across the entire article set; use the complete text when a corpus comparison is needed.
Frequently asked questions
1. Can a Shopify B2B AI sales assistant send a quote automatically?
Only if the current store has a controlled sending process, the request context is complete, the quote version has not changed, and a designated authorized reviewer has approved that specific displayed version for sending. This article does not assume that any automatic sending capability exists. An AI-generated draft is not an approved quote and is not contract, credit, price, or order confirmation.
2. Can the assistant create an order after a customer says “I accept the quote”?
Not from that sentence alone. Bind the reply to the quote version and send it to customer-response and order review. Contract, credit, price, and order decisions still follow current store permissions and policy. The assistant may organize review material, but it may not promote customer intent into commercial authorization.
3. How should the assistant choose a location when a company has several?
It should not guess when the request lacks one unique, verifiable location identifier. It may show authorized proposeds and ask for confirmation. If the company relationship, catalog, or requester scope conflicts with the selected location, route the request to human review. Similar names or addresses do not replace current store relationship data.
4. What fields are the minimum audit log?
At minimum record the event and time, actor and role scope, company/location/catalog/quote and version, source snapshot and verification time, AI suggestion or send-content summary, state before and after, human decision and reason, rule or configuration version, and the retention/deletion marker required for real data. Field names can vary, but the record must support an authorization and evidence replay.
5. What happens to an old quote when the documentation or store configuration changes?
First block sending and order-related actions. Compare the approval-time source snapshot with current evidence. Preserve the old audit record, withdraw or mark the old version invalid, reread company, location, catalog, and product context, create a new quote version, and obtain approval again. Published content also becomes due for retest; an old approval is not current authorization.
Official sources
All cited claims should be checked against the current official pages and live-store configuration. The general Google AI display note is limited to ordinary content and structured-data consistency and does not add GEO-only schema or a ranking promise.