Content last updated 2025-12-26

Provisioning

Documentation on Zendesk user provisioning

This document details the process for provisioning and deprovisioning agents in Zendesk.

Role based entitlement

2 days after someone starts working at GitLab, an access-request issue is generated based off their role based entitlements. We would manually provision users based off the request itself.

To do this, you will need to:

  1. Create the user in Zendesk (the role to be used should be included in the role based entitlement access request issue). Ensure their groups and other such settings are accurate (see the access request issue). See Manually creating an agent for more info on creating the user.
  2. Associate the correct app in Okta (see Assigning an app via Okta for more info) if required.

After you have done so, mark off the items in the access request issue.

Special request

Any special request issues to provision on either Zendesk instance not related to role based entitlements must be done via an access request issue. Do note this will require approval from the Zendesk system owner to proceed.

See Role based entitlements for information on what to do when it comes time to provision it.

Zendesk Global light agents

This is handled by the requester sending an email to the service desk address of the Zendesk Global Light Agent Provisioning Requests project. Doing so creates an issue, which will fire a webhook to the Light Agent Provisioning project.

This triggers the bin/process script, which does the following:

  1. Reviews if the email of the requester has the domain of gitlab.com
    • If they do not, a comment is made on the original issue telling them they are not qualified (and closes the issue)
    • The process is then stopped
  2. Looks if the email is currently in user in Zendesk
  3. If a user exists, it then checks if they are already an agent
    • If they are, a comment is made on the original issue telling them they are already an agent (and closes the issue)
    • The process is then stopped
  4. It will then perform actions to create or update the user to be an agent with the required metadata
    • It will then comment on the original issue telling members of the Customer Support Operations to Assign the app in Okta

Specialized Zendesk Global light agents

Specialized groups of light agents are allowed to file specific types of Internal Requests. These agents require specific tags to be added or removed based on their team:

Team Required Tag
Partner Support partner_support_agent
Order Management order_management_team
OEM Management oem_management_team

You should only ever be asked to either add or remove that tag (and it must be via an access request issue).

Zendesk US Government light agents

As these require the tech stack provisioner to manually provision these, an Access Request issue is required.

Once one has been received and approved, the process will go as follows:

  1. Submit a HelpLab request by selecting Background Checks under the People Team dropdown. On the next page, select Identity Verification or Other from the dropdown What type of support do you need? and use the prompt below to fill out your request:

    Greetings all!

    Can you verify if NAME is a US Citizen? They are requesting access to the US Government Zendesk instance via ISSUE which does require it.

    Thanks!

  2. Note the Access Request issue that you have contacted the People team to verify US citizenship.
  3. Depending on the response from the People team, your next actions will vary:
    • If the People team verifies the citizenship:
      • Create the Light Agent manually in the Zendesk US Government instance.
      • Associate Zendesk US Government app in Okta (see Assigning an app via Okta for more info)
      • Update the issue letting them know it has been provisioned.
    • If the People team cannot verify the citizenship:
      • Comment on the Access Request issue noting citizenship could not be confirmed and that the issue will be closed, as no further action can be taken without verification from the People team.

Deprovisioning

You will, from time to time, get a request to deprovision an agent (these will mostly stem from Offboarding tasks). To deprovision an agent, go to that agent’s page in Zendesk and do the following:

  • Unassign any active tickets (less than Closed) from that agent (assign them to their manager)
  • Delete any Support Team files associated with the user (if applicable)
  • Delete the user from Zendesk
  • After doing so, do the following on the issue requesting the deprovisioning
    • Check the corresponding boxes on the request issue

Assigning an app via Okta

To associate an app via Okta, you will add the person’s email to the corresponding google group as a Member:

If you ever need to remove the person, locate them in the group and click the Unassign option.

Last modified February 12, 2026: Remove aliases from frontmatter (f895738e)