Building an employee service catalog with Zendesk - Part 4: Extending your service catalog with AI coding assistants

After completing the three-part service catalog series, you have a working application with a catalog browser and a request submission form. This article shows you how to use an AI coding assistant to extend what you've built. The prompts in this article were written and tested using Claude. You can use similar prompts with other AI coding assistants such as ChatGPT or GitHub Copilot, though you may need to adjust the wording slightly to get the best results.

For each enhancement, you'll find a prompt you can give directly to an AI coding assistant. Each prompt is written to match the actual files, functions, and routes in your application.

Warning: The prompts in this article generate code that creates and modifies Zendesk tickets, reads service catalog data, and routes employees through request workflows. Before deploying any AI-generated changes to a production environment, test them thoroughly on a development or sandbox Zendesk account. Verify that tickets are created with the correct form ids, custom field values, and assignee routing. Confirm that error handling works as expected by intentionally triggering failure conditions such as invalid item ids or revoked API tokens. AI-generated code can contain subtle logic errors that only appear under specific conditions, so do not rely on the code appearing to work with just a single test.

This tutorial is the fourth part of a series on building an employee service catalog with Zendesk:

• Part 1 - Laying the groundwork
• Part 2 - Building a custom catalog browser
• Part 3 - Letting employees submit requests
• Part 4 - Extending your service catalog with AI coding assistance - YOU ARE HERE

Because the tutorials build on each other, tackle them in order and finish each tutorial before moving on to the next one.

Before you start

Each prompt assumes you completed all three parts of the series and have the following file structure:

service_catalog/
  .env
  static/css/
    main.css
    request_form.css
  templates/
    catalog_browser.html
    index.html
    request_form.html
  app.py

When using an AI coding assistant, the model needs to see your existing code before you ask it to make changes. If you paste a prompt asking it to modify app.py without sharing the file, it will generate something that may conflict with your existing code.

Most AI assistants support two ways to share your file:

• Attach the file directly: Claude, ChatGPT, and Gemini all support file uploads in their chat interfaces. This is the simplest approach and avoids any formatting issues that can occur when pasting code manually.
• Paste the file contents: If you're using an AI assistant that doesn't support attachments, or you're working in an API or IDE integration, paste the full file contents into the chat before sending your prompt.

Either way, include the file before asking for changes, not after.

Important: AI-generated code may reference outdated Zendesk API endpoints or incorrect field names. Always verify any API calls against the current Zendesk API reference before running them in production.

How to use the prompts in this article

Each prompt in this article follows the same four-part structure so you can read them consistently and adapt them to your own needs:

Part	What it does
Role	Tells the AI what kind of developer it should behave as
Task	Describes the enhancement in plain language
Instructions	Specifies the input, the transformation, and any constraints
Safety	Sets limits on what the AI should not change and requires error handling

To use a prompt, paste the relevant file (for example, app.py or catalog_browser.html) into your AI coding assistant conversation before sending the prompt. This gives the model the context it needs to produce changes that fit your existing code rather than generating something that conflicts with it.

If you want to build an enhancement that isn't covered here, use this template as your starting point:

You are a [language] developer extending an existing service catalog application.

Task:
[Plain-language description of the enhancement]

Instructions:
- Input: [Which file to modify, which function or route is involved,
  and what data is available]
- Transformation: [What to add or change and how it should work]
- Constraint: [What to preserve, what format to return, what not to change]

Safety:
- Do not modify [specific functions or variables that should stay unchanged].
- Use environment variables for all credentials.
- Add error handling for failed API requests and unexpected responses.
- Add comments explaining what each new part of the code does.

The more specific you are about your existing code structure, the more useful the output will be.

Enhancements

Adding pagination to the catalog browser

The zendesk_get() function in app.py currently retrieves only the first page of results from the Zendesk API. If your catalog grows, employees will only see a subset of available items. This enhancement updates zendesk_get() to support cursor-based pagination and adds Next and Back navigation buttons to catalog_browser.html.

You are a Python and Flask developer extending an existing service catalog application.

Task:
Add cursor-based pagination to the catalog browser so the app can retrieve
and display more than the default number of items returned by the Zendesk API.

Instructions:
- Input: The existing app.py contains a zendesk_get() helper function and a
  list_items() route at /service_catalog. The route calls
  /api/v2/help_center/service_catalog/items and renders catalog_browser.html.
  The Zendesk API returns paginated results with a meta object containing
  after_cursor and has_more fields.
- Transformation: Update zendesk_get() to accept an optional cursor parameter
  and pass it as the page[after] query parameter when provided. Update
  list_items() to read the after_cursor and has_more values from the API
  response and pass them to the template. Update catalog_browser.html to show
  a Next button when has_more is true, passing the after_cursor value to the
  server as a query parameter to load the next page.
- Constraint: Do not change the existing search functionality in list_items().
  Pagination controls should only appear when there are multiple pages of
  results. Pass the cursor as a query parameter in the URL — do not store
  it in a session or cookie.

Safety:
- Do not modify the ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN
  variables or the BASE_URL value in app.py.
- Use environment variables for all credentials.
- Add error handling for cases where the cursor is invalid or the API
  request fails.
- Add comments explaining how the cursor is passed between pages.

Adding graceful error handling

The zendesk_get() function and the create_ticket() route both use response.raise_for_status(), which raises an unhandled exception if an API call fails. This enhancement wraps API calls in try/except blocks and adds a user-friendly error page so employees see a clear message instead of a generic Flask error page.

You are a Python and Flask developer extending an existing service catalog application.

Task:
Add graceful error handling to app.py so that when a Zendesk API call fails,
the employee sees a clear, friendly error message instead of an unhandled
exception.

