Phishing Playbook Not Firing and Duplicate Closure Leaving Stale Parents
You inherit an XSOAR tenant with 14 incident types and 3,000 open incidents. An email gateway integration creates incidents of type Phishing with a custom field phish_score intended to hold 0 to 100. The playbook should auto-close obvious false positives below 20 and escalate the rest for analyst review. Three complaints arrive: about 30 percent of phishing incidents never run any playbook; false positives stay open for days because the auto-close branch never executes; and when an analyst closes a child as a duplicate, the linked parent stays open showing stale child data. Last quarter a set of pre-processing rules was added and the classifier was retrained. The gateway sometimes sends phish_score as 85.0 and sometimes as the word high.
1. Thirty percent of phishing incidents never run a playbook. Walk through the diagnostic order and identify the most likely culprit.
Read the worked answer
Work from the earliest stage of the pipeline forward, because each stage can silently pre-empt the next.
First, pre-processing rules. They execute before classification and can change the incident type or drop the incident entirely. A rule added last quarter that routes high-score mail to a new type - say Phishing - High - would explain exactly a partial miss: those incidents exist, look like phishing to an analyst, and have no playbook because that type has none configured.
Second, the classifier. If the retrained model now maps some gateway incidents to a different type, the phishing playbook never triggers. Check DBotCreatedBy and the assigned type on a sample of non-running incidents.
Third, the playbook trigger. A trigger can be constrained by source, severity, or a custom-field condition. If the trigger filters on phish_score and that field is text containing high, the condition fails and the playbook is skipped. Also confirm the playbook is actually designated as the type's default or set to run on all incidents of that type - a playbook can exist, be enabled, and still not be wired to the type.
Most likely culprit given the timeline: a pre-processing rule that re-types high-score incidents into a type with no playbook. Confirm by pulling ten affected incidents and comparing their type against the trigger definitions before changing anything.
2. The auto-close branch never fires even when the score is clearly low. Explain the root cause and how you would fix it without losing historical data.
Read the worked answer
The condition compares a text field numerically, and the data is not consistently numeric. A playbook condition on phish_score < 20 where the field is a string will either compare lexicographically (so 85.0 sorts below 20 because 8 precedes 2 in character order) or fail outright on the value high. Either way the branch resolves unpredictably, which matches "never fires."
Fix in three layers rather than patching the condition alone.
Normalize at ingestion: add a pre-processing or playbook step that maps categorical values to numbers - high to 90, medium to 50, low to 10 - and writes the numeric result to a dedicated numeric field. Do not overwrite the raw field; keep it for audit.
Change the field type: make the comparison field a number type in the incident field definition so the UI, API, and playbook conditions all agree. Text-to-number comparison in conditions is where this class of bug lives.
Harden the branch: guard the condition with an existence and numeric check so a missing or unparseable score routes to manual review instead of silently falling through to the escalation path or to nothing.
For historical incidents, run a one-time maintenance playbook that computes the normalized value from the raw field and writes it, then re-evaluate. Do not mass-change incident types. Validate on 20 incidents across all observed formats before running at scale, and add a sample-format test to the playbook so a future gateway change is caught before analysts see it.
3. When a child incident is closed as a duplicate, the linked parent stays open with stale data. What is the correct handling?
Read the worked answer
Linking two incidents is a relationship, not an inheritance. Closing the child changes only the child; nothing propagates to the parent, and any summary of child data shown on the parent was captured at the time it was written or is rendered from the child's current state without updating parent fields. So the stale parent is expected behavior, not a bug in linking - the workflow is incomplete.
The fix is an explicit close-handling step. When an incident is closed with the duplicate reason, the playbook should: identify the parent from the linked incidents relationship, write the summary fields the parent layout displays (duplicate count, last duplicate timestamp, aggregate score) onto the parent with a field update, and either close the parent if the parent's own criteria are satisfied or post a war room note to the parent so the owner sees the child outcome. Do this on incident close, triggered by the close event or as the final task of the playbook, not on a schedule.
Two design cautions. First, avoid closing parents automatically just because a child was a duplicate - the parent may aggregate multiple distinct children, and auto-close can destroy an active investigation. Gate it on an explicit parent criterion. Second, guard against loops: if the parent is later merged into another incident, the close handler must not re-trigger recursively. Use a flag field set once, and test the chain with a two-level and three-level link before enabling in production.