Allow users to define custom fields on Kibana cases

[shanisagiv1]

Feature Description: We'd like to support new fields that the user can define and manage on cases for better case classification and case enrichment.

Basic Use cases and Requirements:

• The user should be able to define up to 5 new custom fields. (from case settings)

• For each field, the user should determine the following:

  • Label (name)

  • Type (text, areatext, number, URL, Json)

  • Multi-value/ Single value

  • Key(unique) - yes/not. means that you cant have 2 fields with the same key. Once the first case is defined with a new "key" field . no other cases can get the same value. this is used for unique IDs

  • Mandatory/ Optional

• The fields should be presented in the case view, and updates in those fields should be logged in the Activity feed.

• The new fields should be added to the case table as columns and filters

• The fields can be leveraged for connector syncs, the user will have to map between the case fields and 3rd party fields (out of scope for this request)

• When deleting an existing custom field, the field will be removed and the values will be lost

• In the future, we'll consider allowing more than just 5.

• Anything should be supported via our APIs as well

Advanced Use cases and Requirements (2nd phase):

• show similar cases based on custom fields:

  • Users will be able to mark another checkbox when creating custom fields called "Enable Case similarities based on this field"
  • In the case view, a new section will be available called "Similar cases", this shows a list of cases and links to those. Case will be considered as similar when the value in the defined custom fields equals 2 or more cases. e.g: a new field called vulnerability is defined for similarity purposes. once 2 cases get the same value "CVE-X", those will be considered as similar cases.

• allow users to auto-populate values to custom fields using defined automation:

  • Users are able to define "automation" on custom tags based on several options:
    • Unique Values : that are aggregated from the assigned alerts. The user will have to select the alert attribute to aggregate (aggregate unique alert.hostname to case tag)
    • Fixed value: populated pre-defiend values based on condition. (e.g if alert.reason is X, value is Y)
  • Any time a new alert is assigned/re-assigned to the case, the custom tags are re-calculated
  • Activity log should be written for each update.

• We should have the following metrics in Telemetry:

  • How many custom fields do customers use
  • what types of fields are used

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[elasticmachine]

Pinging @elastic/response-ops-cases (Feature:Cases)

[mdefazio]

@shanisagiv1 A few questions / clarifications on these reqs:

---

The user should be able to define up to 3 new custom fields. (from case settings)

Is there a reason 3 is a max?

---

The new fields should be added to the case table as columns and filters

Some more clarification here or more thinking might be needed. We currently do not have a method for hiding/showing columns on the Cases table. And I don't think we will want to add columns for every custom field a user adds.
--> How would we filter or group on these fields? --> How do we handle cases that don't share the same field, but the table is grouped or filtered according to that field --> How would I include a column on the table if I wanted to

---

The fields can be leveraged for connector syncs, the user will have to map between the case fields and 3rd party fields (out of scope for this request)

Does this mean including a variable within the action that can reference these fields? Should these custom fields be presented or prioritized differently than other variables?

---

When deleting an existing custom field, the field will be removed and the values will be lost

Sounds similar to how we handle tags in cases at the moment. Should there be more guardrails on these so a user doesn't inadvertently delete one when deleting a case? I would think so, since the setup of these is more involved than creating a simple tag.

---

In the future, we'll consider allowing more than just 3.

Again, is there a reason for 3 only at the beginning? Is this referencing the need to add these to the table?

---

We should have metrics to measure... what types of fields are used

What do we mean by 'types of fields used'? Multi-select or single value vs boolean vs string? Or something else?

---

Additional questions:

1. Should these instead be defined in a 'Settings' or 'Admin' section for cases? Are there different personas that would define these fields, and then others that would consume them when creating a case?
2. Should I be able to reorder the custom fields (and current fields) on the form? What about hiding or showing current fields in favor of these custom ones? What about the order of the right sidebar once the case is created?

---

Let me know if these make sense. (And whether we want to move these to a doc)

[cnasikas]

Some thoughts from me on your questions 🙂.

The user should be able to define up to 3 new custom fields. (from case settings)

The main reason is field explosion on the UI (cases table, cases view page, cases configuration). If there is a UX way to avoid it then we can increase the number of custom fields. We should put a limit on the backend, but it can be higher (for example, 10).

And I don't think we will want to add columns for every custom field a user adds.

I agree with @mdefazio on this. We can support it in the feature (adding/removing columns from the table) but for the first iteration maybe we do not show them.

How would we filter or group on these fields?

We do not support grouping at the moment. The filtering will work the same as our current filters work. For example severity: High AND status: open AND (tag: one or tag: two). For the custom fields, I imagine the same. Depending on the type of field the filtering can be slightly different. If it is a multi-select field it can be (customField: customValue1 or customField: customValue2) AND status: open.

How do we handle cases that don't share the same field, but the table is grouped or filtered according to that field

IMO, we should filter out the cases that the field does not exist. Same we do with the assignees.

How would I include a column on the table if I wanted to Good question. I would say in the future we can let the users add/remove columns as we do in the alerts table.

Sounds similar to how we handle tags in cases at the moment. Should there be more guardrails on these so a user doesn't inadvertently delete one when deleting a case? I would think so, since the setup of these is more involved than creating a simple tag.

To my understanding, the user will go to the configuration page to define the available custom fields (key, label, etc). Then these fields will be available in the cases table, case creation form, and the case view page. I think what @shanisagiv1 means here is that if someone goes to the configuration page and deletes the definition of the fields. If a case is deleted then all the new values created only in this case will be lost. Do you think we should keep them?

Should these instead be defined in a 'Settings' or 'Admin' section for cases? Are there different personas that would define these fields, and then others that would consume them when creating a case?

I would say yes to both. An administrator can define/create the definition of the fields but they should be able to limit access to the configuration page for other users. They can use them but they cannot change their definition (key, label, etc).

Should I be able to reorder the custom fields (and current fields) on the form? What about hiding or showing current fields in favor of these custom ones? What about the order of the right sidebar once the case is created?

I think the custom fields should be after our fields (core). The order can be alphabetical. We can revise in the future and provide these capabilities.

[shanisagiv1]

great questions.. let's have a quick sync to answer all. will be better than collaborating on that here.

[mdefazio]

Linking the design document with prototypes.

[cnasikas]

@shanisagiv1 Should we close the issue? The "custom fields mapping with 3rd party fields" and "Advanced Use cases and Requirements (2nd phase)" are not implemented (We will work on telemetry on 8.13+). I think is better if we have one issue for each request/bullet if we plan to prioritize and implement them. Wdyt?

[shanisagiv1]

I'd suggest breaking it down and opening the other issues and linking them to this one before closing this one, just to make sure we wont miss anything. wdyt? @cnasikas

[twanva]

• The fields can be leveraged for connector syncs, the user will have to map between the case fields and 3rd party fields (out of scope for this request)

Hi, the above feature would be very much appreciated. For the Webhook Case Management connector this would be very helpful. Are there any plans for this feature?

[shanisagiv1]

Thanks for the feedback, it's on our radar to support that, yes.

[cnasikas]

I'd suggest breaking it down and opening the other issues and linking them to this one before closing this one, just to make sure we wont miss anything. wdyt? @cnasikas

@shanisagiv1 Could you please open the issues describing the features that you would like custom fields to support?