Organization chart - KayanOS Documentation

KayanOS represents organizational structure through node and position hierarchies. Use these views to understand responsibility, staffing context, and open positions. Do not treat the hierarchy as a permission report or a final human-resources headcount register. The current source-backed views are a node tree and a position tree. A separate generic Organization Chart component is not a completed operational chart, so this guide focuses on the hierarchy views that are actually supported.

When to use it

Use the node hierarchy to review how organizational units sit below the organization root. Use the position hierarchy to review reporting relationships between positions. Use both before changing a parent node, a parent position, or a staffing model that will affect service delivery. For the Syrian Citizen Services Directorate, a manager can use the node view to see the central directorate and regional centres, then use the position view to see how a Regional Service Centre Supervisor relates to Intake Advisers.

Configuration

View	What determines the hierarchy	What it helps you review
Node tree	Each node’s parent node; top-level nodes appear below the organization root	Unit relationships, positions by node, staffing context, and vacancies.
Position tree	Each position’s parent position; positions without a parent appear below the organization root	Reporting/role relationships and the place of a role in the structure.
Staffing context	Positions connected to nodes, plus assignments connected to positions	A planning view of positions, assignments, and vacancies.

The node view can include descendants in its counts. In the current source, a linked assignment without an end date or with an end date in the future contributes to the displayed staffing count. That is useful for a structural review, but it is not the same as an approved payroll count, an attendance count, or a legal headcount.

Workflow

Open the node hierarchy before reorganizing units. Start at the organization root.
Confirm that every regional unit has the expected parent node.
Open the position hierarchy and confirm parent positions represent real reporting relationships.
Inspect positions associated with each node. Review whether they point to the intended service location.
Use the descendant option only when you need an aggregated view. Turn it off when checking a single unit’s own positions.
Investigate a vacancy by opening the position and its assignments; do not conclude that a named person has left merely from a chart count.

Worked example

The Directorate is preparing a service-capacity review.

Organization root: Citizen Services Directorate Node: Damascus Regional Citizen Services Child node: Mobile Intake Service Parent position: Regional Service Centre Supervisor Child position: Intake Adviser Service location: Damascus Service Counter

First, the manager confirms that Mobile Intake Service is a child node of Damascus Regional Citizen Services. Next, the manager checks that Intake Adviser reports to the Regional Service Centre Supervisor. Finally, the manager checks the linked assignments and their dates before treating a vacancy count as an action item. This review can reveal a structural problem, such as an adviser position attached to the central directorate instead of the regional centre. It does not decide access, salary, leave eligibility, or work-time approval.

Testing

Test a hierarchy change with temporary records or a controlled draft change, never by moving a live service unit without review.

Create a temporary child node and position under a clearly marked test parent.
Confirm the node tree shows the child under the expected unit.
Give the position a temporary parent position and confirm the position tree path.
Add a dated temporary assignment and compare the displayed staffing context with the assignment record.
Undo or retire the test structure after the review.

When testing an existing structure change, capture the original parent links and obtain the organization’s approval before saving. A parent change can affect how people interpret reports and inherited operational context.

Troubleshooting

Situation	Check	Resolution
A node appears at the organization root unexpectedly	Parent node	Add or correct the parent node after confirming the intended organizational owner.
A role appears in the wrong branch	Parent position	Correct the position’s parent relationship; do not create a duplicate role merely to change the diagram.
A unit shows an unexpected vacancy count	Position links and assignment end dates	Inspect the positions and assignments behind the count. Treat it as a review signal, not an automatic staffing decision.
The hierarchy omits a location	Position location link	Locations are not tree nodes in the same view; verify the position’s location relationship.
A viewer expects broader access because they manage a branch	Assigned verbs and scopes	Configure access explicitly. Reporting hierarchy does not grant entity capabilities.

Permissions and data-quality limits

Viewing or changing the underlying Nodes, Positions, or Assignments records requires the corresponding capability and may require matching scope. The chart does not override those controls. Use the hierarchy for structural understanding. It is not an authoritative source for payroll, legal reporting, emergency contact records, work attendance, or access certification. Confirm those matters in their own records and approved processes. Example organization organization chart in KayanOS.

Example organization organization chart in KayanOS.

Build the structure in Nodes and locations.
Define reporting roles in Groups, positions, and assignments.
Review service staffing windows in Shifts and timesheets.

​When to use it

​Configuration

​Workflow

​Worked example

​Testing

​Troubleshooting

​Permissions and data-quality limits

​Related guides