# Use Case

## **Notify Requester and Assignee on Ticket Field Modifications**

### **Scenario**

In a support environment, certain ticket updates—such as changes to Status, Priority, Assigned Team, or Impact Service—can significantly affect resolution timelines and ownership. To ensure transparency and timely communication, the system must automatically notify relevant stakeholders whenever these critical fields are modified.

### **Configuration Overview**

An administrator configures a Notification Configuration rule with the following details:

* **Module:** Ticket
* **Workflow:** Ticket Antivirus
* **Type:** Notification Configuration
* **Fields:** Status, Impact Service, Team, Assignee, Priority
* **Notify To:** Requester, Assignee

<figure><img src="/files/7LN5qo9hD0qBbRLWGpqh" alt=""><figcaption></figcaption></figure>

This configuration ensures notifications are triggered only when one or more of the selected fields are changed.

### **How It Works**

1. A ticket is created and assigned to a support engineer.
2. During ticket handling, the assignee updates one or more configured fields—for example:
   1. Status is changed from *Implementation* to *Reschedule*
   2. Priority is changed from *Medium* to *High*
3. The system detects that the modified fields are part of the Fields selection in the notification configuration.
4. A notification email is automatically sent to:
   1. The Requester, to keep them informed of changes
   2. The Assignee, for confirmation and traceability

### **System Behavior and Controls**

* Notifications are triggered only when fields listed in the Fields configuration are modified.
* Changes to other, non-selected fields do not trigger any notification.
* Multiple field changes in a single update are consolidated into one notification email.
* The notification email is automatically logged in the Communication tab of the ticket for audit and reference.
* The system prevents duplicate notification configurations for the same Module and Workflow combination.

### **Outcome**

This configuration ensures that:

* Key stakeholders are immediately informed of meaningful ticket changes.
* Noise from unnecessary notifications is avoided.
* All field change communications are traceable and auditable within the ticket lifecycle.

## Enforcing Mandatory Fields on Status Change

Ensure that specific fields are required before allowing a **ticket status transition**, per configured Field Configuration rules.

This enhancement validates mandatory fields during **status change** and prevents progression if required fields are not completed.

### Requirement

An organization wants to:

* Enforce completion of specific fields before moving a ticket from one status to another.
* Prevent users from bypassing mandatory fields during quick status updates.
* Ensure validation works consistently across:
  * Grid View (Smart Grid)
  * Panel View
  * Nested Quick Edit View

### Configuration

{% stepper %}
{% step %}

### Step 1: Create a Field Configuration Rule

* Navigate to: **Infraon Configuration → Automation → Field Configuration**
* Click **Add Field Configuration**
* Configure the following:

| Field     | Value (Example)                    |
| --------- | ---------------------------------- |
| Module    | Incident                           |
| Workflow  | Ticket Workflow                    |
| Type      | Field Configuration                |
| Role Name | Admin-Read Only (or required role) |
| Status    | Waiting for Closure                |

* Under the selected status, mark required fields as **Mandatory** (for example: Resolution Notes, Impact Service).
* Click **Submit**.

This rule now enforces mandatory fields for the selected status.
{% endstep %}
{% endstepper %}

### Scenario: Status Change with Missing Mandatory Fields

A user attempts to change the ticket status, but the mandatory fields configured for the status are not filled.

This validation applies in:

* Grid View (Smart Grid)
* Panel View
* Panel Quick Edit (Nested View)

#### System Behavior

When a user attempts to change the ticket status:

* The system checks the configured Field Configuration rules.
* If mandatory fields for the target status are empty:
  * A **toaster message** is displayed indicating mandatory fields are missing.
  * The ticket **sidebar opens automatically**.
  * All mandatory fields are highlighted for completion.
* The ticket status **does not change** until all required fields are filled.

#### Successful Status Change

Once the user:

1. Fills all mandatory fields as per the configured rule.
2. Attempts to change the status again.

Then:

* The status change is processed successfully.
* No toaster message is displayed.
* The ticket moves to the selected status.

#### Validation Flow Summary

| Action                                       | System Response             |
| -------------------------------------------- | --------------------------- |
| Status changed with missing mandatory fields | Toaster message displayed   |
| Mandatory fields missing                     | Sidebar opens automatically |
| Mandatory fields completed                   | Status change allowed       |
| Mandatory fields incomplete                  | Status change blocked       |

{% hint style="info" %}
**Note**

* Validation is triggered during **status transition**.
* Applies consistently across all ticket interaction views.
* Prevents incomplete data during workflow progression.
* Ensures compliance with configured workflow rules.
* Improves data integrity during lifecycle transitions.
  {% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.infraon.io/infraon-help/infinity-user-guide/infraon-configuration/infraon-automation/field-configuration/use-case.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.