Hey Ravish - Yes, that is an older (prior to Kingston) baseline SIR inbound action that is still kicking around. I believe the condition is mocked up to provide an example / leading point for configuring this (or cloning and adjusting this).
You may want to check out some of the newer (introduced in Kingston+) SIR Email Processing capabilities introduced into the SIR app, since that specific inbound action was around. These are meant to be configured and tuned for your use-cases, such that you do not need to touch `Inbound Email Actions`.
In the app nav menu, check out Security Operations > Email Processing ...
You will see several modules here.
You can configure inbound emails for scenarios such:
- Security tools to send emails to SN and create SIR records
- Users to report phishing / suspicious emails by sending them to SN as an attachment (this feature is pretty neat, it parses artifacts from the msg attachment to create Observables that can be used for Threat Lookups and other slicing and dicing)
- Ad-hoc users to send emails to SN to create SIR records
Using these capabilities offers duplication / aggregation capabilities, parsing capabilities - in bit more 'configuration friendly way', than the platform Inbound Action. Also, users with the <sn_si.admin> role, can modify these configs; whereas Inbound Actions at the platform level are not necessarily accessible to users only having the <sn_si.admin> role.
The [Email Parsing] Module, essentially allows you to create your own configurations to control what to do when an email is received (based on criteria such as subj, recipients, body text, etc) - and you can use this to parse data / set values on the target SIR records that are created.
If you are curious, you can check out the Inbound Email Action called "Record SecOps Email Events". This acts a front, to the Email Processing capabilities, and leverages the configurations you make within the Email Processing configs (i.e. SIR Email Parsing Rules). There are two Inbound Email Actions called "User Reported Phishing", that acts as a front, to the User Reported Phishing configurations you make (sender, subject, body, etc) (one covers new msgs and one covers fwd msgs).
Using the [Email Parsing] or [User Reported Phishing] here allows you configure what you need, without having to touch the `Inbound email actions`, and with only having the <sn_si.admin> role.
The one caveat to not needing to touch these Inbound Email Actions, may occur when custom Inbound Actions were introduced onto the SN Platform with very broad conditions and a low Order number that it is ran with; sometimes the Order number may need to be adjusted on these "SecOps" Inbound Email Actions (this may involve working with someone who has the platform <admin> role)...
Reference:
https://docs.servicenow.com/bundle/madrid-security-management/page/product/security-operations-commo...
https://docs.servicenow.com/bundle/madrid-security-management/page/product/security-incident-respons...
