Support app uses Support API as a client to communicate with Zendesk by calling the /support-tickets endpoint. Services.support_api is instantiated in app/lib/services.rb.
The endpoint is exposed via gds_api_adapters gem's .raise_support_ticket method, which is invoked by the ZendeskTicketJob.
The ZendeskTicketJob is created by the ZendeskTickets class, which has a raise_ticket method that takes an object of type Zendesk::ZendeskTicket (or any child class thereof). ZendeskTickets is instantiated in the RequestsController on submission of one of the live Support forms (one of the forms in the "User access", "Content request", "Technical support", "Campaigns", "Feedback for tools in Beta", "Topic taxonomy requests" or "Other requests" groups). The resulting ticket is tagged as per the tag method in whichever Zendesk::ZendeskTicket subclass it is, e.g. content_amend tag for the ContentChangeRequestTicket as well as the default govt_form tag present on the parent class.
Tickets are created 'unassigned' and tagged as described above. Zendesk then routes the ticket to the correct group based on its tags.
For example, sticking with the content change request, we can see in this example Zendesk ticket that it was automatically triaged based on the Gov't Form content change requests to 2nd Line--GOV.UK Content Triage, Gov't rule, which matches on unassigned tickets (Group Is -) that have the tags content_amend and govuk_form, to assign the ticket to the 2nd Line--GOV.UK Content Triage, Gov't group. There are similar rules for content advice, publisher technical fault requests and many more.
See all of the existing routing rules by visiting https://govuk.zendesk.com/admin/objects-rules/rules/triggers/ and filtering by: Conditions -> Tags -> Contains at least one of the following -> govt_form.