Instructions:
- Input: The existing app.py uses response.raise_for_status() in the
  zendesk_get() helper function and directly in the create_ticket() route.
  If an API call fails, Flask currently returns a generic 500 error page.
  The routes that call the Zendesk API are list_items(), show_item(),
  show_request_form(), and create_ticket().
- Transformation: Wrap the API calls in each route with try/except blocks
  to catch requests.exceptions.HTTPError and requests.exceptions.RequestException.
  Create a simple error.html template in the templates folder that displays
  a friendly message and the HTTP status code if available. Register a Flask
  error handler that renders error.html for 404 and 500 errors.
- Constraint: Do not change the existing logic inside the routes — only add
  error handling around the API calls. Do not expose raw exception messages
  or stack traces to the employee in the browser. Apply the existing styles
  from main.css to the error page.

Safety:
- Do not modify the BASE_URL variable or the authentication logic.
- Use environment variables for all credentials.
- Log the full error details to the console before rendering the user-facing
  error page so you can debug issues without exposing them to employees.
- Add comments explaining what each error handler catches and why.

Routing employees to different request forms

The show_request_form() route in app.py currently renders the same request_form.html template for every catalog item. If you add items with different custom fields (for example, a keyboard request that needs an ergonomic preference field) you will need separate form templates. This enhancement adds routing logic to show_request_form() so it renders the correct template based on the item's form_id.

You are a Python and Flask developer extending an existing service catalog application.

Task:
Update show_request_form() in app.py to render a different request form
template depending on the catalog item's form_id.

Instructions:
- Input: The existing show_request_form() route in app.py at
  /service_catalog/request_form fetches item details using the Show Service
  Catalog Item endpoint and renders request_form.html. Each item in the API
  response includes a form_id field. The current request_form.html has fields
  for itemName, itemId, formId, requesterName, requesterEmail,
  and justification.
- Transformation: Create two additional templates in the templates folder —
  request_form_b.html and request_form_c.html. Each template should include
  the same base fields as request_form.html but replace the justification
  field with a different custom field appropriate for that item type. Add
  a routing dictionary or conditional block in show_request_form() that maps
  each form_id to its corresponding template name and renders the correct one.
- Constraint: Keep the existing request_form.html unchanged as the default
  fallback. The create_ticket() route at /service_catalog/request should
  continue to work for all form types — do not change the route path or
  the ticket creation logic. Replace the placeholder form_id values in the
  routing logic with your own values from your Zendesk catalog.

Safety:
- Do not modify the zendesk_get() function, the BASE_URL variable,
  or the authentication logic.
- Use environment variables for all credentials.
- Add error handling for cases where the form_id does not match any
  known template, and render a clear error message.
- Add comments explaining the routing logic.

Adding client-side form validation

The request_form.html template uses the required attribute on its fields, which relies on the browser's default validation behavior. This enhancement replaces that with explicit JavaScript validation so employees see specific, inline error messages before the form is submitted to the server.

You are a JavaScript developer extending an existing service catalog request form.

Task:
Add client-side validation to request_form.html so employees see clear,
specific error messages when they submit the form with missing or invalid input.

Instructions:
- Input: The existing request_form.html has four visible input fields:
  itemName, requesterName, requesterEmail, and justification. All four have
  the required attribute. The form submits via POST to the create_ticket()
  route at /service_catalog/request.
- Transformation: Add a JavaScript validation function that runs when the
  employee clicks the Submit request button. Check that requesterName and
  justification are not empty strings. Check that requesterEmail matches a
  valid email address format. Display an inline error message directly below
  each invalid field. Prevent the form from submitting to the server until
  all fields pass validation.
- Constraint: Clear each field's error message as soon as the employee
  starts correcting it. Do not change the form's action URL or method.
  Do not change the layout or styling of existing form elements. Add the
  validation script inside the existing request_form.html file — do not
  create a separate JavaScript file.

Safety:
- Do not modify the create_ticket() route in app.py.
- Validation must run entirely in the browser — do not add new API calls.
- Add comments explaining each validation rule.

Showing a confirmation page after submission

The create_ticket() route currently redirects the employee directly to their ticket in Zendesk after a successful submission. This enhancement keeps the employee on your application by rendering a local confirmation page that shows the ticket ID and next steps, with a link to Zendesk if they want to check status.

You are a Python and Flask developer extending an existing service catalog application.

Task:
After an employee successfully submits a request, render a confirmation
page in the app instead of redirecting them directly to Zendesk.

Instructions:
- Input: The existing create_ticket() route in app.py at /service_catalog/request
  creates a Zendesk ticket via the Tickets API and redirects the employee to
  {BASE_URL}/hc/en-us/requests/{ticket_id}. The ticket ID is available from
  data['ticket']['id'] in the API response. The item name is available from
  the request form's itemName field.
- Transformation: Create a new template named confirmation.html in the templates
  folder. The template should display the ticket ID, the name of the requested
  item, and a short next-steps message such as "Your request has been received.
  The IT team will follow up shortly." Include a link to the employee's ticket
  at {BASE_URL}/hc/en-us/requests/{ticket_id}. Update create_ticket() to pass
  the ticket_id and item_name to confirmation.html and render it on success
  instead of redirecting.
- Constraint: Keep the Zendesk ticket URL available as a link on the
  confirmation page — do not remove it entirely. Do not change the fields in
  request_form.html or the route path for create_ticket(). Apply the existing
  styles from request_form.css to the confirmation page so it matches the
  rest of the application.

Safety:
- Do not modify the zendesk_get() function or the BASE_URL variable.
- Use environment variables for all credentials.
- If ticket creation fails, render an error message on the page — do not
  show a raw exception or stack trace to the employee.
- Add comments explaining the success and error rendering paths.