Permissions: Site Admin

Product tier: Available for Advanced and Expert subscription tiers

Greenhouse Recruiting's tiered offices and departments feature allow 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.

Flat vs tiered organization structure

In a flat organizational structure, all departments and offices are structured on a single level. For example, a flat organizational structure would have offices in Boston and New York with no overlap. Users must be assigned specific permissions for each office location.

A tiered organizational structure can set the two offices under a larger umbrella called "Northeast." By assigning user permissions to the "Northeast" tier (rather than individual offices), the user's permissions can grow and scale with the individual workings of each office.

Tiering can also be applied to departments across the organization. For example, Product and Engineering departments may be united under a larger "R&D" group.

With this flat structure, it may be simpler to conceptualize your organization during the initial stages of using Greenhouse Recruiting, but over time, will be limiting as your organization grows.

Using a tiered structure makes it easier for organizations can generate overarching reports, easily configure the correct permissions across their organization, or effectively distinguish large sections of the recruiting organization from each other.

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 an existing office / department.

Screenshot-of-edit-an-office-box.png

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

Screenshot-of-subordinate-office.png

In the example above, Berlin is a sub-ordinate office of the EMEA office.

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 on your job board. 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

Success

  • Technical Support
  • Customer Enablement

R&D

  • Product Engineering

— Solutions Engineering

— Team Delta

  • Security & IT

If there were no jobs in Accounting, Legal, or Sales, 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'll want to have your web development team take a look at the documentation on our Developers Resources to ensure that moving a department underneath another one does not inadvertently remove it from your job board altogether.

Our APIs 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 Recruiting if that's something you are interested in.

Permissions

The tiered office / department 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 simultaneously be affected by two different rules. As an example, let's imagine the below structure represents our tiered offices and departments:

Departments

R&D

  • Product Engineering

— Team Delta

— Solutions Engineering

Offices

USA

  • Northeast

— Boston

  • Northwest

— Seattle

A single user could be configured to be a Job Admin: Recruiter on all Team Delta roles in Boston AND a Job Admin: Hiring Manager 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 the 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. 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 as they would in a flat organization structure, but can be filtered to show data for individual subordinate offices and departments you select. 

If we take the same tree as earlier:

Business

  • Accounting
  • Legal
  • Sales

R&D

  • Product Engineering

— Team Delta

— Solutions Engineering

— Technical Support

  • Success

— Activations

— Customer Enablement

— Learning Experience

The numbers in R&D can be further refined to encompass specific subordinate departments for Success, such as Activations and Customer Enablement, when reviewing essential reports or creating custom reports using Report Builder.

Build_your_own_department_report_subdepartments_filtered.png

These figures offer a great overview of all your business units, allowing you to gain insights into the individual performance of each tier within your organization.

Report_builder_parent_department_filters.png

Note: Individual sub-departments and offices can only be filtered when the parent office or department is NOT selected.