Breadcrumbs

Organizational Hierarchy

The Organizational Hierarchy is the foundation for structuring an Institution in the platform. It models the real-world organization, enabling precise governance, targeted data access, consistent reporting, and scalable configuration. The core concept is a parent-child structure of organizational units (Colleges, Academic Divisions, etc.) from the Institution to increasingly specific branches (courses, co-curricular activities, etc.) that exist to concentrate ownership, scope access, and localize configuration. The hierarchy is segmented into two components: academic and administrative. The academic hierarchy includes the Institution, Colleges, and Departments, which are created based on the data files sent to HelioCampus; these levels cannot be manually created within the platform. The hierarchy's administrative levels include manually created Administrative Divisions and Units.

image-20251029-163210.png

The Organizational Hierarchy is intentionally structured to enable higher levels to define broad configuration defaults for standardization, while lower levels can refine configurations, given that a higher level of the hierarchy didn’t lock the configuration of a setting(s) to prevent downstream changes. Some common features and functionalities that are configured at the hierarchy levels include:

  • Properties and metadata: Codes, names, descriptions, owners, and tags used for search and reporting.

  • Policies and permissions: Role assignments, sharing boundaries, and data accessibility.

  • Feature defaults: Notification preferences, form or workflow templates, dashboard visibility, and integration mappings.

The hierarchy operates on inheritance. Policies, feature defaults, and permissions set at a higher level automatically cascade downward, promoting consistency and reducing duplication. This inheritance structure ensures balance, keeping the platform both coherent and adaptable. In practice, it means the Institution establishes shared foundations (such as default roles, naming conventions, evaluation rubrics, or data classifications) at higher levels and allows targeted exceptions when operations materially differ. Because the Organizational Hierarchy is functionally related to all platform functionality, a well-designed hierarchy reflects decision-making paths, permissions, and ownership.

When platform functionality needs to answer questions such as “who sees what”, “which rules apply”, or “who does this data belong to”, it looks to the hierarchy to determine the relevant structured data. Users granted a role at a hierarchy level gain visibility and capabilities for that level and its associated lower levels; however, users at lower levels see only what level and content they are associated wth. This drives access control, data segmentation, task routing, and reporting, ensuring that dashboards show the right information, workflows reach the right approvers, and content appears where it is owned and maintained.

Cross-Platform Interdependencies

Together, these cross-platform interdependencies mean the Organizational Hierarchy is not just an organizational matrix. It is the platform’s control plane: a single, coherent model that determines who can act, where data resides, how processes flow, and how results roll up—ensuring everyday work aligns with governance at scale.

Access and Permissions

  • Roles assigned at any level grant the least-privilege access necessary for that level and all associated lower levels. For example, when a user is given the Self Study Chair role for a College, they automatically gain visibility for self study content within that College and all of its Departments, courses, etc., but not for other Colleges or the Institution level.

    • If narrower access is required (for example, a single Department's self study), the Self Study Chair role can be assigned at the Department level without expanding visibility elsewhere.

  • Cross-functional users can be assigned multi-level user roles. If a user supports two divisions, assign roles for both divisions rather than creating parallel accounts or “shadow” units. This simplifies audits and respects inheritance.

Reporting and Analytics

  • Standard reports use the hierarchy to aggregate by level. For example, a dean can view Department metrics, then drill down to programs.

  • Calculations can respect higher-level overrides. For example, if a rubric is locked for editing at a higher level of the hierarchy, it cascades down to associated lower levels and is reflected in their reporting.

Workflows, Reviews, and Automations

  • Approval paths are resolved based on a record’s associations. Submissions route to the nearest configured user(s) up the level-branch, with fallbacks to parent levels/users if a lower-level user lacks permissions. This prevents orphaned tasks and reduces manual triage.

  • Notifications and SLAs inherit defaults from higher levels. Lower-level exceptions can change due dates, assignees, or escalation rules for a specific level while retaining the global pattern.

Templates, Standards, and Configuration Defaults

  • Forms, rubrics, evaluation criteria, and communication templates can be set globally and inherited, ensuring consistency.

  • Locking configurations can be applied at selected levels and settings to control cascaded information.

Auditing, Compliance, and Change History

  • Every significant action can be viewed through a hierarchy lens: who acted, on which unit, and with what inherited or overridden settings. This supports internal audits, accreditation reviews, and policy attestations.

  • Structural changes are logged with effective dates, so downstream impacts on access, routing, and reports are traceable.

Cross-Level Initiatives and Exceptions

  • When work spans multiple levels, the hierarchy remains the authoritative source of ownership while features support cross-level collaboration through shared roles or controlled relations.

  • Exceptions are time-bound and documented. The platform highlights where higher-level overrides exist, so admins can periodically reconcile differences and retire temporary configurations.

Considerations

Before Setup

  • Which systems are sources of truth? Confirm how codes and names will stay in sync.

  • What are the key reporting rollups? Design levels that match how higher-level admins consume information.

  • Where do permissions differ materially? Create level branching where access needs to diverge.

  • Perform setup in the Institution’s test environment to validate inheritance, access, and reporting.

After Setup

  • Communication: Communicate the structure and effects on access and workflows. Track changes and their impacts to ensure downstream effects can be monitored.

  • Consistency and Maintenance: Schedule periodic audits to ensure the current hierarchy and configurations are used.

Best Practices For Setup and Long-Term Maintenance

Setup:

  • Base the structure on authoritative organization data and naming conventions, and validate before implementing. Use consistent names and codes and add descriptions to clarify scope and responsibilities.

  • Start with major levels and add details at lower levels where they provide clear value for permissions, reporting, or workflows.

  • Favor setting policies and defaults high in the hierarchy to ensure accurate cascading to lower levels that should inherit the default.

Long-Term Maintenance

  • Capture the purpose of a level and who owns it. establish ownership and consider defining who approves changes and on what cadence, if different from the level owner.

  • Define a clear request process for creating, renaming, merging, or retiring levels. Record rationale and effective dates.

    • If a structural change is needed, contact HelioCampus for assistance and plan effective dates to ensure smooth transitions for potential permissions and reporting.

  • Conduct quarterly reviews of user access to reduce excess accounts, obsolete processes, or outdated configurations associated with excess users.

Frequently Asked Questions

How deep should the hierarchy go?

Ideally, all levels of an Institution will be set up in the platform to ensure a holistic approach across its features and functionalities. Levels should be set up deep enough to ensure enough support for access and reporting needs without creating a maintenance burden. Avoid branches with only one lower level unless they represent clear governance boundaries.

Can levels move after creation?

Yes, but only with the assistance of HelioCampus. If the hierarchical structure of an Institution changes, please contact Support to facilitate implementation. Changes to the Organizational Hierarchy should never be sent to HelioCampus via data files. Learn more about getting support.

What if two units share resources?

Keep the hierarchy authoritative for ownership. Use groups, relations, or shared-role constructs for cross-collaboration.