Incident Management

Editable Custom Attributes Post-Closure

Administrators can now configure which Incident custom attributes remain editable and addable after an Incident reaches a terminal status (Closed, Cancelled). This capability addresses real-world scenarios where additional information needs to be captured or updated after ticket closure without requiring ticket reopening.

A new company-specific admin property "Post-Closure Custom Attribute Update" controls this behavior:

• Stores the list of custom attributes allowed for post-closure editing and addition
• Contains an Enable/Disable flag to activate the feature per company
• Accessible only to users with administrator role

Administrators must set Enable = True if they want to allow the support users to edit Custom attributes at terminal status otherwise set the attribute as False. Administrators also must mention the exact Custom attribute(s) labels which can be edited or added post closure separated by comma in case there are multiple.

This enhancement improves operational flexibility by enabling post-closure data collection for compliance, analytics, or quality management purposes without disrupting the ticket lifecycle or requiring complex workarounds.

UI Behavior on Incident Form (Terminal Status)

1. Custom Attribute Section Header

   On the Incident form, in the Custom Attributes section header (when Incident is in terminal status) now two new icons are displayed to the Incident Support Users:

   • Edit icon (for editing existing custom attributes).
   • “+” icon (for adding new custom attributes).​

   

2. Editing Custom Attributes (Post-Closure)

   When the Incident is in a terminal status:

   Upon clicking the Edit icon in the custom attribute section header.
   • All existing custom attributes are displayed as usual.
   • Only attributes which are mentioned in the admin property are editable.
   • All other attributes in the section remain read-only.​
   On Modifying the required Custom attribute values and Saving:
   • Changes are validated as per existing custom attribute validations.
   • Valid changes are persisted at the backend in Incident table
   • An audit log entry is created for each modified field
   Note:

   Editing is available only when the Incident is in terminal status.

   

3. Adding Custom Attributes (Post-Closure)

   When the Incident is in a terminal status:

   • A “+” icon is visible in the custom attribute section header.
   • On click, system opens a dropdown listing custom attributes that:
     • Belong to the Incident module.
     • Are configured in the admin property.
     • Are not already added to this Incident.​
4. Users can then save the Custom attributes which are persisted at the backend.

   

5. Data Persistence and Audit Logging

   On Save (edit or add) in terminal status:

   • All updated values are stored in the existing tables
   • The Change is captured in audit and an audit log entry per attribute changed or added.

6. Security and Permissions

   • Only users with appropriate Incident update permissions can:
     • Edit allowed custom attributes in terminal status.
     • Add allowed custom attributes in terminal status.​
   • No changes are allowed if the user lacks writing permission, even if the attribute is configured in the admin property.
   • Audit entries must always capture the actual user performing the change.
   • The validation “Unable to Modify Cancelled/Closed tickets" has been bypassed for only Custom attributes update when the admin setting value “Enabled= True”

Parent- Child Assignment Group Synchronization

When enabled by administrators, changes to the Assignment Group on a parent incident can automatically update the Assignment Group on all related child incidents, ensuring consistent ownership and reducing manual reassignment overhead in complex incident hierarchies.

Parent-Child Auto Update Property

A new company-specific configuration property controls synchronization behavior for three attributes:

• Status (default: Yes) - Status changes on parents can update child incident statuses
• Support Group / Assignment Group (default: No) - Controls whether Assignment Group synchronizes
• Support Individual / Assignee (default: No) - Controls whether individual assignee synchronizes

Administrators configure this property using JSON format at the company level, enabling granular control over which attributes propagate from parent to child tickets.

Synchronization Rules

When Support Group is enabled and a parent incident's Assignment Group changes:

• System identifies all child incident tickets belonging to the same company that are not in terminal status
• Updates their Assignment Group to match the parent
• Child incident status automatically changes to "Submitted" per existing functionality
• Peer incidents are not affected; only true child incidents are updated

Support Individual Behavior

The interaction between Support Group and Support Individual settings determines assignee handling:

