Support Azure AI Legacy Deployment-Based Endpoints for Reply Cleanup AI

[dschipfel]

Current situation

The Reply Cleanup AI feature is a great addition and helps improve the quality and consistency of ticket responses.

However, many organizations use Azure OpenAI through deployment-based endpoints, as supported by platforms such as Zammad. These environments rely on Azure deployments rather than selecting models directly via modern endpoint configurations.

Suggested improvement

Add support for Azure OpenAI deployment-based endpoints, similar to the configuration available in Zammad.

Typical configuration parameters could include:

• Azure OpenAI Endpoint
• Deployment Name
• API Version
• API Key

Example:

Endpoint:
https://company.openai.azure.com/

Deployment:
gpt-4o

API Version:
2024-02-01

The Reply Cleanup AI feature would then use the configured deployment instead of requiring direct model selection.

Benefits

• Compatibility with existing Azure OpenAI environments
• Easier adoption in enterprise environments
• Reduced migration effort
• Alignment with implementations already available in Zammad
• Better support for organizations with strict governance and security requirements

[edmozley]

Hi Daniel @dschipfel,

This is built and pushed.

Where it is

Every module's AI settings panel now offers Azure OpenAI (your own deployment) alongside Anthropic, OpenAI and OpenRouter. Choosing it replaces the model box with the three fields you listed: the endpoint, the deployment name and the API version. The key goes in the same box as before.

It is not just Reply Cleanup

You asked for it on Reply Cleanup, but it went into the shared provider layer rather than into that one feature, so all ten AI features get it for the same work: Knowledge, CMDB, Workflows, Forms, Problem Management, the LMS, the Knowledge Assistant, the War Room, and both ticket features. Each is still configured independently with its own key, so you can point one at Azure and leave the rest alone if you want to start small.

Details that might save you some time

The deployment name replaces the model, rather than sitting alongside it. On a deployment-based endpoint the deployment already decides which model runs, so there is nothing useful for a model box to do and it is hidden.

The endpoint is accepted however the Azure portal gave it to you - with or without a trailing slash, and with or without "/openai" already on the end. All four spellings resolve to the same call.

The API version can be left blank, in which case it uses 2024-02-01.

If your deployment is a newer one that rejects max_tokens and asks for max_completion_tokens instead, FreeITSM notices what Azure said and retries once under the new name rather than reporting a failure. That retry only fires when Azure's own error text names the replacement, so it cannot loop and cannot mask an unrelated problem.

The part you need to know before you turn it on

I do not have an Azure subscription, so none of this has ever spoken to a real Azure tenant. I want to be straight about what that does and does not mean.

What is verified is everything FreeITSM sends. There are 31 automated checks against a local stand-in that assert the URL we build, the api-key header rather than Authorization: Bearer, the absent model field, the retry above, and controls proving the existing OpenAI path is unchanged. Azure's request and response shapes are the OpenAI ones this codebase has been using for months, so the genuinely new surface is small and it is covered.

What is not verified is anything Azure does at its end: content filtering, api-version differences between deployments, quota behaviour, regional differences. Only a real tenant can answer those, and you have one.

So if you are willing to try it, you would be the first, and I would rather say that plainly than let you find out.

If it does not work

There is a new debug tool for exactly this, at System - Debug tools - D014, Azure OpenAI. It prints the exact URL it built from your settings, the headers it sends, then makes one live call and shows Azure's answer word for word, with a reading of the common failures. A 404 usually means the deployment name rather than a wrong endpoint, and a 401 usually means a key belonging to a different Azure resource, so it says so rather than leaving you to guess.

The output contains no API key - only its first four characters and its length - and no prompt or ticket content, so it is safe to paste into this discussion. If you hit something it does not recognise, that output is genuinely useful to me.

There is no database change, so nothing needs migrating. Pull, hard-refresh the settings page once (the panel's script was previously served without a version, so your browser may be holding the old copy), and the new provider is there.

Thanks for the suggestion, and for the example configuration in your post - it was precise enough to build from directly.