This guide assumes you have completed the Mitel Workflow Setup guide. If the parking lot or workflow has not been configured, start there.
Debugging the Interaction Parking Workflow
When a transfer fails or calls are not routing correctly, work through the steps below in order — each one tells you where in the chain the failure occurred.
1. Check the Parking Lots UI First
In Talkative, navigate to Settings → Parking Lots and open the relevant lot. Any currently parked interactions are listed here in real time.
- A slot that clears within a couple of seconds is working correctly — the workflow fired, retrieved the metadata, and freed the slot.
- A slot that remains occupied for more than a few seconds indicates the workflow failed — the MCX IVR did not fire, or it fired but did not successfully call the Talkative API.
- If all slots are occupied, transfers will fail. Talkative cannot park the interaction if no free slot is available. If you see this in production, increase the number of slots in the parking lot, or investigate why slots are not being cleared. A high call abandonment rate can cause slots to become stuck until the timeout clears them — the default timeout is 5 minutes, but 1 minute is recommended. If stuck slots are a recurring issue, lower the timeout in the parking lot settings.
A full parking lot causes transfer failures immediately — the caller will not be transferred and may be dropped. If you suspect this, check the lot in real time during a test call.
2. Check the Mitel Device Logs
The MCX IVR workflow Execute step logs its activity — including any HTTP requests and responses — to device port log files on the MCX server. These are found in the logs directory on the MCX server and are written per device port. Because any free IVR port in the Hunt Group may handle a given call, you will need to identify which port was assigned to the call in question and open the corresponding log file.
What to look for:
- HTTP request sent and a response received → the Execute step fired. Check the response code and body.
- No HTTP request in the logs at all → the Execute step never fired. The problem is upstream — see section 4 below.
3. Common API Failures
If the Execute step fired but returned an error, the most common causes are:
Symptom | Likely cause | Fix |
401 Unauthorised | API token is missing, incorrect, or the creating user has been deleted | Regenerate the token under a shared group account and update the Authorization header in the Execute step |
404 Not Found | Either nothing is parked at that slot, or the endpoint URL is wrong | See section below — check both possibilities before concluding |
Connection error / timeout | Wrong region in the URL, or network connectivity issue between MCX and Talkative | Verify the region prefix ( eu, us, au, euc) matches your Talkative instance. Confirm MCX has outbound HTTPS access to *.engage.app |
Empty response / mapping fails | Known YSE double-request issue during setup | Use the test endpoint https://mitel-mapper-test-xwknfzmz.on-forge.com/demo to complete output mapping, then revert to the correct URL |
Understanding a 404 Response
A 404 from the Talkative API can mean two different things, and it is important to check both before concluding:
- Nothing is parked at that slot. The slot number in the request did not match an active parked interaction — either the slot was already cleared, or the DNIS variable is not being substituted correctly. Check the DNIS variable value in the workflow logs.
- The endpoint URL is wrong. The
lotIdordnispath segments may be incorrect, or the region prefix may be wrong. Cross-check the URL against the parking lot ID shown in the Talkative UI (visible in the URL when editing the lot).
Verify both before making changes — a slot can legitimately be empty if the call was abandoned before the workflow fired.
4. No Network Logs — Execute Never Fired
If the device logs show no outbound HTTP request at all, the Execute component was never reached. This means the problem is upstream of the REST call — likely in the workflow routing itself.
Things to check:
- Did the call reach the Hunt Group? Check MiVB logs to confirm the speed call extension was dialled and picked up by the Hunt Group.
- Did the Hunt Group forward the call to the IVR workflow? Confirm the Hunt Group is correctly assigned to the IVR port running the workflow.
- Is the Answer component running? If the workflow is not answering the call, the Execute step will never be reached.
- Is the correct workflow assigned to the IVR port? Verify in YourSite Explorer that the port receiving calls from the Hunt Group is running the expected workflow.
- Are there enough IVR ports? If all IVR ports are in use when a parking space is dialled, the call will receive a busy tone and the workflow will never fire. Ensure you have sufficient ports allocated to the Hunt Group to handle your expected concurrent call volume.
- Does the MCX server have internet access? The Execute step makes an outbound HTTPS request to Talkative's servers. If the MCX server does not have a working internet connection, the request cannot complete. Confirm outbound connectivity from the MCX server and that
*.engage.appis not blocked by a firewall or proxy.
A useful test: dial the hunt group extension directly from a MiVB handset. If the workflow fires and you hear the expected IVR response, the workflow itself is healthy — the issue is in how calls are being routed to it. If the call drops or goes unanswered, the workflow or port assignment is the problem.