An Automic CALL.ALARM notification bug that nobody could reproduce, evidence sitting in plain sight inside a screenshot, and a single overlooked detail that flipped the whole investigation. This is a real Automic Automation V24 support case from the Tricise Support team — and it is a near-perfect example of why first-hand experience still beats every troubleshooting tool we own.
For a related case study on how environmental dependencies can break the AWI, see our companion article on Automic AWI logon failures and Tomcat configuration. This case study takes a different angle: when the bug is real, the customer is right, and the engineer simply cannot reproduce it.
The situation: a notification object that wouldn’t behave
The customer raised a case shortly after upgrading their system to Automic Automation V24.4.4. A specific Notification object — CALL.ALARM — had stopped working the way it always had.
In earlier versions, the AWI displayed the notification with two clear buttons: accept and reject. After the upgrade, those buttons were gone. The user could see the message, click OK, and the dialog would close. One second later it would re-open. Then close. Then re-open. The notification was inescapable from inside the AWI — the only workaround was to terminate the Notification object manually from Process Monitoring.
For an operations team that relies on CALL.ALARM notifications to validate critical alerts, this is not a cosmetic issue. It blocks an entire workflow class.
Diagnostics: when reproduction fails
The first instinct in any support case is to reproduce. The Tricise engineer set up a simple Notification object of type CALL.ALARM, built a task to trigger it, and ran it on the same Automic Automation V24.4.4 version the customer was on.
The bug did not appear. Buttons displayed correctly. Accept and reject both worked. Same product version, same object type, same expected behaviour.
The next step was to suspect customer-specific configuration. Variables, dependencies, client settings — something must be different. The customer was exceptionally cooperative, packaged a reproducible scenario from their environment, and shipped the objects across so the engineer could load them into a clean test system.
Still nothing. The objects ran. The buttons appeared. The bug refused to show up.
At this point the case sits in an awkward place that anyone who has worked in product support knows well: there is obvious evidence of a real defect — screenshots, customer process monitoring data, repeatable behaviour on their side — and there is a complete inability to reproduce it on the support side. Logs and traces don’t usually help with a display issue. And nothing about the customer’s setup was unusual enough to explain the gap.
The detail in the screenshot
The breakthrough on this Automic CALL.ALARM notification bug came from looking at the customer’s screenshot more carefully — not at the missing buttons, but at the AWI chrome around them.
The customer was running the AWI in German. Every reproduction attempt on the Tricise side had been done on the English AWI. That was the only variable that hadn’t been controlled for.
The engineer switched the test AWI to German language, triggered the same simple CALL.ALARM Notification object, and the buttons disappeared. The dialog started looping. Identical behaviour to the customer’s environment. Later tests confirmed the same defect appeared on the French AWI as well.
The bug was localised to specific AWI language packs — a class of issue that almost never shows up in the symptom description, because customers don’t think of “I use the German interface” as part of the technical context. They mention it about as often as they mention which colour their monitor is.
The fix and the workaround
With reproduction in hand, the case was escalated to Broadcom as a confirmed bug. The vendor accepted it and committed to a fix in service pack 24.4.5, which restores correct notification button rendering in the German and French AWI.
For the customer, the immediate workaround was simple: switch the AWI session to English until the patched service pack is installed. Not elegant, but it unblocks the team within minutes, and a clean fix is already on the roadmap.
Broadcom’s official Notification (CALL) documentation covers the intended button behaviour of ALARM templates in detail — useful background for anyone validating the workaround.
What this Automic CALL.ALARM notification bug actually teaches
Three things, all of which generalise far beyond this specific case:
- Reproduction failure is data. When a customer can reproduce something and support cannot, the difference between the two environments contains the answer. Not “the customer must be doing something wrong” — almost never. The discipline is to find the variable that nobody is consciously varying.
- Screenshots carry context the case description doesn’t. The German UI labels were sitting in the screenshot from day one. The fix was visible the moment someone looked at the picture as a picture, not as evidence for a hypothesis already in mind.
- Internal communication multiplies the value of every solved case. Within days of this CALL.ALARM resolution, several other customers reported the same symptom. Because the team had discussed the case in regular internal meetings, those follow-up tickets were closed in minutes rather than days — and customers got the workaround and the fix-plan information immediately.
Frequently asked questions about this Automic CALL.ALARM notification bug
After publishing the case internally, the Tricise Support team kept getting the same follow-up questions from customers running into similar symptoms. The answers below cover what comes up most often, including the situations where the simple “switch to English” workaround is not an option.
Which Automic Automation versions are affected?
The defect was first reported on Automic Automation V24.4.4 and confirmed by Broadcom as a bug in the same version. Earlier service-pack releases of the V24.4.x line did not show the problem in our reproduction tests on German and French AWI. The fix ships in service pack V24.4.5. Customers still on V24.4.3 or earlier are not exposed; customers on V24.4.4 are exposed until they install V24.4.5. The V24.5.x line was not part of this case and should be tested separately if you upgrade from V24.4 to V24.5 in one step.
Which AWI languages trigger the missing buttons?
German and French were the two languages we confirmed in the support case. English does not trigger it. We did not test every supported AWI language, but the pattern — a localisation-specific rendering defect — is consistent with how the AWI builds language packs for the V24.4 line. If you run the AWI in Italian, Spanish, or any other non-English locale, treat this as a known risk on V24.4.4 and verify CALL.ALARM Notification behaviour on a non-production client before relying on it in production workflows.
What if we cannot upgrade to V24.4.5 right away?
The interim workaround is to have AWI users switch their personal AWI session to English. The setting is per-user, so a single operations engineer can toggle to English without affecting colleagues. The rest of the platform — Automation Engine, agents, workflow engine — is unaffected and continues to run in its existing configuration. If a session switch is not acceptable, the second workaround is to terminate active CALL.ALARM Notification objects from Process Monitoring rather than from the dialog, which is operationally cumbersome but functionally complete.
Does the defect affect other CALL Notification object types?
In our reproduction work we did not see the same button-rendering issue on CALL.MAIL or on the SAMPLE Notification templates. The defect is specific to the request-and-response interaction of CALL.ALARM, which renders a dialog with explicit accept/reject buttons in addition to the OK button. CALL.MAIL does not present that interaction pattern, so there are no buttons to disappear in the first place. We still recommend testing every Notification-based workflow on the same AWI language your production users actually use, especially after any V24.4.x upgrade.
How can we prevent this kind of bug from hitting production again?
The structural fix is to include a non-English AWI in your pre-production validation runs whenever you upgrade Automic Automation. Most enterprise teams test only the English AWI because that is what their engineers use day-to-day, which means localisation defects reach production before anyone notices. Adding a single test client with the AWI set to the language your operators use takes one engineer one hour to set up and catches an entire class of defects this case is just one example of.
What’s the fastest way to get a tricky Automic case to Tricise Support?
For cases where reproduction matters — and most do — the package that helps us most contains four things: the Automic Automation version (including service-pack level), screenshots of the failing behaviour with the AWI chrome visible (language indicators, user menu, theme), an exported Notification or workflow object that demonstrates the issue, and a one-paragraph description of what the customer expected versus what happened. The screenshot with the AWI chrome is the detail that this case turned on, and it almost never appears in support tickets unless the customer is specifically asked for it.
What about hybrid teams with both English and German operators?
This is the most operationally painful scenario, and several customers reported it after we published the internal case write-up. Until V24.4.5 is installed, the practical recommendation is to standardise the AWI language to English for the team members who actively process CALL.ALARM Notifications, and let other team members use their preferred language for read-only or non-Notification work. AWI language is a per-user setting, so the split is feasible without infrastructure changes. Once V24.4.5 ships, the split is no longer necessary and teams can return to their preferred languages.
Why customers choose Tricise for Automic support
This is the kind of case that does not get solved by a knowledge-base search. It needs a support engineer who is patient enough to ask “what’s different about your setup that I’m not seeing,” disciplined enough to keep reading the evidence after the first reproduction fails, and connected enough to a team that turns one resolution into a fix for everyone affected.
As Automic Automation specialists at Tricise, we handle more than 1,600 cases like this one every year. Each case feeds back into our internal exchanges and into our Smart Automation portfolio, so that the next customer to hit a similar issue gets a faster answer.
For teams planning a V24 upgrade or already running on V24.4.x, our Tricise University training catalogue covers the operational realities of post-upgrade support, including how to package a reproducible case quickly when the symptoms are strange.
The bottom line
An Automic CALL.ALARM notification bug that survives both customer-side and support-side reproduction attempts is not impossible to solve — it just demands that the engineer keep looking at the evidence after the obvious paths have been exhausted. In this case, the answer was sitting in a screenshot the entire time. The lesson is older than any version of Automic: the variable nobody is varying is usually the one that matters.
Got a stubborn Automic support case?
If you’re running into Automic Automation behaviour that “shouldn’t be happening” and your in-house team has hit a wall, the Tricise Support team has likely seen something similar. We’ll review the case together, identify the missing variable, and get you to a workable answer.
