How can we help you?

Tiered Offices and Departments

all_tiers.png

Greenhouse Recruiting's tiered offices and departments feature allows your organization to express the exact department or office structure you need to support offices all over the world, multiple brands within one Greenhouse account, or departments and sub-departments. Using this feature your organization can created nested layers of offices and departments that are subordinated to one another.

Use Case: With a flat organizational structure, all departments and offices are structured on a single level, respectively. With this flat structure, it is impossible to organize offices in Boston and New York under a region like Northeast, or to nest Product and Engineering departments under R&D. This limits an organization's ability to roll up their jobs for reports, easily configure the correct permissions across their organization, or effectively distinguish large sections of the recruiting organization from each other.

In this article, we will cover how tiered offices and departments impact:

  

Office and Department Creation/Deletion

While the process of adding new offices and departments in your organization is exactly the same as a non-tiered, flat organizational structure, users will find an added dropdown menu to select whether the newly created office or department should be subordinated to existing office/department.

Screen_Shot_2019-06-06_at_4.01.38_PM.png

One created the office or department will be nested under the parent office or department and can be accessed by expanding the parent item. 

Screen_Shot_2019-06-06_at_4.02.22_PM.png

 

Job Board and APIs

No matter what style of job board integration you use, updating your organization to use tiered departments or offices will adjust how things look. For organizations using the Greenhouse-hosted board or an iframe on an external career site, you will see a series of indents that distinguish departments and sub-departments with indents.

If a specific department does not have any nested departments AND does not have any jobs, it will be hidden on the job board.

As an example, let's imagine the below structure represents our departments and tiered sub-departments:

  • Business
    • Accounting
    • Legal
    • Sales
  • Juicing Innovation
    • Blender Technology
    • Juice Maximization
  • R&D
    • Product Engineering
      • Solutions Engineering
      • Team Delta
    • Security & IT

If there were no jobs in Legal or Accounting, Business would also be removed from the board. If Product Engineering has one job while Team Delta and Solutions Engineering were both empty, the two empty sub-departments will disappear while Product Engineering will remain as-is.

For organizations using any of the API-driven job boards, you will want to have your tech team take a look at the documentation on developers.greenhouse.io to ensure that moving a department underneath another one does not inadvertently remove it from your job board altogether. Our updated methods support listing out departments and sub-departments (and offices and sub-offices), so your team will also be able to recreate a nested structure directly in Greenhouse if that's something you are interested in.

  

Permissions

The tiered structure still allows your organization to assign permissions to all future jobs in a specific department and office combination, but there may be more situations where a job may be simultaneously affected by two different rules. As an example, let's imagine the below structure represents our departments and tiered sub-departments:

Departments:

  • R&D
    • Product Engineering
      • Team Delta
      • Solutions Engineering

Offices:

  • USA
    • Northeast
      • Boston
    • Northwest
      • Seattle

A single user could be configured to be an Interviewer on all Team Delta roles in Boston AND a Job Admin: Standard on all Product Engineering jobs in the Northeast. In this case, the more department-specific of the two rules (Team Delta + Boston) will win out. But in the case of an equivalent tie, like R&D + Boston vs. R&D + Seattle, the higher of the two job permissions (Job Admin: Standard) will be granted.

Now, in unlikely event of an even more specific scenario where the two roles are both Job Admins with the same number of permission stripes, the older of the two permissions will be granted. Because of this possibility, we recommend that you are as specific as possible when setting up Permission rules.

 

Approvals

Approvals have always suffered from a tiered structure, since you could set up an approval rule that covers all Boston jobs and another one that covers all R&D jobs. In this case, an R&D job in Boston would defer to the Department rule, since Departments are typically smaller and thus more specific than Offices.

In regards to Approvals, we follow a similar pattern as with permissions.

Departments:

  • R&D
    • Infrastructure
      • Site Reliability Engineer

Offices:

  • USA
    • California
      • Los Angeles
    • Northwest
      • Seattle

An approval process for a Site Reliability Engineer in Los Angeles will always win out over all Infrastructure roles in California. In the case of a tie, the more specific Department will win out, so Site Reliability Engineer in USA will always be assigned over R&D jobs in Los Angeles.

When adjusting your default approvals, it may be helpful to think about who the fallback approvers should be at each of the high levels before assigning approvers to more specific combos. Assigning someone as the approver on All Future Jobs will ensure that every job opened will always have an approver, even if no department and office is selected. From there, you might set an additional fallback for all USA jobs and another for all R&D jobs to ensure that someone else will always be added as an approver should the job creator select the wrong department or office during the job setup process.

 

Reports

Most reports will continue to function exactly like they, but there are a couple whose logic has been adjusted as part of this feature. The Department Summary Report and the Department view of the Recent Applications, Number of Hires, and Interviewing Activity Reports will now list out the top-level departments in your tree. If we take the same tree as earlier:

  • Business
    • Accounting
    • Legal
    • Sales
  • R&D
    • Product Engineering
      • Team Delta
      • Solutions Engineering
    • Security & IT
  • Juicing Innovation
    • Blender Technology
    • Juice Maximization

The reports would only list Business, R&D, and Juicing Innovation, but the numbers in the reports for Business would also encompass everything within Accounting, Legal, and Sales. These roll-up numbers are a great way to see what is going on with your business units as a whole, and it may be helpful to consider your reporting needs when designing your tiers.

 

Filters and Dropdown Menus

Sharp-eyed users might have noticed that various selectors changed slightly over the past month or so. These adjustments were made to support the new tiered model and will allow you to easily see your organizational structure when filtering across the app. They all generally work the same as they did before, but should offer much more flexibility across Greenhouse.