• If Support Individual = "No" and Support Group = "Yes": Child incident's Assignee is cleared when Assignment Group changes
• If Support Individual = "Yes" and Support Group = "Yes": Child incident's Assignee is copied from parent when Assignment Group changes

Admin Configuration Options

The Parent-Child Auto Update property governs how synchronization works at company level:

Status Configuration:

• If set to "Yes": Status changes on the parent incident can automatically update the status on child incidents
• If set to "No": Status changes on the parent incident will not auto-update child incident statuses

Support Group Configuration (Assignment Group):

• If set to "Yes": Child incidents' Assignment Group is automatically updated when the parent's Assignment Group changes
• If set to "No": Child incidents' Assignment Group will not change when the parent's Assignment Group changes

Support Individual Configuration (Assignee):

• Controls whether the Assignee field propagates from parent to child
• Interaction with Support Group setting determines whether Assignee is cleared or copied

All Sync Options Disabled:

If the property is configured so that Status = "No", Support Group = "No", and Support Individual = "No", then changes to the parent incident's Assignment Group, Status, and Assignee will not automatically propagate to child incidents.

Conditions and Limitations

To avoid unexpected behavior and performance issues, the following rules apply:

Same Company Only:

• Only child incidents belonging to the same company as the parent are updated
• Child incidents belonging to other companies are not changed

No Terminal Status Updates:

• Child incidents in terminal status (Closed, Cancelled, Completed) are not modified
• This prevents disruption of completed work and maintains data integrity

No Peer Impact:

• Synchronization applies only to direct child incidents, not peer relationships
• Preserves correct incident hierarchy boundaries

Performance Considerations:

• Large numbers of child incidents may impact performance
• Administrators should consider this when enabling the feature for parent incidents with extensive child ticket populations

Audit Trail

All automatic updates to child incidents are recorded in audit logs as System changes, maintaining complete traceability of automated modifications.

The audit log captures:

• Assignment Group changes triggered by parent updates
• Status changes resulting from synchronization
• Assignee modifications (cleared or copied)
• System user shown as the actor, consistent with existing behavior for automatic updates

Benefits

This enhancement streamlines incident management workflows where parent-child relationships represent coordinated resolution efforts:

• Reduces manual reassignment effort for complex incident hierarchies
• Ensures consistent ownership across related tickets
• Improves coordination for multi-team incident resolution
• Maintains accurate workload distribution
• Supports efficient escalation workflows
• Provides complete audit trail for automated changes
• Eliminates risk of orphaned child incidents with outdated assignments
• Enables centralized control of incident ownership through parent ticket management

Configurable "Reported Through" Field

This enhancement lets you configure the Incident Through (Reported Through) field per company, while still providing a default list of values such as EBonding, Monitoring, Walk In, Email, MyService, Integration, Web, Phone, Chat, Service Request, and Virtual Agent. Administrators can add or modify values for the Incident module through configuration (module = Incident, field = ReportedThrough) using key, value, sequence, and an isVisible flag, so options can exist in the backend without showing in the UI.

Functionally, only the configured values appear on the Incident Create/Edit form. Incidents created from Service Catalog set Through to Web, from E2T to Email, from eBonding to the payload value, from alerts to Monitoring, and from the Chat Bot to Virtual Agent. For copied Incidents, the Through field remains editable until the record is submitted; for all other Incidents it becomes read-only after submission, and the same Through value is preserved when creating new Incidents via Copy Incident or Propose Incident from Incident/Problem modules.

Incident Templates

Users who frequently create similar Incidents can now save and reuse pre-defined Incident data through the Templates feature, significantly reducing data entry time and improving consistency across recurring Incident types.

The Templates capability enables users to capture commonly used field combinations as reusable templates, then apply those templates to pre-fill new Incident forms with a single click. This streamlines repetitive Incident creation workflows such as standard maintenance windows, recurring service requests, or category-specific Incidents that share common attributes.

