How to suppress "Alerts were ingested into Environment X which does not exist" notifications for unmapped namespaces

Hi, from the behavior you described, it looks like the connector still receives the original namespace value, for example IFES, as the environment value before it falls back to Default. That is probably why the system still generates the “Environment does not exist” notification. Instead of using the raw namespace field directly as the Environment Field Name, I would suggest normalizing this value before it reaches the connector. For example, use a derived field that contains only valid Google SecOps environment names:

IFAP / UNIFAP → SOC-AP
IFPI → SOC-PI
all other namespaces → Default or empty value

Then configure the connector to use this normalized field as the environment field. This should avoid creating one environment per namespace and should also prevent unknown namespace values from being treated as missing environments.

This was extremely helpful — your diagnosis was exactly right. The connector was reading the raw namespace value (e.g., IFES) as the environment before falling back to Default, which is what triggered the "environment does not exist" notification.

We implemented the normalization approach you suggested. Since we run one BindPlane processor per institution, we added an ingestion label on each mapped institution instead of relying on the raw namespace field:

• IFAP / UNIFAP → soar_environment = soc-siem-ap
• IFPI → soar_environment = soc-siem-pi
• all other institutions (no SOC yet) → no label

We then pointed the connector's Environment Field Name to this normalized ingestion label instead of the raw namespace. We confirmed the label arrives correctly in the SIEM (metadata.ingestion_labels.key = "soar_environment" with the expected values), and routing of new cases to the correct environments is working.

This avoids creating one environment per namespace and prevents unmapped institutions from being treated as missing environments. Thanks again for pointing us to normalizing the value upstream — it scales much better for our multi-SOC model.

I recommend double checking to confirm cases where the event_metadata_baseLabels_namespaces_1 field is present but does not match your regex are actually showing up in default environment. 

In my testing with the Chronicle Alerts connector the ‘Environment Regex Pattern’ works more as a subselect on the value of the environment field name instead of as a filter for the Environment Field Name function, so routing behavior is this:

• If a detection DOES NOT have the field specified in ‘Environment Field Name’ : use Environment dropdown at top of connector.
• If a detection DOES have the environment field name, and the value of the field matches the ‘Environment Regex Pattern’: Use the value extracted from Environment Field Name by the regex
• If a detection DOES have the environment field name, and the value of the field DOES NOT MATCH the regex pattern: Use the value from Environment Field Value 

What you can do to ensure the IFES cases are worked from the Default Environment and prevent the error notifications for missing environments is to add ‘IFES’ (and any other missing environment) as an alias on the Default Environment, you can set this under settings → soar settings → organization → environments.