Custom-fields are supposed to be created on the alarm, not on the event. So in an AO profile you can modify the custom fields but in a pre-processor it is not officially supported. The trick is that in a processor 'scope' the fields usually do not exist but they could if i.e. alarm_enrichment created them. Then the pre-processor could also modify them. The simple explanation is: they are available in the Auto Operator context.
You can set these fields at any point in the alarm life. None of the CA (UIM) Nimsoft provided probes will ever set these fields, but a custom probe may send alarms with these fields set in raw alarm upon generation. Think of them as user_tag1 and user_tag2 with customizable captions - for example, if you want to have an alarm property you'd like to call "Support Case", you could set this in the nas.cfg through setup/custom_headers/custom_1 through custom_5. Note that this is not available in the GUI.
As for the custom fields themselves, they are, simply put, new fields that are included in the alarms. These can then be set in a preprocessing script, ie. programmatically - here's an outline on how to do it:
event.custom_1 = "A custom message"
event.custom_2 = "custom message number 2" -- and so on for _3 through _5
"Rewrite alerts generated by some remote probes to appear as if they are coming from the nodes being monitored."
--Rewrite major alerts to include a runbook number in their message
event.hostname = "hostname" event.message = "some other message"
See attached nas technical brief. On page 23 you can see which alarm fields are available for use/manipulation in Auto Operator-context, and on page 24 for pre-processing.