Help Articles – Page 11
One platform, three relationships. Multi-site is the umbrella term: many websites or storefronts running on one shared core. Multi-store usually means one company running several branded storefronts from a single admin, often sharing a catalog and customer records. Multi-tenant means independent operators: franchisees, dealers, or separate businesses, each with isolated data and their own logins on shared infrastructure. Core dna supports all three on one instance: you decide what's shared at the core and what each property controls locally.
Both automatic discounts that apply at the cart without a code, and code-based vouchers and promo codes. Buy-one-get-one, volume breaks, customer-group rates, regional flash sales, and renewal discounts run natively. Stacking and exclusion rules live in one place, so you control which discounts combine and which cannot. There is no platform-imposed cap on the number of active discounts, price lists, or customer groups.
Yes, through Core dna MCP. Describe the change in plain language and the platform makes it against the same rules your team uses in the admin, with approval, audit, and rollback built in. Draft a promo, model a margin scenario before it goes live, audit recent overrides, or update contract pricing at renewal, all from a prompt. It runs on a live MCP server with 80+ tools and 400+ APIs. No price or promo goes live until the assigned approver signs off.
Yes. One storefront can serve retail customers at list price, B2B accounts on contract pricing, members on member rates, and internal users on a no-payment flow, all at once. The price each visitor sees is resolved from the customer group and account they belong to, against one master price book. You are not running separate stores or separate engines to support different commercial models under one brand.
Yes. Not every order has to collect payment. Core dna can run a checkout that behaves like an order, moves stock, and triggers fulfilment and approval, but takes no payment. Internal transfers, branch requisitions, sample orders, and account-billed orders run on the same engine as paid orders, with the same audit trail. You decide per customer group or per channel whether payment is collected, deferred to invoice, or skipped entirely.
Yes. Buyers can raise an RFQ from the catalogue, and sales reps can build or adjust a quote against the account's negotiated price list. The quote carries the same pricing rules, customer-group logic, and contract terms the account already sits on, so the quoted price matches what the buyer sees when they log in. Approved quotes convert to an order without rekeying. Every override on a quote is logged against the account.
By the four-phase exit criteria, not by the model's benchmark scores. The readiness signal is operational: scoped identity in place, audit captures intent, discovery-mode plans match human-operator plans, governed execution has run a representative volume of writes with zero unrecoverable actions, and a governance cadence is established and attended. If any of those is missing, the agent is not ready to scale, regardless of how the model performs in isolation.
With a standing governance group, a monthly cadence, and the audit log as the agenda. Governance covers tool-permission drift, new-tool onboarding, model changes, incident review, and retiring tools the agent no longer needs. The governance group needs representation from digital, platform, security, and risk - not just the team that built the agent.
When it has demonstrated, in discovery mode, that its plans are the plans a human operator would approve, on a representative task set, over a window long enough to surface your edge cases. Write access is earned, not defaulted. And the first writes should be reversible, low-blast-radius actions inside a tight tool box - not high-stakes operations on customer-facing data.
The narrowest set of permissions that lets it do the specific job you hired it for. Agents should never inherit a human's permission set, and they should never share credentials with another agent or service. Permissions are granted at the tool level, scoped to the record types and actions the agent's job actually requires, and reviewed on the same cadence as the rest of your privileged-access program.
In phases, with read-only first. The pattern that works is: prepare the environment with scoped identity and audit, validate the agent in discovery mode where it can plan but not write, promote it to governed execution with tight tool boundaries and rollback, then run it under continuous governance with a standing review cadence. The single most common failure mode is granting write access before discovery-mode validation is honestly complete.
MCP, the Model Context Protocol, is a standard for exposing tools to AI agents as a declarative surface. Instead of every agent integrating against every system through bespoke code, the system publishes its tools through MCP and the agent discovers and calls them through a single protocol. For enterprise rollouts, MCP matters because tool boundaries become enforceable. You grant an agent access to specific tools rather than to whole systems, and you can revoke access without rewriting the agent. Core dna's MCP server exposes 80+ tools across 400+ APIs, in production today.
A chatbot answers. An agent acts. The chatbot lives in the conversation layer and hands off to a human or a workflow when something needs to happen. The agent owns the doing. That difference is why the governance model for agents looks more like the model for a privileged service account than like the model for a content surface.
An enterprise AI agent is a software actor that takes goals, plans actions, and calls tools against your production systems on its own initiative. The distinguishing trait is autonomy with consequence. Unlike a chatbot, an agent is doing work that changes state - updating records, dispatching workflows, calling APIs that move money or content or customers. Enterprise-grade means it operates inside the same identity, audit, and governance perimeter as the rest of your platform.
Only if the business case for headless exists independently of the migration. Headless solves real problems - multi-channel delivery, frontend framework freedom, separation of editing and rendering - but it adds complexity. Migrating to headless because the migration was happening anyway is how teams end up with a stack they can't staff.