Collaborators

overview 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 the super user recommendation 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 best practice at least one cycle admin should hold all three roles simultaneously — owner , final approver , and collaborator on everyone this makes them the effective "superuser" of the cycle assignment options 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 option 1 no collaborators not recommended at minimum, you need at least one admin as a collaborator on everyone (see super user recommendation above) avoid this option option 2 yes — same collaborators for everyone 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 you cannot assign a collaborator to the ceo/head of org — that's what final approvers are for final approvers are effectively collaborators on the top of the tree you cannot collaborate on yourself if an hr admin is also a reviewer in the tree, they will not see collaborator only fields in their own pod this is a minor edge case but worth knowing option 3 yes — different collaborators for different parts of the org 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 collaborator permissions there are three permission levels for collaborators view only — can see the pod but cannot make changes edit — can make edits to that manager's pod edit & submit — can edit and also submit on the manager's behalf 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 post launch behavior once the cycle is launched the assignment option (none / same for everyone / different by group) is locked the permission level is locked the bulk assignment fields are locked however, you can still add and remove individual collaborators while the cycle is live to do so pause the cycle navigate to the collaborators section click on the specific manager in the tree and manually add or remove a collaborator resume the cycle the bulk configuration is read only after launch, but one off changes at the manager level remain available throughout the cycle