Sync Repo for Knowledge (KCS)

We are Transitioning to a Sync Repository for our Knowledge Base.

  • Target date: March 2, 2026

Since launching our GitLab Knowledge Base in ZenDesk in June 2025, we've gained valuable insights into both its capabilities and its constraints. As Knowledge management evolves alongside GitLab's growth, we've identified an opportunity to better align our tooling with our workflows and long-term strategic goals. This means that we will transition to a sync repository model beginning in March 2026.

This will also help us Enable integrations with GitLabDuo, automation and federated search solutions. We will be able to have internal comments, use of tags and Labels, as well as deeper Reporting capabilities etc..

Project Date Status Notes
Training
Testing
Migration of articles
Documentation
Comms
Labels & Tags
Cut Over Date

What we Gain

  • Internal Comments
  • Use of Tags, Labels
  • Ability to have tracking by "teams" (example, Support, Solution Architects, CS)
  • Dogfooding our own Product
  • Utilize GitLab Duo to help write articles
  • Utilize GitLab Duo to create automation
  • Ability to add tags/labels that we can categorize
  • Ability to create KCS workflow across GitLab
  • Version Control
  • History (tracking, reporting
  • Ability to create article and post to both US Gov and Global
  • Ability to create permissions/roles
  • Metrics and Tracking ability realtime (tagging, Labels, etc.)
  • Tighter controls for publishing (merge requests)
  • Familiarity with process (as this was the process before)
  • More integration points (slack, etc.)
  • Ability to look for duplicate title(s)
  • Ability to have review cycles based on dates/reporting.
  • Full access across GitLab for anyone to contribute

What we must maintain/have

  • ability to go from a support ticket to create a knowledge article
  • permissions/roles
  • Internal and External articles

Repository will move to a GItLab Sync Repository

  • We need to migrate existing stuff to the sync repo. We moved all the support pages stuff as a courtesy to help make it easier. I’d assume it would be a “slowly as we go” type deal though.

We will Stop creating articles in ZenDesk at a certain point for this move. We will message this

  • When that time comes (i.e. we officially go live on the sync repo), we would remove people’s ability to create them in Zendesk

How this will work in a GitLab Repository situation.

  • Create MR in repo -> Review -> Merge -> Trigger to sync repo -> Sync occurs -> Article created

Continue to use something from within a support ticket to “need to create an article… click here, takes you to the repository to create

  • We can likely either change the link or do something to direct them to like an issue template or something

Support Engineers still search and link knowledge(and docs) to support tickets by searching

  • Articles are still in ZD so still visible by customers, searchable, linkable, etc. The articles stuff is in GitLab, a sync script pulls that data and converts it into article objects for Zendesk

Permissions and Roles in a Sync Repo

  • GitLab permissions basics.

Templates:

  • .md files
  • Will be in a “Templates” folder- Break/Fix, FAQ, Troubleshooting, How To, Process
  • Templates will not be visible to customers

Process

  • We will continue to have Draft, In progress, Published
  • MR in draft, then remove draft (in progress), then when merged it is published

Articles will still be visible to customers on Support Portal (Knowledge) and wont see any differences. Customers won’t see any difference.

Edited by Kirsty Allen