Roles & responsibilities

PIE ships a fixed set of roles. You do not design permissions; you give each person the role that matches their job, and the platform enforces it on the server for every request. This page explains who does what in the overall process. The exhaustive resource-by-resource matrix is the generated Roles & permissions reference.

How roles work

• Every user has one role in one organisation. The role decides what the person can see and change; the organisation decides whose data it is. A user can never act on another organisation's data, whatever the role.
• The app follows the role. Menu entries are shown when the role may use the page, and a button appears only when the role may take the action. A read-only person still sees the page — they simply are not offered buttons that would be refused. This is a convenience: the server checks every request again.
• Buyers see only what they are granted. A buyer role reads products of producers who have granted access, never anything else (see Multi-tenancy & grants).
• Roles belong to the side of the organisation. A producer organisation uses the pip_* roles, a buyer organisation the pic_* roles. An organisation that is both a producer and a buyer (type both) has producer users for its own catalogue and buyer users for what it receives.

Producer roles

pip_admin — organisation administrator

The only producer role that shapes the setup and the audience:

• People and access — invites and removes users, assigns roles, manages grants (which buyer sees which products), API keys, webhooks, SSO and the organisation's sign-in policy.
• Structure — creates and edits product categories and their schemas, reference-entity types, quality profiles, workflow definitions and approval rules.
• Outbound channels — creates channels and their delivery connectors, brand portals, GS1 mappings and the GDSN pool connection.
• Data governance and money — privacy tooling (data-subject requests, retention, processing records), the audit log, plan and billing, AI settings.
• Everything an editor can do, plus archiving and deleting products.

pip_editor — product data editor

Does the daily product work, and nothing that changes who sees it or how the organisation is set up:

• Creates, edits and publishes products, manages their assets, ingredients and relationships, localises content, and reviews AI enrichment suggestions.
• Builds catalogs (templates and renders) and Digital Product Passports, publishes products to channels that an administrator set up, and publishes to GDSN through the connection an administrator configured.
• Acts on workflow tasks assigned to them.
• Reads, but does not change: categories and schemas, quality profiles, brand portals, channels and connectors, GS1 mappings, the GDSN connection, grants, users and organisation settings. These pages stay in the menu so the editor can see how things are set up; the buttons that would change them are not offered.
• Cannot archive or delete products.

pip_viewer — read-only

For people who need to see but not touch — a quality manager, an auditor, a sales colleague preparing a call. A viewer reads products, assets, catalogs, passports, channels, portals and the setup pages, and can export analytics and passports. Every create, edit, publish or delete control is absent.

A producer example

Alpenhof Käserei is a cheese producer that sells to supermarket chains.

1. Sibylle, the owner, is the pip_admin. She registers the organisation, invites her colleagues, builds the "Cheese" category with the required attributes, sets a quality profile ("name, GTIN, allergens and nutrition must be complete"), creates a channel for the chain's flat-file feed and a brand portal for the website.
2. Jonas and Mira are pip_editors. They create the products, upload photos, fill in the allergens and nutrition values, and use AI enrichment for the German and French descriptions. When a product passes the quality profile they publish it, and publish it to the chain's channel. Jonas also renders the autumn catalog as a PDF.
3. Sibylle grants the supermarket chain access to the published products — the buyer sees nothing before this.
4. Dr. Weber, the quality manager, is a pip_viewer. He reads the products, passports and quality results before a certification audit, and exports the analytics. He has no way to change a value by accident.
5. A product needs a new allergen declaration. Mira changes it and publishes. A change that must be approved goes through the workflow: Mira submits it, Sibylle (or whoever the workflow names) approves it. Deleting or archiving the old product is Sibylle's step.

Buyer roles

pic_admin — buyer administrator

• People and access — invites users, assigns roles, manages API keys, SSO and sign-in policy, billing and AI settings.
• Bringing suppliers in — creates onboarding requests for suppliers, reviews and approves their submissions, defines mapping templates and the quality profiles a submission must meet.
• Receiving data — accepts or rejects inbound GDSN messages, and, like every buyer, requests access from suppliers and uses their granted products.
• Governance — audit log, privacy tooling and webhooks.

pic_subscriber — buyer user

The working role for category managers, data stewards and integrators:

• Reads the products of every supplier that granted access — attributes, assets, categories and relationships — and searches across suppliers.
• Syncs and exports the data into their own systems, and manages webhooks that notify those systems about changes.
• Handles inbound GDSN messages and can request access from a supplier.
• Reads, but does not change: onboarding requests and submissions, mapping templates and quality profiles. A subscriber has no access to API keys, SSO or billing.

A buyer example

Frischemarkt AG is a supermarket chain.

1. Tobias, head of data, is the pic_admin. He registers the organisation, invites his team, and creates an onboarding request for a small supplier that does not use PIE yet: which fields are required and which quality profile the data must satisfy.
2. The supplier submits its data through the link it received. Tobias reviews the submission, previews the field mapping, and approves it — the supplier's products now appear in the chain's catalogue.
3. Lena and Murat are pic_subscribers. They browse the granted products, filter by allergen or certification, and compare suppliers. They never see a producer's drafts or products that were not granted to Frischemarkt.
4. Murat connects the ERP. He registers a webhook so the ERP is notified when a supplier updates a product, and uses the export for the nightly sync.
5. When a new colleague joins, only Tobias can invite them and choose their role.

Organisations that are both producer and buyer

An organisation of type both has the two sets of roles for the two jobs: its producer users maintain its own catalogue, its buyer users read what suppliers granted. A both organisation can also take a supplier's granted product over as an ingredient of its own product — a producer-side step for pip_admin and pip_editor; the supplier's data is copied at that moment and later supplier changes wait for review. How an organisation becomes both, and what that does to its plan, is in Producing and buying on one account.

Platform roles

PIE staff have their own, separate roles, scoped to the whole platform rather than one organisation: platform administrator (organisations, platform users, billing), read-only auditor, support (help a customer, with an audited impersonation) and billing. They are not roles you can give to your own users. The Roles & permissions reference lists what each may do.

Choosing the right role

• Give most people the least role that does their job: editors for the people who maintain data, viewers for those who only read, subscribers for the buyers' daily users.
• Keep the administrator count small — an administrator can grant data to other organisations and create API keys.
• Change a role by editing the user in Administration → Team (producer app) or the team section of Settings (buyer portal).
• If someone says "the button is missing", check their role first: a button that is not offered means the role may not take that action, and the reference matrix says which role may.