Departments
A Department is its own boundary inside a Tenant: its admins see and manage every Project inside it, and nothing outside it. Most of the day-to-day organizational structure in VeroXM lives at the Department level — it's where Projects are grouped, where custom roles are defined, and where an approval workflow is usually configured.
Creating a Department
Adding a Department is a Tenant Admin (or Super Admin) action, done from the parent Tenant's page — open the Tenant and use New department. A Department has a display name and a slug; like a Tenant's slug, it's fixed once chosen.
Department Admins
A Department Admin sees and manages every Project inside their Department, and nothing outside it. Grant or revoke a Department Admin from the Department's own page — the same invite-by-email flow Tenant Admins use, including "Pending activation" for an account that hasn't signed in yet. Only a Tenant Admin (of the Department's Tenant) or Super Admin can grant or revoke a Department Admin; a Department Admin can't promote another user to their own tier.
Department members and roles
Beyond Department Admin, a Department can have members holding any of the built-in role tiers, or a custom role (below), scoped to that Department. See Users & Roles for the full list of built-in tiers and how project-level roles work.
Custom roles
A Department can define its own custom roles — a named bundle of specific permission grants, such as a role that can manage API tokens and webhooks but nothing else, or a business-facing approver role like "Brand Reviewer" or "Compliance Lead." A custom role is scoped to the Department that defines it and is assigned to individual users within that Department; revoking it from one person doesn't delete the role itself.
Both a Tenant Admin and a Department Admin can define and assign custom roles for a Department — unlike an approval workflow (below), which only a Tenant Admin can configure.
Custom roles power named approvers
Beyond permission grants, a custom role can also be named as the required approver for a specific step in an approval workflow — see Approval Workflows. That's why custom roles live at the Department level: an approval step's named approver has to be someone scoped to the same Department the workflow governs.
Where a Department fits in
A Department groups related Projects under one set of admins and one shared approval policy. See Tenants for the tier above a Department, Creating A New Project for how a Project is created inside a Department, and Approval Workflows for how publishing is gated at the Department level (and optionally overridden per Project).