Departments and work handoff rules
Departments (/departments) define management structure and task handoff. They affect escalation, assignment, visibility, and control—not just the employee list. Use /departments/new to create a department and /departments/:departmentId to open an existing one; fields and tabs depend on your permissions.
The documentation is translated, but some visible Departments labels in a selected locale can temporarily inherit a base language. This does not change permissions or data; do not treat a mixed-language screen as localized screenshot evidence until its visible labels are verified on the current build.
Both pages are addressable and keep the selected tab in the tab query parameter; All departments returns to the registry, and the browser Back action keeps the expected route. Loading has its own state, a read error offers Retry, and a deleted or inaccessible department is shown as Not found rather than as an empty card.
Hierarchy and editing
At /departments/new, enter a required name, code, parent department, manager, order, and active flag. After a successful save, the portal redirects to the created department page instead of leaving the result only in a modal. Creation and later edits require write permission; without it, the form explains the restriction.
The department page has four tabs: Overview, Members, Task rules, and Settings. Overview shows the place in the structure, child departments, manager, and facts; Members supports search, add, remove, and save. Task rules shows assignment presets and handoff directions and requires a reason to save or reset local rules. Settings contains ordinary field saving, a reversible active toggle, and an irreversible Delete button with confirmation. There is no separate Delete tab.
Adding a member does not transfer the person out of their former department: it adds another membership. For an actual transfer, remove the person from the former department separately, then verify their access after both changes; a successful save does not show how visibility or permissions changed.
Changing the manager is not cosmetic: it affects the “own and subordinate” scope and therefore CRM visibility. The screen does not explain that consequence before or after saving, so agree the change with the policy owner first and then verify the affected employee’s access separately; a successful save is not proof of the correct visibility.
Before moving or closing a department, check active tasks, workflows, projects, documents, and the current manager. Before deleting a parent department, move or close every child department first, then review employees and tasks. The confirmation dialog does not list child departments or cleanup counts: without reparenting, a child department can still exist but disappear from the tree and search. Closing must not delete history or leave existing work without an owner.
Tabs and changes
Do not treat a hidden tab as proof that the record is absent: a tab may be unavailable by permission while the department remains read-only. Before changing anything, confirm the selected tab, current revision, and write-permission message.
In the department task-intake block, you can enable or disable assignments to the department. When enabled, candidates are selected in round-robin order; the scope can be the department only or the department and its subtree, and you can require the candidate to accept before work starts. A declined task with a reason moves to the next eligible candidate or back to manual assignment when the queue is exhausted. Set the minimum number of active assignees; without required acceptance, the task is considered started as soon as it is assigned.
In Task rules → Work planning, choose As in the portal, Allowed, or Not allowed. The first option creates no department rule; the shown portal setting is only a default because a company policy can further limit the effective right. When self-planning is not allowed, the task author or the performer’s manager plans the work. Work planning does not change the task deadline. Give a reason before saving, then read the rule again after saving: a brief reload alone is not proof of the result.
Effective rules
Inspect the department structure, members, task rules, and local settings together. These facts live on the corresponding department tabs; do not grant admin access as a shortcut around an unclear local policy.
Incoming assignments also depend on other departments' rules and global settings. Resetting local settings removes local exceptions and makes global settings apply again; explain the reason and expected effect before changing them.
Search and presets
Search departments by name, code, or manager and enable Show inactive when needed; confirm the result count beside the filters. Open a department and use Overview, Members, Task rules, and Settings to inspect structure, membership, presets, and local policy. In Task rules compare the audiences All roles, Employees, and Managers.
Assignment presets are a quick starting point, not the final policy. Review each rule's actual area and role after choosing a preset. Enter a reason before saving or resetting and confirm that only the selected layer changes.
Task handoff directions
Verify downward assignment, upward escalation, cross-department transfer, and within-department work with a safe test user. After saving, create a test task and check the result. If an action is unavailable, check its area, membership, and policy.
Safe examples
Use synthetic departments, roles, and tasks. Do not show real names, phones, internal codes, client data, or mixed-language labels. Keep examples for this surface free of financial data.
Related pages