User Roles & Permissions
Learn about platform roles, organisation role templates, permissions, capabilities, package entitlement checks, and the 13-layer authorization stack in NowToPrint.
User Roles & Permissions
NowToPrint authorization is not decided by a role name alone. The current model evaluates platform roles, organisation role templates, permissions, capability entitlements, and resource scope together through a 13-layer authorization stack.
The 13-Layer Authorization Stack
Every access decision in NowToPrint passes through a layered evaluation pipeline. This design follows industry best practices from leading B2B SaaS platforms and ensures both security and flexibility.
┌─────────────────────────────────────────────────────────┐
│ Layer 1: Authentication (BetterAuth + Firebase) │
│ Layer 2: Principal Status (active/suspended/banned) │
│ Layer 3: Tenant Boundary (organization isolation) │
│ Layer 4: Resource Scope (platform/org/profile/team) │
│ Layer 5: Role → Permission (RBAC) │
│ Layer 6: Permission → Capability (mapping) │
│ Layer 7: Package Entitlement (capability status) │
│ Layer 8: Billing Contract (grant state) │
│ Layer 9: Targeting Override (pilot/founder bonus) │
│ Layer 10: Release Gate (feature flag) │
│ Layer 11: Usage Quota (metered limits) │
│ Layer 12: Risk Control (anomaly detection) │
│ Layer 13: Decision Audit (immutable log) │
└─────────────────────────────────────────────────────────┘How Decisions Are Made
A request must pass all applicable layers to be allowed. If any layer denies access, the request is blocked and the reason is logged for audit. This provides defense-in-depth security while maintaining a clear audit trail.
Platform Roles
Platform roles control access to admin surfaces and system-wide operations. Every user has exactly one platform role.
Administration Roles
| Role | Risk | Description |
|---|---|---|
Platform Owner (platform_owner) | 🔴 Critical | Highest platform authority — founders only |
Super Admin (super_admin) | 🔴 Critical | Full administrative access to all systems |
Security Admin (security_admin) | 🔴 Critical | Security configuration, role and API key management |
Operational Roles
| Role | Risk | Description |
|---|---|---|
Marketplace Ops (marketplace_ops) | 🟠 High | Day-to-day marketplace operations, user and org management |
Finance Admin (finance_admin) | 🟠 High | Financial operations, payments, payouts, commissions |
Entitlement Admin (entitlement_admin) | 🟠 High | Package and capability management, rollout control |
Pricing Admin (pricing_admin) | 🟠 High | Pricing configuration and commission management |
Support Admin (support_admin) | 🟡 Medium | Read-only support access to users and organisations |
Growth Admin (growth_admin) | 🟡 Medium | Analytics and growth operations |
Content Localization Admin (content_localization_admin) | 🟡 Medium | Content and translation management |
Data Management Roles
| Role | Risk | Description |
|---|---|---|
Master Data Steward (master_data_steward) | 🟡 Medium | Canonical master data management, import/export |
Standards Steward (standards_steward) | 🟡 Medium | Standards and quality data management |
Readonly Auditor (readonly_auditor) | 🟢 Low | Compliance audit access — read-only |
Note: Legacy aliases such as
admin,superadmin, andread_only_auditorare still accepted for backward compatibility. New admin surfaces use the canonical platform roles from the shared contract.
Organisation Role Templates
Organisation role templates generate permission sets within a workspace. The available templates depend on your organization type (buyer, supplier, broker/agency).
Buyer Organizations (Individual / Corporate Customer)
| Role | Description | Key Permissions |
|---|---|---|
Owner (org_owner) | Full control including billing and member management | All buyer permissions |
Admin (org_admin) | Manages org settings, members, and operations | Member management, settings, operations |
Buyer Manager (buyer_manager) | Procurement lead — creates RFQs, manages quotes and orders | RFQ create, quote management, order lifecycle |
Buyer Member (buyer_member) | Team member — creates RFQs, views own orders | RFQ create, own order view |
Finance (finance_member) | Finance team — views billing, manages payments | Billing view, payment management |
Viewer (viewer) | Read-only access to all buyer data | View-only |
Print Producer Organizations
| Role | Description | Key Permissions |
|---|---|---|
Owner (producer_owner) | Full production operations and business management | All producer + buyer permissions |
Admin (producer_admin) | Operations manager — manages team and production | Full producer operations |
Quote Manager (quote_manager) | Sales/estimating — handles incoming RFQs and quoting | View matching RFQs, create/manage quotes |
Production Manager (production_manager) | Shop floor lead — manages orders and production status | Order management, production tracking |
Finance (producer_finance) | Accounting — manages financial operations | Financial views, payout management |
Viewer (producer_viewer) | Read-only access to all producer data | View-only |
Agency / Broker Organizations
| Role | Description | Key Permissions |
|---|---|---|
Owner (agency_owner) | Full agency operations and client management | All agency permissions |
Admin (agency_admin) | Operations lead — manages team and workflows | Full agency operations |
Buyer (agency_buyer) | Client manager — creates RFQs on behalf of clients | Client-facing buyer operations |
Seller (agency_seller) | Vendor relations — manages supplier interactions | Quote management, production coordination |
Finance (agency_finance) | Accounting — billing, payments, commissions | Financial operations |
Permission and Capability Relationship
A role grants permissions. Many permissions map to capabilities. If the organisation package does not include the capability, the action can still be blocked.
┌──────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────┐
│ Role │────▶│ Permission │────▶│ Capability │────▶│ Package │
│ │ │ │ │ │ │ Status │
└──────────┘ └──────────────┘ └──────────────┘ └──────────┘
▼
┌──────────────────────┐
│ live | locked | │
│ preview | pilot | │
│ coming_soon | │
│ contact_sales │
└──────────────────────┘| Example Permission | Capability | Notes |
|---|---|---|
rfq.create | marketplace.rfq.create | Buyer RFQ creation |
producer.quote.create | supplier.quote.manual | Supplier quote creation |
producer.order.manage | supplier.order.lifecycle.basic | Supplier order operations |
admin.entitlements.manage | Entitlement control plane | High-risk; approval and audit required |
admin.roles.manage | IAM control plane | High-risk role-management permission |
Use the Roles & Permissions admin page to preview whether a role template, resource, package, and action combination is allowed.
How Roles Are Assigned During Onboarding
When you complete the onboarding wizard, the system assigns roles based on your selected organization type:
Organization Type Selection
│
▼
┌──────────────────────────┐
│ IAM_ACCOUNT_TYPE_CONFIG │ ← Single Source of Truth
│ (from @nowtoprint/ │
│ contracts) │
└──────────┬───────────────┘
│
┌──────┴──────┐
│ │
▼ ▼
Legacy Role IAM Role Binding
(owner) (org_owner /
producer_owner /
agency_owner)The legacy role (owner) is stored for backward compatibility. The IAM role binding is stored with organization scope and determines your actual marketplace permissions.
Control-Plane Governance
The 2025-2026 launch posture treats authorization policy as versioned product infrastructure, not admin UI copy. The shared AuthZ SSOT defines the decision chain, high-risk permissions, control-plane role boundaries, and review cadence used by the admin read model.
| Control Area | Launch Rule |
|---|---|
| High-risk role, entitlement, finance and API-key powers | Review at least every 30 days |
| Standard organisation and platform access | Review at least every 90 days |
| Read-only auditor access | Review at least every 180 days |
| Break-glass elevation | Time-box to 24 hours or less |
| Policy changes | Keep in contract/code review with audit evidence |
| Decision logs | Keep allow/deny, override, package and release-gate decisions auditable |
Preview access to the entitlement control plane can include auditors. Publish access must stay limited to full platform admins and explicit entitlement/pricing/security operators.
Inviting Members
Navigate to the team management page from the dashboard.
Enter the invitee's email address and select the appropriate role template. Available roles depend on your organization type.
The invitation email is sent automatically. The invitee must accept within 7 days.
Changing a Member's Role
An Owner or Admin can change organisation member roles when the relevant permission and package conditions pass:
- Go to Settings → Team
- Click the ⋮ menu next to the member
- Select Change role
- Choose the new role and save
Important: You cannot demote yourself. Ask another admin or owner for help.
Best Practices
- Principle of least privilege: Grant only the role template users need
- Regular audit: Review members, role changes, and entitlement changes periodically
- Critical actions: Keep role, entitlement, API key, and finance changes behind approval and audit
- Departing team members: Remove leavers immediately and revoke service accounts where applicable
- Package separation: Remember that package entitlement is checked separately from user permission
See Also
- Registration & Onboarding — complete setup guide
- Roles & Permissions Reference — complete admin reference
- Packages & Entitlements — how plans control feature access
- Organization Management — managing organizations
Previous: ← First Order | Next: Keyboard Shortcuts →
Cet article vous a-t-il été utile?
Articles connexes
Dernière mise à jour