Departments

Departments are the durable organizational functions at Provisionr. They own budget, policy scope, and contain one or more Teams. Individuals never belong directly to Departments — they join Teams, which nest into Departments.

Pattern

prv-{dept}-dept@{domain}

Display name: PRV – Department – {Title}

Canonical Departments

ID	Email	Display Name	Scope
exec	prv-exec-dept	Executive	Board, strategy, OKR governance
fin	prv-fin-dept	Finance	FP&A, AR/AP, billing, payroll
hr	prv-hr-dept	Human Resources	JML, policies, recruiting, benefits
legal	prv-legal-dept	Legal	Contracts, IP, privacy, compliance
biz	prv-biz-dept	Business Operations	Cross-functional ops, capacity planning
ops	prv-ops-dept	Operations	Delivery governance, staffing, QA
plt	prv-plt-dept	Platform Engineering	Identity, workspace, infra, automation
it	prv-it-dept	Information Technology	Endpoints, helpdesk, networks
eng	prv-eng-dept	Engineering	Delivery engineering, IP, codebases
sec	prv-sec-dept	Security	SecOps, GRC, vuln management
mktg	prv-mktg-dept	Marketing	Brand, content, demand gen, events
sal	prv-sal-dept	Sales	Pipeline, accounts, CRM
archive	prv-archive-dept	Archive & Records	Retention, discovery, closeout

Description Format

PRV – Department – {Title}: {scope summary} | {who participates} | {what they work on}
  | Security group (department-level access control + team nesting)
  | CEL: {membership rule}

Example:

PRV – Department – Finance: Financial operations and accounting
  | Finance team, accounting, billing
  | Financial reporting, budgeting, invoicing, compliance
  | Security group (department-level access control + team nesting)
  | CEL: member.email.matches('^prv-.*-team-fin(?:-[a-z0-9-]+)?@.*$')

Membership Rules

Departments contain only Teams — never individual users. Membership is enforced via CEL rules that match the team naming pattern:

member.email.matches('^prv-.*-team-{dept}(?:-[a-z0-9-]+)?@{domain}$')

This ensures only properly-named teams for that department can be members.

Group Settings

• Security label: ON (departments are used for access scoping)
• Membership: Only invited (CEL-restricted to matching team groups)
• External members: OFF
• Locked: OFF (unless SCIM-managed)

Hard Rules

1. No individuals directly in any prv-*-dept group.
2. A Team nests into exactly one Department.
3. Departments are never members of admin Role groups (Segregation of Duties).
4. Departments should not appear on STRICT drive ACLs — use dedicated viewer role groups instead.

Drive Bindings

• Safe: Department as Viewer on internal knowledge TEAM drives (broad read access).
• Avoid: Department on STRICT drives. Department as Editor on any root.
• Prefer: A dedicated viewer role group (e.g., prv-ops-role-internal-viewers) on multiple drives instead of binding departments directly.

When to Create a New Department

Create a Department when the function:

• Owns budget, policy, or platform scope
• Will contain multiple Teams for at least 12 months
• Has a distinct compliance or audit surface

If it doesn’t meet these criteria, start as a Team under an existing Department. Promote later if scope grows.

Lifecycle

Create

1. Propose id + scope. Ensure it’s not a sub-team use case.
2. Get review from Executive + Platform + Security.
3. Create the group with email/name/description. Label as Security.
4. Set CEL membership restriction.
5. Wire baseline drive/view bindings if needed.
6. Create a starter Team under the new Department.

Modify

• Rename: Update Name/Description only. Email remains canonical. Add an alias for 60-90 days.
• Scope change: Re-review. Migrate affected Teams via ticket.

Retire

Move Teams to their new Department. Lock the old group. Keep for 1 year for audit. Then delete.

Metrics

Metric	Target
Orphan Teams (0 or >1 Department parent)	0
Direct users in any prv-*-dept	0
Mover SLA (update department within 1 biz day)	>= 98%
Department on STRICT ACLs	0 per quarter
Quarterly attestations (owners confirm nested Teams)	100%