Roles and Entitlements

Two role-based entitlements control template functionality:

Template Owner (template_owner role):

Users with any Incident creation role (Incident User, Incident Manager, Critical Incident Manager, or Service Desk) plus the template_owner role can create and save templates. Template owners can define template accessibility as either Self (personal use only) or Groups (shared with specific assignment groups).

Template User (template_user role):

Users with any Incident creation role plus the template_user role can search for and apply templates they are entitled to use. Entitlement is determined by template accessibility settings—users see templates they own or templates shared with groups they belong to, limited to the Incident module.

This role separation enables organizations to control who can create reusable templates while allowing broader access for template consumption.

Creating and Saving Templates

On the Create Incident page, users with template_owner role access the template creation function through a three-dots icon displayed next to the Search Template field. Clicking this icon reveals the "Save as Template" option.

When "Save as Template" is selected, the system captures the current state of the Incident form and presents a dialog prompting the user to specify:

• Template Name – A descriptive identifier for the template
• Description – Details about the template's purpose or use case
• Template Accessibility – Self (personal) or Groups (shared), with Self as the default selection

Templates can be saved at any stage of form completion—even if mandatory Incident fields are not filled or if the form is completely blank. This flexibility supports various use cases, from partial data templates to comprehensive pre-filled forms.

Upon successful save, a confirmation message appears and the template is stored in the templates table with its accessibility settings. The user is automatically redirected to the My Templates view to review and manage their saved templates.

Using Templates During Incident Creation

Users with template_user role access templates through a Search Template field positioned at the top right of the Incident create form. This field displays only templates the logged-in user is entitled to use based on template accessibility settings and group membership.

Template Selection Prerequisites

Fill from template functionality is enabled only after a Company is selected on the Work Item record. If a user attempts to select a template before choosing a company, the system displays an error message instructing the user to select the company first.

Once the Company field is populated, the Search Template dropdown displays the list of available templates filtered to the Incident module and the user's entitlements.

As the user types into the Search Template field, the dropdown dynamically filters template names to match the typed text, enabling fast template discovery in environments with many saved templates.

Important: Applying a template only pre-fills the form. Users retain full control to modify any populated values, add additional data, or adjust fields before saving the Incident record. This ensures templates serve as starting points that accelerate data entry without constraining user flexibility.

Add New User from Incident Form

Support users working in the Incident module can now create new user profiles directly from the Incident form when the Requested For user's profile does not exist in the BigFix Service Management database. This capability streamlines the incident logging process by eliminating the need to navigate to separate user administration screens.

Users access this functionality through an "Add User" icon displayed on the Requested For and Caller fields. Clicking the icon opens a form in the right panel where support users enter the required information to create the new user profile.

Four mandatory fields must be completed: User's First Name, Last Name, Contact Number, and Email Address. Upon save, the new user profile is created for the selected Company as a Guest User with the default role of "Service Consumer". The support user can then immediately select the newly created user in both the Requested For and Caller fields, allowing incident logging to proceed without interruption.

This enhancement eliminates context switching between modules, reduces incident logging time, improves service desk efficiency, ensures consistent user data capture, removes dependency on administrator intervention for urgent incident logging, and supports faster resolution of user issues by eliminating delays in ticket creation.

Global Incident Flag

A new field on the Incident form enables support users to tag incidents as Global Incidents, identifying issues that impact a large user base or span multiple geographies. This capability improves visibility into organization-wide service disruptions and supports coordinated response to widespread issues.

By default, the Global Incident field is set to False for all new incidents. Users may change it to True at any point in the incident lifecycle, except when the incident is in a terminal status (Closed, Cancelled, or Fixed). This ensures accurate historical data while preventing modifications to completed incidents.

The Global Incident column can be added to incident list views through standard list personalization, enabling support teams to quickly filter and identify organization-wide issues when reviewing work queues.

Reports can be created using the Global Incident flag, enabling users to identify Global Incidents and their related child tickets for analysis, trend identification, and impact assessment.

