Alerts are not mapped and modeled by default. In order to do so,
navigate to the mapping and modeling section (click the gear icon).
For this use case we will map our case using the predefined family – MailRelayOrTAP for email monitoring events.
Mapping and Modeling can be in one of the three stages of hierarchy, for this example:
Source – This is the Source name field as we filled earlier. This is the Source that digested the data and created an alert in Google Security Operations platform. For this example the Source name is "Email Connector".
In this stage we will map only the time, since these fields are the same in each stage.
If you map at this stage then the following stages (Product – "Mail" and the Event -"Suspicious email"), will inherit the same modeling mapping we performed.
Product – The product is "Mail", which is the product that digests the data that came by the source "Mail". For example a connector can digest data from many sources. If mapping and modeling is configured at this stage then the following stage ("Suspicious email") will inherit the same modeling mapping we performed.
Event – This is the event_name as we filled in earlier, for this example the event name is "Suspicious email". The event in
this case is the email message itself.
We will map the relevant fields by assigning each field to the appropriate field in the code. In this mapping section we will map all the fields under the "Product" level.
Rule Level
Target Field
Extracted Field
Transformation Function
The field value
Product
DestinationUserName
event["destinationUserName"]
TO_STRING
The email address of the person who received the email.
Product
SourceUserName
event["sourceUserName"]
EXTRACT_BY_REGEX Regex format:
[\w\.-]+@[\w\.-]+
The email address of the person who sent the email
Product
EmailSubject
event["subject"]
TO_STRING
The email subject
Product
DestinationURL
event["found_url"]
TO_STRING
The URLs found in the email body
Product
StartTime
event["startTime"]
FROM_UNIXTIME_STRING_OR_LONG
The time the email was received
Product
EndTime
event["EndTime"]
FROM_UNIXTIME_STRING_OR_LONG
The time the email was received
After Mapping this case we will simulate the alert to see the mapping
result. From the Overview Tab in the Alert, click more_vert on the right side of the screen and select "Ingest alert as test case".
Then, a new simulated alert will appear as a new case in the case queue. All
the simulated cases are tagged with the purple "Test" mark on the left of the
case name.
After mapping the case you can see each email
message argument that we mapped by clicking
more_vert
on the right of the screen and then clicking Show Result.
If you would like to see a visual view of the entities involved in
the event and the relations between them, click on the Explore button.
Now that you have finished the mapping and
modelling step you can now start ingesting alerts into your platform
automatically that will inherit the mapping and modelling you have performed. To
do so, navigate back to the Connectors screen, enable the toggle and click
save.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-29 UTC."],[[["\u003cp\u003eMapping and modeling alerts in Google SecOps is not enabled by default and must be configured in the settings via the gear icon.\u003c/p\u003e\n"],["\u003cp\u003eMapping and modeling can be performed at three hierarchical levels: Source, Product, or Event, with subsequent levels inheriting the mapping of the levels above them.\u003c/p\u003e\n"],["\u003cp\u003eIn this example, the mapping process is demonstrated using a "MailRelayOrTAP" email monitoring case, mapping fields at the "Product" level with corresponding data extraction functions and field values.\u003c/p\u003e\n"],["\u003cp\u003eAfter mapping, the alert can be simulated as a test case, allowing users to review the mapping results and also offering a visual exploration of entities and their relationships.\u003c/p\u003e\n"],["\u003cp\u003eOnce mapping and modeling is completed, new alerts that come in the system will inherit the mapping configurations, and can be done so by toggling the setting in the connector screen.\u003c/p\u003e\n"]]],[],null,["# Mapping & modeling\n\nMapping \\& modeling\n===================\n\nSupported in: \nGoogle secops [SOAR](/chronicle/docs/secops/google-secops-soar-toc) \nAlerts are not mapped and modeled by default. In order to do so,\nnavigate to the mapping and modeling section (click the gear icon).\n\n\u003cbr /\u003e\n\n[](/static/chronicle/images/soar/mappingmodeling1.png)\n\n\u003cbr /\u003e\n\n1. For this use case we will map our case using the predefined family -- **MailRelayOrTAP** for email monitoring events. \n [](/static/chronicle/images/soar/mappingmodeling2.png)\n2. Mapping and Modeling can be in one of the three stages of hierarchy, for this example:\n - **Source** -- This is the Source name field as we filled earlier. This is the Source that digested the data and created an alert in Google Security Operations platform. For this example the Source name is \"Email Connector\". \n In this stage we will map only the time, since these fields are the same in each stage. \n If you map at this stage then the following stages (Product -- \"Mail\" and the Event -\"Suspicious email\"), will inherit the same modeling mapping we performed.\n - **Product** -- The product is \"Mail\", which is the product that digests the data that came by the source \"Mail\". For example a connector can digest data from many sources. If mapping and modeling is configured at this stage then the following stage (\"Suspicious email\") will inherit the same modeling mapping we performed.\n - **Event** -- This is the `event_name` as we filled in earlier, for this example the event name is \"Suspicious email\". The event in this case is the email message itself.\n3. We will map the relevant fields by assigning each field to the appropriate field in the code. In this mapping section we will map all the fields under the \"Product\" level.\n\n4. After Mapping this case we will simulate the alert to see the mapping result. From the Overview Tab in the Alert, click more_vert on the right side of the screen and select \"Ingest alert as test case\".\n\n \u003cbr /\u003e\n\n [](/static/chronicle/images/soar/mappingmodeling3.png)\n\n \u003cbr /\u003e\n\n Then, a new simulated alert will appear as a new case in the case queue. All\n the simulated cases are tagged with the purple \"Test\" mark on the left of the\n case name.\n\n \u003cbr /\u003e\n\n [](/static/chronicle/images/soar/mappingmodeling4.png)\n\n \u003cbr /\u003e\n\n After mapping the case you can see each email\n message argument that we mapped by clicking more_vert on the right of the screen and then clicking Show Result.\n\n \u003cbr /\u003e\n\n [](/static/chronicle/images/soar/mappingmodeling5.png)\n\n \u003cbr /\u003e\n\n If you would like to see a visual view of the entities involved in\n the event and the relations between them, click on the Explore button.\n\n \u003cbr /\u003e\n\n [](/static/chronicle/images/soar/mappingmodeling6.png)\n\n \u003cbr /\u003e\n\n Now that you have finished the mapping and\n modelling step you can now start ingesting alerts into your platform\n automatically that will inherit the mapping and modelling you have performed. To\n do so, navigate back to the Connectors screen, enable the toggle and click\n save.\n\n**Need more help?** [Get answers from Community members and Google SecOps professionals.](https://security.googlecloudcommunity.com/google-security-operations-2)"]]