If this is a brand new alarm from the logmon probe with a new supp_key, the alarm will not exist in the NAS_ALARMS table when the alarm_enrichment probe first processes the new alarm. The alarm_enrichment probe will fail to enrich the alarm so the Custom_4 field will not be populated. The alarm is then passed on to the nas and at that point it will be added to the NAS_ALARMS table. If the logmon probe sends another alarm with the same supp_key, as long as the first alarm is not acknowledged (remains active in the NAS_ALARMS table), I would expect the alarm_enrichment probe to match on the supp_key and populate the custom_4 field. If you are executing the SQL query test after you see that the Custom_4 field is not populated, you are too late because the nas has already added the alarm to the NAS_ALARMS table.
Miller -Great news! Your solution seems to confirm my original comment that when the logmon probe creates the first alarm with a new supp_key, that alarm does not exist in the NAS_ALARM table yet so no matches for the supp_key in the new alarm are found in the NAS_ALARMS table and your query returns no results.
The alarm_enrichment probe processes the alarm (to enrich it) before sending it to the nas probe. The nas probe will then insert a copy of the alarm in the NAS_ALARMS table, but this is after the alarm_enrichment probe tried to enrich the initial alarm. If the logmon probe generates a second alarm with the same supp_key, and the initial alarm has not been acknowledged, then your original query will find a match for the supp_key in the NAS_ALARMS table and will then successfully enrich the alarm update.