The visibility of the "Global Issue" field is controlled by an administrator setting named "Global Issue Field" under the Incident section.

With a default value of False, this property can be set to True to make the Global Issue field visible for specific tenants that require this capability.

Auto-Resolve Related Incidents on Problem Closure

This enhancement allows tenants to automatically update and resolve all open related Incidents when a Problem ticket is permanently resolved with Closure Reason = “Closed – Implemented.”

When enabled, the system identifies all open Incident work items linked via Related Work Items to that Problem and, on closure, sets each Incident’s status to Fixed, populates the Incident Resolution fields with default values (Type of Fix = Resolved by Problem), and copies the Problem’s closure/resolution notes into the Incident’s Resolution Notes, after which the Incidents follow the existing closure workflow (for example, direct closure or auto-closure from Fixed). This behavior applies only to the Problem Management and Incident Management modules, affects only open related Incidents (closed/cancelled Incidents are ignored), and is triggered exclusively when the Problem is closed with the “Closed – Implemented” reason.​

Control over this automation is provided via an admin property “Update related Incidents on Problem Closure”, configured per tenant/company in BigFix Service Management admin settings.

When this property is set to true, the automation is active: closing a Problem as “Closed – Implemented” copies its closure notes to all open related Incidents’ Resolution Notes and sets their status and Type of Fix accordingly; when set to false (the default), no automatic updates occur, and support users must manually resolve or close related Incidents regardless of how the Problem is closed.

If the Problem is closed with any other closure reason (for example, not Closed – Implemented), no automatic updates are performed on related Incidents irrespective of the property value, leaving teams free to manage them case by case.​

For support users, this feature shifts some responsibilities while preserving governance. To leverage the automation, they must ensure all relevant Incidents are correctly linked to the Problem, enter clear and complete closure/resolution notes in the Problem (since these will appear on the Incidents), and then close the Problem with Status = Closed and Closure Reason = Closed – Implemented.

If an Incident did not update, users are advised to check that it was still open at the time of Problem closure, properly linked, closed with the correct reason, and that the admin property is set to true; organizations preferring full manual control can keep the property at false so the linkage remains informational only, with no automated status changes.​

Add New User from Incident Form

This enhancement lets support users in the Incident module create a new user in Foundation directly from the incident form when the Requested By or Requested For user does not exist. By clicking the Add User icon on these fields, a side panel opens where the agent enters the mandatory details: First Name, Last Name, Contact Number, and Email Address.

On saving, a new profile is created for the selected company as a Guest User with the default Service Consumer role, and the newly created user becomes immediately selectable in both Requested By and Requested For (Caller) fields.

Use 'Additional Information' in Incident Notification Templates

The Additional Information field available to notification admins when designing or editing incident email templates. The field has now been added across all incident notifications, and admins can update default templates or create custom ones that include this attribute as needed.

A new template variable, <%=additionalInfo%>, is now exposed for use in custom email templates for the following notifications:

• Incident Submitted – Notify Assignment Group
• Incident Reassigned to a Group – Notify Assignment Group
• Incident Fixed – Notify Requestor
• Incident Submitted – Notify Requestor
• Incident Submitted – Notify Assignment Group (Requested For)
• and Incident Submitted – Notify Requested For.

This ensures any additional context captured on the incident is consistently communicated to both requestors and assignment groups in notification emails.

Enhancements to Impacted CI Field on Incident Form

On incident form (work item board), specifically in the Impacted CI field, when we search for an existing CI and populate it, an information icon is visible and upon clicking it, a CI Quick View opens towards the right of the screen. This CI quick View has been enhanced to show the details Location and Assigned To along with the existing details like - CI Name, Company, Class, and Status.

When this CI quick view opens upon clicking the information icon against a populated Impacted CI field on the incident form, then the first detail in this quick view is CI Name. Hyperlink to the CI Name attribute has been added such that when it is clicked upon, the CI record / form opens in a new tab.