Partner Groups and Product Groups
Owner / Compliance Manager setup workflow for the two axes every Document Requirement scopes on. A requirement answers WHO owes it (global, a Partner Group, or one partner) and WHAT it is about (all products, a Product Group, or one product) — and both group vocabularies are org-defined here before any requirement can use them. This runs immediately after Document Types and before Document Requirements. Skipping it is not a neutral choice: a requirement scoped to a Partner Group that does not exist cannot be written, and a partner who belongs to no group is subject to nothing that is group-scoped. In the first production org, 9 of 13 requirements were partner-group scoped and every product-scoped requirement was gated on a Product Group — so a partner or product created without one reads compliant while owing nothing.
Who: Owner / Compliance Manager · Regulation: No direct regulatory citation. Both groupings are org-internal vocabulary for scoping obligations. FSVP supplier verification (21 CFR 1.505-1.506) and the DR compliance aggregate both read the requirements these groups scope, so the vocabulary is upstream of every compliance answer — but choosing it is a business decision, not a regulated one.
Review the partner groupings requirements can be scoped to
Section titled “Review the partner groupings requirements can be scoped to”
What you should see: The Partner Groups tab lists the groupings this org scopes obligations by. These are NOT a partner classification for its own sake and they are not the partner’s lifecycle standing — they exist so one requirement can apply to a set of partners without being written once per partner. A partner may belong to several groups; the requirements it owes are the union.
Define a new partner grouping
Section titled “Define a new partner grouping”
What you should see: The group exists and can be scoped to. Nothing is applied retroactively — creating a group changes no partner’s obligations until a partner is put in it or a requirement is scoped to it. A description is worth writing. It is what the next person reads when deciding whether a new supplier belongs here, and a group whose membership rule lives only in one person’s head produces inconsistent compliance answers.
Review the product groupings requirements can be scoped to
Section titled “Review the product groupings requirements can be scoped to”
What you should see: Product Groups are the WHAT axis. They attach to the Product — the org’s catalog entry for a thing — and not to a Supply, because they describe what the thing IS and that does not change with who ships it. This replaced an is_organic boolean. A flag answers one question forever; a group vocabulary answers the questions the business has not thought of yet, which is why the requirement scope picker reads from this list rather than from a fixed set of columns.
Define a new product grouping
Section titled “Define a new product grouping”
What you should see: The group exists and can be scoped to. The consequence to understand before leaving this screen: a product in no group is invisible to every requirement scoped by Product Group. It will not appear as a gap, because nothing is asking for it. That is why the ERP mapping dialog states the rule inline when creating a product, and why this workflow sits before Document Requirements rather than after.