Collaborators

Collaborators were designed with HR Business Partners in mind. They allow a customer to give a specific person access to one or more managers' pods in the cycle — so they can view, edit, and potentially submit on behalf of those managers.

Example: An HRBP assigned to the Engineering department gets collaborator access to all Engineering managers' pods, so they can assist or act on their behalf during the cycle.

A common misconception: customers often assume that being an Owner of the cycle means they can edit anyone at any time. This is not true. Cycle ownership allows you to pause, conclude, and edit settings — but it does not grant blanket edit access to all pods.

The only way to guarantee a user can edit anyone at any time is to make them a collaborator on the entire tree.

There are three options for how collaborators are assigned. Whichever option you choose locks upon launch and cannot be changed while the cycle is live.

Not recommended. At minimum, you need at least one admin as a collaborator on everyone (see super user recommendation above). Avoid this option.

The simplest option. Add collaborator names at the top and they are automatically assigned to every manager in the tree. Great for cycles where a small group of admins should have visibility across the whole org.

Things to note with this option:

Use this when collaborators are assigned based on a specific attribute like department, location, or team. ChartHop will surface a field selector — choose the field you want to assign by (must be a single-select or enumerated field, not a free-text field), and it will list all the possible values.

For each value (e.g., each department), you assign a collaborator. ChartHop then looks through every reviewer and approver in the tree and assigns that collaborator to any manager who has at least one eligible employee with that attribute in their pod.

Example: Assigning Ace to Marketing — ChartHop finds every manager with at least one Marketing employee in their pod and makes Ace a collaborator on them.

⚠️ Watch Out at Higher Org Levels

As you go higher up the org chart, managers often have multiple departments, locations, or teams under them. When a collaborator is assigned to a manager, they see everyone that manager sees — there is no way to say "assign them to this manager but hide these people."

Example: If Engineering and Product both roll up to the same VP, assigning an Engineering collaborator to that VP means they'll also see the Product employees in that VP's view.

Always double-check the highest levels of the tree with the customer to confirm they're comfortable with the full scope of what each collaborator will see. Sometimes the right call is to manually remove a collaborator from a specific high-level manager rather than have them see everyone under that person.

Manual Overrides#

Regardless of how collaborators are assigned programmatically, you can always click on any individual manager in the tree and manually add or remove a collaborator on a one-off basis. This is useful for handling exceptions after the bulk assignment logic has run.

There are three permission levels for collaborators:

Important: The permission you select applies to all collaborators — you cannot have some collaborators on view-only and others on edit. It is a single setting for everyone.

We recommend Edit or Edit & Submit at minimum. View-only is not useful for the super user admin who needs to be able to act on anyone's behalf.

This permission setting locks upon launch and cannot be changed while the cycle is live.

Once the cycle is launched:

However, you can still add and remove individual collaborators while the cycle is live. To do so:

The bulk configuration is read-only after launch, but one-off changes at the manager level remain available throughout the cycle.