Case workflow rules: tagging and metadata

Overview

As security landscapes continue to evolve, it is vital to inject structure and order into case work flows, enhancing organization, conventions, and collaborative work environments.

A new case lifecycle rules capability introduces support for mandatory tags and metadata fields during specific case workflow status transitions.

To create tag/metadata rules, navigate to Settings > Case Workflow Rules > Transition Rules.

How to use case workflow rules

Case workflow rules allow you to enforce organizational policies automatically during case management workflows. When configured, these rules ensure that analysts meet specific requirements before they can change a case's status.

Rule types

Cydarm currently supports workflow rules pertaining to:

1. Transition rules -- Enforce requirements when an analyst changes a case from one status to another (e.g., "Analysis" to "Closed"). These are the primary rule type used in day-to-day operations.

What Analysts will experience

1. Status changes with transition rules

When a Transition Rule applies to a status change, analysts will see the following workflow:

1. The analyst selects a new status for a case (e.g., moving from "Analysis" to "Closed").

2. The system checks all enabled rules that match that particular transition.

3. If any requirements are unmet, a Justification Modal appears, preventing the status change until the analyst addresses each issue.

4. The modal displays categories of requirement(s):

   • Actionable requirements that can be resolved directly within the modal. These include inline controls for adding tags, setting severity, or assigning a user.

5. As the analyst resolves each requirement, the requirement will update to an acceptable state, and await confirmation.

6. The Submit button remains disabled until every requirement is met.

Note: Even after the analyst submits the modal, the system performs a final validation before completing the status change. If conditions have changed since the modal was opened, the analyst may be asked to re-verify.

2. Mandatory tags

Rules can require that a case has at least one tag from a specific tag group before a status change is permitted. Tags follow a group:value naming convention (e.g., casetype:incident, casetype:vulnerability), and any tag within the required group satisfies the rule. Multiple tag groups can be required simultaneously — for example, a rule might require both a casetype and a priority tag. When a requirement is unmet, a pre-filtered tag selector appears in the Justification Modal, with green indicators showing which groups still need a selection. Tags are applied when the analyst submits the modal, not on selection, meaning no changes are persisted until the full action is confirmed. For backward compatibility, tag group requirements also recognize tags set via legacy system properties.

3. Metadata enforcement

Rules can also require that a case meets conditions around severity and assignment before a status change is allowed. Severity requirements support equals, greater than, and less than operators. Assignee requirements support three patterns: has a value (any user is assigned), equals (a specific user is assigned), and is empty (no one is assigned). When these conditions are unmet, the Justification Modal displays inline controls (a severity dropdown / user selector) allowing the analyst to resolve the issue without leaving the modal. As with mandatory tags, all changes are batched and applied together with the status change on submit, ensuring nothing is persisted until the analyst confirms the action.

How rules are evaluated

Understanding the evaluation pipeline helps predict how rules will affect your team:

• Exceptions are evaluated first. If an exception condition matches the current case, the rule is skipped entirely. Use exceptions to create overrides for specific scenarios.

• Conditions are evaluated next. If a rule's conditions do not match the current case, the rule simply does not apply -- this is not treated as an error.

• Requirements are enforced last. Only when a rule's exceptions do not apply and its conditions match will the system check whether requirements are met.

Key details for administrators

• Each organization maintains its own set of rules. Rules configured for one organization do not affect cases in another.

• Disabled rules are completely ignored during evaluation and will not affect analyst workflows.

• Rules support wildcard matching using the * character for status fields. A rule with a "from" status of * applies to transitions from any status.

• Transition Rules apply to the specific direction of a status change. A rule configured for "Open to Closed" will not trigger for "Closed to Open."

How to configure case workflow rules

Case Workflow Rules allow administrators to enforce governance policies on case status transitions. These rules ensure that analysts meet specific prerequisites before moving a case from one status to another.

Accessing case workflow rules

1. Navigate to Settings from the main application menu.

2. Select Case Workflow Rules from the settings sidebar.

3. If your account belongs to multiple organizations, use the organization dropdown at the top of the page to select which organization's rules you want to manage. Single-organization users will see their organization name displayed automatically.

The page opens to the Transition Rules tab, which is the primary configuration surface.

Understanding the workflow transition graph

At the top of the Transition Rules tab, an interactive graph visualizes all case statuses and the allowed transitions between them.

• Blue nodes represent start states (e.g., New, Open).

• Green nodes represent end states (e.g., Closed, Resolved).

• Gray nodes represent intermediate states.

• Edges (arrows between nodes) represent allowed transitions.

You can interact with the graph in two ways:

• Click an edge to filter the rules list below to only those rules that apply to that specific transition. A filter chip appears (e.g., "Filtered: Open → Closed") which you can dismiss to return to the full list.

• Click a node to open a detail panel showing all incoming and outgoing transitions for that status.

Creating a transition rule

To create a new rule, click the Add Rule button. A three-step wizard guides you through the process.

Step 1: Basic information

1. Enter a Rule Name (required). Choose a descriptive name such as "Require casetype tag before closing."

2. Optionally provide a Description explaining the rule's purpose.

3. Configure the Trigger:

   • Select one or more statuses in the From States dropdown, or choose Any State (\*) to match all origin statuses.

   • Select one or more statuses in the To States dropdown.

   • Leave a field empty or select "Any State (\*)" to match all states for that side of the transition.

Step 2: Conditions and exceptions

Conditions determine when the rule applies. All conditions must be true for the rule to activate. For each condition, select a Field, an Operator, and a Value:

• Tags -- Operators: "Has specific tag," "Has tag from group," "Does not have tag from group"

• Severity -- Operators: "Equals," "Does not equal," "Greater than," "Less than"

• Assignee -- Operators: "Has a value," "Is empty," "Equals," "Does not equal"

You may add multiple conditions. Each condition can optionally include a display label for clarity.

Exceptions use the same field, operator, and value structure. If any exception condition matches, the entire rule is skipped regardless of whether conditions are met. Use exceptions to carve out scenarios where enforcement is unnecessary.

Step 3: Requirements

Requirements define the prerequisites that must be satisfied before the transition is permitted. They follow the same field, operator, and value structure as conditions. These are what analysts will be prompted to fulfill when attempting the transition.

Click Create Rule to save.

Managing existing rules

The rules list below the graph displays all configured transition rules with their name, description, applicable From and To states, and current status.

• Enable or disable a rule using the toggle switch on each row. Changes take effect immediately.

• Edit a rule by clicking the edit icon. The wizard reopens pre-populated with the rule's current configuration. Click Update Rule to save changes.

• Delete a rule by clicking the delete icon. A confirmation dialog will ask you to verify the deletion before it is carried out.

Practical examples

1. Require a casetype tag before closing a case 

2. Require severity before escalation 

3. Skip tag requirements for test cases