Policy — departments and designations
Policy (/orgs/{orgId}/policy) is how Admins define what Members (and other staff) can do. Access is granted through designations, not by editing each screen manually.
Concepts
| Term | Meaning |
|---|---|
| Department | Grouping under the org (codes like POLICY-n are generated) |
| Designation | Role template under a department (e.g. Filing Executive) |
| Permissions | Grants on that designation: domain, resource, action, scope |
Users receive one or more designations on their user detail page. Effective permissions are the union of those grants.
Typical Admin workflow
- Open Policy.
- Create departments as needed.
- Create designations under each department.
- Edit the permission tree for each designation (read / create / update / delete on the right resources).
- Optionally export / import a designation-policy bundle when copying setup between environments.
Practical grants (examples)
| Goal | Grant idea (conceptual) |
|---|---|
| See Individual Accounts in nav | Person account list/read |
| Edit a person’s basic details | Person account update (scoped or org-wide) |
| Manage assignees | Person/entity team update |
| Approve accounts | Person/entity approve update |
| Work milestones on an account | Service instance access on that account |
| Approve filings | Filing approve update |
| Create invoices | Invoice create |
| Open Policy itself | Org modules read (edit needs create/update) |
Use product labels in the Policy UI. Avoid giving Members approve or Policy edit unless intentional.
Who can do this
| Action | Admin | Member |
|---|---|---|
| Open Policy | Yes (typical) | Only if granted |
| Create departments / designations | Yes | Only if granted |
| Edit permission rows | Yes | Only if granted |
| Export / import policy bundle | Yes (typical) | Only if granted |
Open in CARA: Open Policy
Next: Users and designations.