Provisioning
This document details the process for provisioning and deprovisioning agents in Zendesk.
Note
- All sections in this section require
Administratorlevel access to 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:
- 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.
- 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:
- 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
- Looks if the email is currently in user in Zendesk
- 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
- 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
Note
- Requesters must first have a fully created light agent account. If they do not have one, direct them to have one created first.
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:
- Submit a HelpLab request by selecting
Background Checksunder the People Team dropdown. On the next page, selectIdentity VerificationorOtherfrom the dropdownWhat 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!
- Replace NAME with the requester’s name
- Replace ISSUE with the link to the Access Request issue
- This should be a quick link to that form
- Note the Access Request issue that you have contacted the People team to verify US citizenship.
- 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.
- If the People team verifies the citizenship:
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.
f895738e)
