ASIM: 'line to add' table for custom unifying parsers doesn't match the shipped Im_<Schema>Custom stubs (5/11 schemas; 3 produce unresolvable parameters)

[spasaintk]

Page

Manage ASIM parsers → Add a custom parser to a built-in unifying parser
(source: sentinel/normalization-manage-parsers.md, content commit 758c40dc)

Summary

The "line to add" table in this section tells users to invoke their custom parser from the Im_<Schema>Custom stub with a positional argument list. For 5 of the 11 schemas, that argument list does not match the parameter signature actually declared by the shipped stubs in Azure/Azure-Sentinel → ASIM/deploy/EmptyCustomUnifyingParsers/Im_<Schema>Custom.json (nor any deployed vim* parser signature). Following the table verbatim breaks the patched stub — in two different ways depending on the schema.

Verified divergences (docs row vs shipped stub functionParameters)

Schema	Divergence	Result of following the docs line
Authentication	Docs lists targetusername_has_any, actorusername_has_any, targetipaddr_has_any_prefix, dvcipaddr_has_any_prefix, dvchostname_has_any — none of these exist in the shipped stub (or in any vim* parser in the repo). The stub's real filter interface is username_has_any + targetappname_has_any.	Hard failure: the patched function references undeclared parameters → Failed to resolve scalar expression named 'targetusername_has_any' on every invocation. The portal's Save as function rejects the body; an ARM deployment does not validate and deploys a function that errors on every use — including from the built-in _Im_Authentication.
ProcessEvent	Docs inserts targetusername_has, which the stub does not declare (stub has only actorusername_has).	Hard failure, same resolution error.
RegistryEvent	Docs says registryvaluedata_has_any; the stub declares registrydata_has_any.	Hard failure, same resolution error.
AuditEvent	Same parameter set, different order. Docs: …, srcipaddr_has_any_prefix, eventtype_in, eventresult, actorusername_has_any, operation_has_any, …. Stub (and every vimAuditEvent* leaf): …, srcipaddr_has_any_prefix, actorusername_has_any, operation_has_any, eventtype_in, eventresult, ….	Silent failure: positional binding puts eventtype_in into the leaf's actorusername_has_any slot, eventresult ('*', string) into operation_has_any (dynamic), etc. The default invocation works, so the deployment looks healthy — but any caller passing filter parameters (e.g. performance-optimized analytic rules calling _Im_AuditEvent(actorusername_has_any=…)) gets silently wrong or empty results. No error is surfaced anywhere.
WebSession	Docs omits the stub's eventresultdetails_has_any (declared after eventresult).	Mild: that filter can never be forwarded to the custom parser; rows the caller asked to exclude are returned.

Two further issues affect all 11 rows:

1. The line never forwards disabled, so the stub's declared disabled:bool=false parameter is dead — Exclude… watchlist entries / explicit disabled=true have no effect on the custom leaf.
2. Because the table uses positional invocation, every row is fragile against any future signature change on either side.

I verified the failure modes against a Kusto engine using real vim* parsers: the Authentication/ProcessEvent/RegistryEvent shapes fail with a resolution error on every invocation, and the AuditEvent shape returns success with mis-bound filters. Notably, ASimSchemaTester/ASimDataTester cannot catch either case — they invoke the parser without filter arguments, so the mis-ordered patch produces byte-identical tester output to a correct patch, and the unresolvable-parameter patch kills the tester query itself.

Likely root cause

The current table (added in the January 2026 docs update) appears to be derived from the ASIM filtering-parameter naming convention rather than from the shipped stub signatures. The stubs themselves (added/updated in Azure/Azure-Sentinel#13494, which cites this docs page) derive from the deployed im<Schema> unifying parser signatures — so the two sources never matched. For Authentication, the docs signature has never existed in any shipped artifact.

Suggested fix

1. Regenerate the table's parameter lists from the shipped Im_<Schema>Custom.json functionParameters (the only signatures that resolve at runtime).

2. Better still, recommend named-argument invocation, which is immune to declaration order on both sides and is what the built-in unifying parsers themselves use (e.g. imAuditEvent.yaml):

   MyNewAuditEventParser(starttime=starttime, endtime=endtime, srcipaddr_has_any_prefix=srcipaddr_has_any_prefix, actorusername_has_any=actorusername_has_any, operation_has_any=operation_has_any, eventtype_in=eventtype_in, eventresult=eventresult, object_has_any=object_has_any, newvalue_has_any=newvalue_has_any, disabled=disabled)

   This also fixes the dead disabled parameter for free.

3. For Authentication specifically, the row needs the stub's real interface (username_has_any, targetappname_has_any, …) — reordering alone cannot fix it.