People Connect Team members make use of GitLab's ChatOps
functionality to automate creation of Onboarding, Offboarding and Career Mobility issues. By executing a
Slack command a pipeline is triggered in the
employment-automation project, which runs the
related job and replies with a link to the newly created issue.
When these employment issues are created, we also add it to the team member's epic. If there's no existing epic yet, we create one in the Team Member Project. The epic has the team member's name as the title and this is also how we do the lookup for the epic.
The templates used for the creation of the issues and the issues itself are in two different projects. Templates live within the
people-group, while the issues live in the
Team Member Epics group. The templates are public but the issues remain private. Any updates to the templates can be done in the Employment Templates project.
See our Onboarding Automation Flow for more information on current onboarding automations and manual triggers.
See our Offboarding Automation flow for more information on current offboarding automations.
See our Career Mobility Automation Flow for more information on current Career Mobility automations and manual triggers.
We add all the employment issues for the team member in one epic. To de-clutter the epics, we set up automation to close these epics.
We have a scheduled pipeline to close those epics that have no open issues linked to them. This pipeline will add a comment on the epic that it is being automatically closed.
Currently, the pipeline is scheduled to be run at 11:00 AM UTC on every Wednesday
Note that when a new issue is added to a closed epic, we will re-open the epic.
Many of our automation's regarding team members rely on some employment templates. These allow us to dynamically create department and role specific tasks that can then be maintained by the departments themselves.
|Access Request||Click Me|
|Career Mobility||Click Me|
First things first we will have to solve the issue of:
What project does or should my template live in?.
We currently have a two different projects responsible for housing templates:
Now that we have successfully navigated to the corresponding project, we can start creating our template. To ensure that we are able to create the associated templates correctly, we follow quite a strict naming convention.
To start viewing the different potential tasks, lets navigate to the
.gitlab/issue_templates folder of the associated project.
All of the
issue_templates folder's children, ie:
onboarding_tasks, offboarding_tasks, etc are mapped to a specific task.
In our task directory we can also create generalized tasks for a specific entity, country, or department.
These will be added to the specific task based on the team members current entity, country, department, and role. More on how these work in this section.
Now that we have successfully navigated to the correct corresponding task folder, now comes the tricky part, finding the folder name for your department.
For all department folders they will follow this convention:
department_nameto be lowercase, and spaces replaced with
For the majority of departments this will be the case, although we must note that these can differ from what your department is actually called. For example, Public Sector would be referred to as
If you are unsure of what your departments name in Workday is, please open an issue in the People Group Engineering project and we will get back to you with the name and location of the templates for the desired role.
All of the role files will follow the same naming convention:
<role_name>to be lowercase, and spaces replaces with
department directories, as well as the
role files will always follow the same naming convention.
To help better understand the workflow on how this works, lets walk through creating a full blown template hierarchy.
Let's say we have a new team member, John Doe, who is joining GitLab as a People Group Fullstack Engineer. John would be in the People Group division, and the People Operations department. John currently lives in the United States and would fall under the GitLab Inc entity.
Now that we have this information, we can go ahead and create templates for each of the highlighted fields if we would like to. Let's create some new templates for the onboarding tasks regarding this role.
To get started let's navigate to the correct project and associated onboarding tasks folder.
Now that we are in our task folder we can see some directories following the
department_<department_name> naming convention. Let's hold off on creating or finding that directory as we first would like to create entity, country, division, and department specific onboarding tasks.
Entity, country, division, and department templates will always be added to the specific tasks folder and not the associated departments folder.
I find looking at the org chart in Workday (View All Apps > Directory > My Org Chart) to be useful for clarifying how some of these hierarchical structures roll into one another and can help clarify what the file name may be called.
Let's start off with creating an entity wide template for anyone in the Inc department by creating a new file in the onboarding tasks folder.
Because our entity is referenced in Workday as
Inc, and we must follow the same naming convention, our file would be named:
Now we can fill in our entity specific onboarding tasks into the template. Once merged this will then be added to all team members onboarding issues in that entity.
Since our new team member John lives in the United States, lets go ahead and create another file. This time we follow the same naming convention and name this:
We can then go in and fill out the desired information we wish to include here for all onboarding team members that live in the United States. Once merged, any new onboarding issues opened for team members in the United States, will include this template along with the rest of their department/role/entity specific tasks.
Let's also create a division specific task, not only for John, but everyone in the People Group.
Once again following the same naming convention, we would create a file named:
division_people_group.md. Once we add the desired information to this file and merge, we will begin to see this added to all onboarding issues opened for individuals within the People Group.
And finally, before we get to the role specific onboarding task, lets create another task for anyone that may be in the People Operations department.
One more time following the same naming convention as some of the previous steps, let's create a file named:
department_people_operations.md in which again we can add our information to and merge to start seeing the changes added to onboarding issues for all team members in the People Operations department.
Because John's department would be People Operations, we would follow pretty much exactly the same name as our department wide template above. We would name this directory
We can now add role specific templates to this directory.
To create the role specific task file we will need to ensure we have the team members full job title. In this case, John is joining as a People Group Fullstack Engineer, which would follow the naming convention from above, and end up being named:
Now any one in the in the People Operations department that is onboarding for the People Group Fullstack Engineer role will include this template in the onboarding issue.
Now finally we have successfully created country, entity, division, department, and role specific tasks for the new team member. 🎉