Plan speech transcription for IFS service notes

Explore this learning path

Documentation-based guide draft · Reviewed against sources on 2026-09-27 · Not executed in an IFS environment. IFS references use 26R1 unless stated otherwise. Confirm available APIs, components, and permissions in your installed release.

Create an Azure Function that accepts a short WAV recording, calls Azure Speech, and returns recognized text for a user to review before adding it to an IFS service note. The lab supports one explicit audio format instead of claiming every uploaded audio file will work.

Before you start

Use an Azure Speech resource, its region/key, a development Function App using the Node.js v4 programming model, Azure Functions Core Tools, and a supported Node.js runtime. Record only a short fictional note with the speaker’s permission.

Prepare mono, 16-bit PCM WAV at 16 kHz, shorter than 60 seconds. If your recording is another format, convert it using an approved media tool first; changing its filename or Content-Type does not convert audio.

1. Create the function project

Use the Azure Functions Node CLI quickstart to create a JavaScript HTTP-trigger project with the v4 programming model. Confirm that @azure/functions is a dependency and the generated function files are registered by the package’s main entry/glob.

Add SPEECH_REGION and SPEECH_KEY to local development settings, which remain outside source control. Set the same values through Function App configuration/secret references when deployed. Use a dedicated lab resource/key.

2. Replace the generated HTTP handler

For a CommonJS JavaScript project, use:

const { app } = require('@azure/functions');
app.http('transcribe', {
  methods: ['POST'], authLevel: 'function',
  handler: async (request) => {
    if (!/^audio\/(wav|x-wav)(;|$)/i.test(request.headers.get('content-type') || '')) {
      return { status: 415, jsonBody: { error: 'PCM WAV required' } };
    }
    const audio = Buffer.from(await request.arrayBuffer());
    if (audio.length < 44 || audio.length > 2 * 1024 * 1024
        || audio.toString('ascii', 0, 4) !== 'RIFF'
        || audio.toString('ascii', 8, 12) !== 'WAVE') {
      return { status: 400, jsonBody: { error: 'Invalid or oversized WAV' } };
    }
    const region = process.env.SPEECH_REGION;
    const key = process.env.SPEECH_KEY;
    if (!region || !/^[a-z0-9-]+$/.test(region) || !key) {
      return { status: 500, jsonBody: { error: 'Speech service is not configured' } };
    }
    try {
      const response = await fetch(
        `https://${region}.stt.speech.microsoft.com/speech/recognition/conversation/cognitiveservices/v1?language=en-US&format=detailed`,
        {
          method: 'POST', body: audio, signal: AbortSignal.timeout(30000),
          headers: {
            'Ocp-Apim-Subscription-Key': key,
            'Content-Type': 'audio/wav; codecs=audio/pcm; samplerate=16000'
          }
        }
      );
      if (!response.ok) return { status: 502, jsonBody: { error: 'Speech request failed' } };
      const result = await response.json();
      const text = result.NBest?.[0]?.Display || '';
      return { jsonBody: { recognized: result.RecognitionStatus === 'Success', text } };
    } catch {
      return { status: 502, jsonBody: { error: 'Speech service unavailable' } };
    }
  }
});

The header checks are a small lab guard, not a full WAV decoder or a production upload-security boundary. The caller must supply the specified audio format. Enforce request limits at the hosting/gateway boundary too, because the handler reads the body into memory.

3. Test with a real short recording

Start locally with func start. Send your lab recording:

curl.exe -X POST http://localhost:7071/api/transcribe -H "Content-Type: audio/wav" --data-binary "@lab-note.wav"

Expected output is JSON with recognized: true and a transcription resembling the spoken fictional note. Core Tools normally disables function-key authentication locally; do not infer that the deployed endpoint is anonymous. In Azure, provide the function key through the protected x-functions-key header, or use your organization’s stronger gateway/user-authentication setup.

4. Connect the result to an IFS review step

Have the approved client/integration upload the WAV bytes to the function. Display the returned text in an editable review field alongside the target service record reference. The operator must correct names, quantities, and equipment IDs before saving through the record’s supported IFS update API/page.

Keep transcription and record update as separate operations. Do not treat recognized speech as an instruction to release, delete, or approve a business record.

5. Test errors and clean up

Test silence, a non-WAV file, an oversized recording, a wrong Speech key/region, and a recording with a deliberately ambiguous equipment name. Confirm failures do not overwrite an existing IFS note and the user can reject the transcript.

Do not log the audio, key, or full transcript by default. Delete lab recordings/transcripts according to the agreed retention period, disable the test function, and retire its credential when finished. This implementation has not been deployed to your Azure or IFS environment.

Function API reference: Node.js programming model.

Sources and scope

• Azure Speech short-audio REST API

Older IFS Applications examples are historical context, not evidence of Cloud compatibility. No third-party code, screenshots, or downloadable workflows are reproduced.