At first onboarding, EOS<\/strong> automatically approves up to five core<\/strong> products \u2014 the customer-facing offerings in your catalog, as opposed to supporting or ancillary items. If your catalog only has two core products, you get two approved automatically; there’s no padding to hit five. If you have more than five, the system ranks and selects up to five, and the rest land in a pending state.<\/p>\n\n\n\n This auto-approval only happens once, during that first onboarding run. It’s not a standing rule that quietly approves every new item that shows up later \u2014 anything pending after that point needs a human to actually approve it.<\/p>\n\n\n\n Behind the scenes, every product gets classified as either core (a real, sellable offering) or supporting (a sub-component or accessory). You don’t do this classification yourself \u2014 it happens automatically during setup \u2014 but it’s not hidden from you either. Supporting items get a visible “Supporting” badge in your product list, and the list defaults to showing core products only, with a toggle to include supporting items when you want the full picture.<\/p>\n\n\n\n Only core products are eligible for that initial auto-approval. Supporting items always start pending, regardless of catalog size.<\/p>\n\n\n\n Everything that didn’t make the initial cut sits on a Pending Approval tab, and you’ve got two ways to work through it: approve or reject items one at a time, or hit “Approve All” to clear everything on the current page in one action.<\/p>\n\n\n\n That second option is worth understanding precisely, because it’s easy to assume it does more than it does. Approve All clears the current page of your pending list \u2014 not your entire pending queue.<\/strong> If you’re working through a catalog with a few hundred pending items spread across multiple pages, you’ll be hitting Approve All once per page, not once total. For a small catalog this is a non-issue; for a large one, it’s a real, repeatable part of your workflow, not a one-click finish line.<\/p>\n\n\n\n Rejecting is just as available as approving. If a pending item genuinely isn’t worth training your team on \u2014 a discontinued accessory, a duplicate entry, whatever doesn’t belong \u2014 reject removes it from the queue entirely. Nothing has to sit in limbo forever; every pending item has a real endpoint, either approved or dismissed.<\/p>\n\n\n\n There’s no hard ceiling on how many products can be pending or how large a single bulk action can be. A very large catalog just means more pages to work through and more time spent reviewing \u2014 a practical constraint, not a fixed limit anyone will hit a wall against.<\/p>\n\n\n\n See how fact-grounded verification scales to a real catalog.<\/strong> Our 12-page report, Beyond Roleplay: The Rise of the Sales Knowledge Engine<\/em>, covers the architecture behind claim extraction and verification \u2014 the same engine that has to keep up with your product list as it grows. [Download the whitepaper \u2192]<\/strong><\/a><\/p>\n<\/blockquote>\n\n\n\n Products change. When you edit one that’s already approved, saving it kicks off a background knowledge sync \u2014 refreshing the underlying facts and search data that verification actually checks claims against. There’s no fixed timer on this; it depends on the size of what’s being resynced and what else is in the processing queue at the time, and it’s usually a matter of minutes, sometimes a bit longer.<\/p>\n\n\n\n One thing worth knowing: this is a full resync, not a targeted update to just the field you changed. Edit one price and the whole product’s knowledge assets get refreshed, not just that price. And importantly, the product doesn’t go offline while this happens \u2014 it stays approved, stays in your catalog, and practice sessions and quizzes keep working against it the whole time. Very recent edits might take a little while to be fully reflected in verification, but there’s no maintenance-mode gap where the product simply isn’t usable.<\/p>\n\n\n\n Most products land in your catalog the same way: extracted from your website scrape or from an uploaded document, landing pending, going through the same approve\/reject flow either way. Your catalog shows a source label so you can tell which came from where, but the review process itself doesn’t differ by source.<\/p>\n\n\n\n There’s one exception worth knowing about. If you manually add a product directly in the interface rather than letting it get extracted, it’s saved as approved immediately \u2014 no pending queue, no review step. That’s a genuine shortcut when you already know exactly what you want in your catalog and don’t need the system to find it for you.<\/p>\n\n\n\n You don’t have to open every product individually to know how your catalog review is going. The Knowledge Hub home view shows approved and pending counts at a glance, and the Pending Approval tab itself carries a badge showing how many items are waiting. If that number is climbing faster than anyone’s reviewing it, it’s visible before it becomes a real gap.<\/p>\n\n\n\n One role note worth knowing if you’re setting up who can do what: approving or rejecting products requires admin or owner access. Trainers might be able to see the review tabs, but they can’t actually act on them \u2014 that’s reserved for whoever’s running the org.<\/p>\n\n\n\n A fast onboarding start and full catalog coverage aren’t the same thing, and they’re not meant to be \u2014 five auto-approved products gets you practicing quickly; the rest is a deliberate, reviewable process built for exactly the catalogs too large to fully vet in one pass. Knowing where that line sits, and how to move things across it efficiently, is what keeps a large catalog from quietly becoming a knowledge base that only covers what got lucky on day one.<\/p>\n\n\n\n See your own catalog become a knowledge check.<\/strong> EOS turns your product documentation into practice and provable knowledge \u2014 claim extraction, fact-grounded verification, and auto-generated quizzes that reveal what reps actually know. Start free with up to 5 seats at app.akaeos.com<\/strong>, or [download the full whitepaper]<\/strong><\/a>.<\/p>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":" Onboarding only auto-approves a handful of products. Here’s exactly what happens to the rest of your catalog, and how approval actually works.<\/p>\n","protected":false},"author":1,"featured_media":11489,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3642,3640],"tags":[4723,4905,4906,4902,4903,4679,4724,4904,4908],"class_list":["post-11488","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai-en","category-all-en","tag-ai-sales-training","tag-knowledge-hub","tag-knowledge-management","tag-product-catalog-management","tag-product-training","tag-revops","tag-sales-enablement","tag-sales-enablement-ops","tag-sales-onboarding"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\tCore vs. supporting: decided for you, but visible<\/strong><\/h2>\n\n\n\n
Getting through the rest of your catalog<\/strong><\/h2>\n\n\n\n
![\"\"](\"https:\/\/blog.themusio.com\/wp-content\/uploads\/2026\/10\/image-1024x437.png\")
<\/figure>\n\n\n\n\n
What happens when you edit an approved product<\/strong><\/h2>\n\n\n\n
Where products actually come from \u2014 and one shortcut<\/strong><\/h2>\n\n\n\n
Keeping an eye on where things stand<\/strong><\/h2>\n\n\n\n
The takeaway<\/strong><\/h2>\n\n\n\n
\n