A court-system notable already has a CIM user field. The analyst runs a sparse HR lookup that only matches some clerks. Which lookup writing option preserves the original user on non-matches instead of wiping it?
Select an answer to reveal the explanation.
Short Explanation
OUTPUT is a bull in the china shop: miss a clerk in the HR table and it can blank the user you already had. OUTPUTNEW — or writing to a new field — leaves the notable's CIM user standing when the lookup is sparse.
Full Explanation
lookup OUTPUT overwrites the named destination fields; on a sparse court HR table that misses many clerks, unmatched rows can blank the notable's existing CIM user and erase the investigation key. OUTPUTNEW writes only when the destination field is unset, preserving the notable's user on non-matches, and writing HR attributes to distinct field names is an equally safe pattern. Sparse enrichment must never destroy the identity the analyst already has from Enterprise Security normalization. Using OUTPUT user on a sparse table is exactly the destructive pattern: misses become empty users. Overwriting user with rex from _raw after the lookup discards the CIM value the notable was built on. tstats after the lookup does not restore a field the lookup just cleared; summaries will not heal a wiped identity mid-search. Exam caveat: OUTPUT versus OUTPUTNEW is about write behavior on collision and absence—not about whether the HR table is authoritative when it does match. Operational check: run the sparse HR lookup with OUTPUTNEW on a court notable that has CIM user, confirm unmatched clerks retain user, confirm matched clerks gain HR fields, then document which pattern correlation searches must use.