LinkedIn
Twitter
Author: Yuriy Landovskyy
As you all know, the structure of Cases and Alerts can be pretty limiting, which was hurting triaging and reporting. Today we officially announce a Public Preview for Custom Fields.
Custom Fields - new Case Management feature that allow you to add new configurable fields to the Case & Alert objects. Custom fields are available for both UI and automation workflows via playbooks.
Overview
Custom Fields are available under Setting -> SOAR Settings -> Case Data -> Custom Fields.
To add a custom field, you need to press on the "+" button, which will open this modal:
As part of Public Preview, the following input types are supported:
- Free Text (up to 1024 characters)
- Single Select (20 options)
- Multi Select (20 options)
- Radio Button (2 options)
- Calendar
Custom fields are available for both Case & Alert scopes. When you are selecting "All" during the creation of custom fields, you are going to create a custom field with the provided name in Case and in Alert. They are independent from each other. The moment custom field is created, the field is immediately available within all Cases/Alerts.
After the custom field is created, you currently can't edit the scope and the type. If you've made a typo, you need to delete the custom field and recreate it.
If the custom field is deleted, then Cases/Alerts that had the value already set for that custom field, will still be able to access it. Newly generated Case/Alerts will not have that field added to them.
How to interact with Custom Fields via UI?
In order to work with custom fields via UI, you need to add a new special widget to the View called "Custom Fields Form". As part of Public Preview, this widget is only available for Default Case View and Default Alert View. Playbook views support will be added in H1.
You can add as many "Custom Field Form" widgets as you deem necessary. As any other widget, you can change the width for it and also apply conditions, when the widget should be rendered. But remember that the form widget is just a UI component for custom fields. Even if you don't have the form added, custom fields will still be available as part of the Case/Alert.
To add custom fields to the form, you need to press on the "Manage Custom Fields" button. Each form can contain up to 50 custom fields. You can change the order of custom fields and also set, which custom fields are mandatory.
Note: Mandatory in this context just means that when user will interact with the form widget, he needs to provide a value to all mandatory fields. These fields do not block case closure operation. You will also still be able to set custom fields from playbooks individually.
When the custom field is deleted in the Settings page, this custom field is removed from all widgets.
After you've finished your setup, the custom fields will be available inside Case Management.
At any given point of time, this widget will point you to the value that is stored for in the custom field.
To edit the data from the UI, you need to press on the Edit button, which will open a sidebar, where you can interact with all fields on the form widget.
Mandatory fields are labeled with a red asterisk "*".
How to interact with Custom Fields via Playbooks?
All of the custom fields are available in the Placeholder Picker under "Custom Fields" section. Placeholders follow this structure:
- [AlertCustom.{name}] for Alert Custom Fields
- [CaseCustom.{name}] for Case Custom Fields
Examples:
[AlertCustom.Business Impact]
[CaseCustom.Department]
There are 2 actions under Siemplify integration (currently planned for 26th of February) that will work with custom fields:
- Set Custom Fields
- Wait For Custom Fields
Set Custom Fields
This action allows you to set values for multiple custom fields at a time. You can interact with both Alert and Case custom fields depending on the Scope parameter configuration.
Custom Fields Data expects a JSON object in the following format:
{
"Custom Field Name 1": "Custom Field Value 1",
"Custom Field Name 2": "Custom Field Value 2"
}
For example, if I want to update a Custom Field with name "Business Impact" to value "Low", then you will provide the following:
{
"Business Impact": "Low"
}
If you are interacting with "Multi Select" field, then it's expected that you will provide a list of strings as input. For example, if you have a custom field called "Department" and you want to set it to "Dep A" and "Dep B", then your input will look like this:
{
"Department": ["Dep A", "Dep B"]
}
Calendar input types expect epoch time (up to milliseconds) in UTC timezone to be provided. For example, if you have "Due Date" custom field parameter, then it's expected that you will provide the following input
{
"Due Date": "1740149808000"
}
If you want to reset the value for custom field, provide the following payload:
{
"Due Date": ""
}
Sometimes your use case may be to append some data instead of overwriting. For that, we have parameter "Append Values".
For example, you have a "Free Text" Custom Field field called "Justification". You build this justification throughout the whole playbook and currently this field has value "This is first justification.". Instead of managing the state of full justification string, you can just enable "Append Values" and when you will provide "This is second justification." in payload like this:
{
"Justification": "This is second justification."
}
It will result into:
Justification: "This is first justification.This is second justification."
Similar principal is applied to "Multi Select" fields. Let's assume that we want to add additional value to the "Department" Custom field - "Dep C". If you have the payload set like this with "Append Values" enabled:
{
"Department": ["Dep C"]
}
It will result into:
Department: ["Dep A", "Dep B", "Dep C"]
To ensure stable & predictable outcomes, when providing input adhere to this map:
- Free Text - String
- Single Select - String
- Multi Select - List of Strings
- Calendar - String
- Radio Button - String
Wait For Custom Fields
This action is designed to stop the playbook from progressing until custom fields will have either any value or specific value.
The input is similar to "Set Custom Fields" action, as it also expects a JSON object to be provided. Let's look into several examples.
If you provide:
{
"Business Impact": ""
}
Action will wait until "Business Impact" custom field has ANY value.
If you provide:
{
"Business Impact": "Low"
}
Action will wait until "Business Impact" has value "Low".
If you provide:
{
"Business Impact": "Low",
"Department":""
}
Action will wait until "Business Impact" is "Low" AND "Department" has ANY value.
With "Multi Select" fields there is a special logic. Here are some examples.
If you provide for "Multi Select" field:
{
"Department": ""
}
Action will wait for ANY value same as other input types.
If you provide for "Multi Select" field:
{
"Department": "Dep A"
}
Action will wait until ONE of the SELECTED options will be "Dep A". So, if your input filed has ["Dep A", "Dep B", "Dep C"] it will match it.
If you provide for "Multi Select" field:
{
"Department": ["Dep A"]
}
Action will wait until "Department" Custom Field will be EXACTLY "[Dep A]".
Note: Input [""] or ["Dep A", ""] is Invalid. All matching for any input type is done in CASE SENSITIVE way.
Use this action, when you have semi-automated workflow, where you can close the case via playbook as long as all of the necessary custom fields have a value.
Audit
All information about custom field changes are available both in the Settings (SOAR Settings -> Advanced -> Audit) and Case Wall.
RBAC
Currently custom fields support basic RBAC. In order to interact with custom fields, you need "Allow Case Management actions" under "Cases" section. Currently, you can't restrict interactions with specific custom fields.
Context Values Vs Custom Fields
Some of you might be aware that we have also a concept of "Context Values". Originally, context values were designed to share information between multiple backend processes, but eventually, everyone saw that they can be also used to append custom metadata to Cases/Alerts.
Overall, if you are using Context Values to extend Cases/Alerts, then it's recommended to switch to Custom Fields, because Custom Fields will be eventually supported in Search, Reports, Dashboards, but Context Values won't be.
Context Values are NOT going to be deprecated with the release of Custom Fields. Moreover, even today there is still a use case for them. For example, if you have some non-standartised data that you want to share between 2 playbooks -> Context Values are still the way to go.
Linked Custom Fields
Sometimes you might need to solve a use case, where depending on the value of custom fields, you want to show additional fields to fill out. Currently, you can't build fields that are linked/dependant on each other, but this use case, can still be indirectly solved with conditions in widget.
For example, if you are in situation, where you have a custom field "Alert Type" and if this field is set to "Phishing", then you want to show additional fields in the UI: Affected User, Email Subject.
To make this happen, you need to create a new widget called "Phishing Form", which will contain "Affected User" and "Email Subject" custom fields. And as Conditions, you will provide "[AlertCustom.Alert Type] () Phishing". Now, the "Phishing Form" will only be shown to the user, if "Alert Type" is set to "Phishing."
Conclusion
As this feature is very impactful, we would love to hear your feedback! If you have any suggestions/blockers that you want to highlight, feel free to do it in the comments. Comments with the highest likes will directly impact our planning as there is a lot to still enhance for this feature.