Allow Fields to be set Mandatory by Condition(s)

I request the ability to set mandatory requirements for Fields using conditions, much like how conditions are are used to trigger Rules.

There are a few reasons why I would like to have this ability:

We've found out that having any field within the Resilient system with a requirement of "Mandatory" or "On-Close" will be required across all tickets, even if the fields are not specified in any New Incident Wizard creation or any tabs whatsoever.

For example, I can create a field call "Test" make it mandatory, not place it the new incident wizard, any tabs, any tasks, workflows, rules etc, but yet it will be required in order to create any incident on the system; the same holds true for with a requirement of "On-Close". We rely heavily on our email connector and if someone where to accidentally create a random test field, make it mandatory, this would halt the functionality of auto-incident generation because of a random mandatory field.

Currently Fields can be visible/hidden based on type using "Sections", but we cannot mandate their completion if they are not always visible. As the user wont have the ability to fill in a Field that they cant see/isnt presented to them.

We would like to have the capability to have fields set as "mandatory" or "optional" per ticket (incident) type. This would increase efficiency and compliance as for example, auditors require all Use Case Design fields to be completed. If any field is not applicable, it still requires a "not applicable" or other similar text in it.

This would allow the ability for different Playbooks used, Groups assigned or Tasks completed to dictate whether a Field must be answered.

 

For example:

Field: "Malware Family"

Required: When Incident Type Contains Malware AND Owner is Level 1

When Required: On-Close

 

The above example would make the Field "Malware Family" required to be filled in for an incident to be closed when it is a Malware Incident and is Owned by the Level 1 Group.

  • Guest
  • Apr 12 2018
  • Future consideration
  • Guest commented
    6 Nov, 2019 07:35pm

    We would also benefit greatly from this. Our current use case:
    We would like to require a closing reason for our Resilient incidents that originate from QRadar offenses - matching the way QRadar offenses used to be worked (before we got Resilient). However, we are planning on bringing in Resilient incidents from other locations as well (e.g. Service Now). It doesn't make sense to require the "QRadar Closing Reason" on an incident that doesn't originate from QRadar.

  • Guest commented
    4 Nov, 2019 02:31am

    Would love to see this. We are running into the problem of how to force required data for certain incidents to be filled out. We have contractual and legal requirements for certain responses to be in our incidents. But these fields only need to be filled out for certain incidents and not all incidents in our Resilient system.

  • Guest commented
    15 Aug, 2019 01:50pm

    I would like to see this expand into workspaces. To have the capability to have fields set as "mandatory" or "optional" per ticket (incident) type and workspace.  My Privacy Workspace has different mandatory closing items than our SecOps workspace.

  • Guest commented
    17 May, 2019 01:12pm

    Hi Martin - I'm available to discuss the specific use cases as well. I believe this would be a great improvement within Resilient, and bring it in line with other Incident Response tools and their ability to respond dynamically to incidents.

  • Admin
    MARTIN FEENEY commented
    17 May, 2019 09:48am

    Hi Pat, we're currently reviewing top voted ideas with a view to identifying gaps, which ones are on our roadmap, which not, which are impacted by other roadmap items and so potentially their priority would change, etc. Theres a bit of travel happening at the moment but as soon as we get people back at their desks we'll continue this exercise and update when concluded.

  • Guest commented
    16 May, 2019 03:35pm

    Is there a status update on this or the 3 merged ideas? These are highly voted ideas, which if implemented would improve the usage of Resilient for it's users, and ease the building of playbooks & configurations by administrators.

  • Admin
    Brenden Glynn commented
    11 May, 2018 02:14pm

    Additional context:

     

    Example 1:  On the New Incident Wizard an Always Required Field is Conditionally hidden in a section because it is not relevant based on the previous Field choices. The User will not have the ability to put a Value in that field.

    Example 2: On an Incident Tab Layout, a Field is always Required for a Malware Incident, but not a DoS Incident. The Field can be placed on a Conditional Section where it only appears on Malware Incident, however it cannot be natively Always Required as it will always be required since it is on a layout. Exposed to the User or not.

    A Script can be created helper.fail to require the Field based on a condition, however this cannot be enforced on the New Incident Wizard.