Change Management

Configurable "Reason for Change" Field

Static "Reason for Change" values in the Change module have been transformed into company-configurable menu lists, enabling administrators to align change categorization with organizational change management frameworks and terminology.

Previously, the Reason for Change field contained a fixed set of values that, while covering common change drivers, did not accommodate every organization's specific terminology or change classification schemes. Administrators now have complete flexibility to add, modify, or hide these values to match ITIL frameworks, organizational change models, or industry-specific requirements.

This enhancement strengthens change management by aligning categorization with ITIL or custom frameworks, improving analytics and compliance, making reports more meaningful for stakeholders, preserving historical data during schema changes, and supporting independent schemes for each tenant in shared environments.

Default data is as below :

Maintenance and Freeze Window Conflict Warnings

The new enhancement introduces intelligent validation of Planned Start and End dates on the RFC form against configured maintenance and freeze (blackout) windows for the selected Configuration Items (CIs). When a change is created, the system automatically evaluates whether the schedule fully complies with the allowed maintenance window and whether it overlaps with any freeze window, then displays a clear warning message whenever a conflict is detected.

This helps change managers and implementers avoid risky scheduling and improves overall governance without blocking legitimate emergency work (users can still proceed by choosing to ignore the conflict where allowed).​

Maintenance window validation ensures that change schedules are aligned with approved service downtime for each CI. The system checks if the entire change schedule falls within the configured maintenance window and raises a warning whenever any part of the planned change lies outside that window, while remaining silent when the schedule is fully inside. This behaviour is supported by clearly defined rules and scenarios (for example, partial overlap before or after the maintenance window always triggers a warning), giving change coordinators predictable and consistent guidance at planning time.​

Freeze (blackout) window validation prevents changes from being scheduled during high-risk or business-critical periods configured for each CI. Whenever the planned change dates overlap with a freeze window, the system displays a warning if there is any overlap at all and does not show a warning only when there is no overlap with the blackout period. This allows organizations to protect critical periods such as month-end closures or peak trading hours, while still giving full visibility to change owners before they submit or approve an RFC.​

To further support decision-making, the enhancement also adds schedule visibility for all related CIs directly from the RFC form. For each related CI with configured schedules, a view option lets users quickly open a pop-up displaying its maintenance and freeze/blackout windows, or a message indicating that no schedule is configured, so they can assess impact across the full technical stack before finalizing the change.

A guided workflow helps users select the CI, enter planned dates, review any warnings, and adjust the schedule or proceed as needed, improving both compliance and user experience.​

Change Calendar with Maintenance and Freeze Windows

The Change Calendar view provides a monthly, weekly, and daily visual view of all planned Change activities, including Change records, Maintenance Windows, and Freeze (blackout) Windows for all CIs. It opens from the Change Work Item Board by clicking the calendar icon on the top-right, which launches the calendar in a new window in Month view by default.

Entries are color-coded for quick recognition: Green for Change Records (RFCs with Scheduled and Under Implementation status by default), Blue for Maintenance Windows, and Red for Freeze Windows, with a legend on the top-right of the calendar. Users can switch between Day, Week, and Month views, use a Type filter (Scheduled Change, Maintenance Window, Freeze Window) and a Change Status filter (shown when All or Scheduled Changes is selected), and click Reset to return to default filter values.

The search bar lets users find entries by Change Number, Maintenance Schedule Name, or Freeze Schedule Name, with matching entries highlighted or filtered. Hovering over an entry shows ticket or schedule name, exact start and end dates, and a short summary (truncated with dots if long), left-aligned and formatted according to the user’s date settings.

Clicking a Change Number opens the Edit Change page, while clicking a Schedule Name opens the Edit Schedule page (based on permissions).

This enhancement helps teams quickly understand upcoming changes, avoid conflicts with maintenance and freeze periods, and take action directly from the calendar using filters, search, hover details, and click-through navigation.

Configurable Multi CI Approval Visibility at Company Level

A new company-level configuration, EnableMultiCI, has been introduced to give administrators control over whether the “Approval on Multi CI” checkbox is visible on the Change form. This foundation-level property is defined per company, allowing each organization to independently decide if Multi CI Approval should be enabled or disabled for its change management process. By default, the setting is disabled (False), so the Multi CI approval option remains hidden unless explicitly turned on.​

When Enable Multi CI is set to False, the “Approval on Multi CI” checkbox is completely hidden from the Change form and users cannot select or use Multi CI Approval. This ensures that organizations that do not follow a multi-CI approval process maintain a clean, simplified UI for their change users. Once the property is set to True, the checkbox becomes visible, enabling change teams to leverage Multi CI Approval for relevant change records.​

Administrators can configure this behaviour directly from Foundation → Configuration → Settings, where the Enable Multi CI property is available at the company level. After updating the property value and saving, the change takes effect immediately for the selected company, without requiring additional deployment steps. This makes it easy to pilot Multi CI Approval with specific companies or roll it out gradually across the tenant.​

On the Change form, when Enable Multi CI is True, the “Approval on Multi CI” checkbox is visible to all roles (change manager, user, and viewer), while remaining editable only for change managers and change users. The capability applies to all change types except Standard Change, ensuring that routine, low-risk changes remain streamlined and do not require multi-CI approval configuration. This enhancement gives organizations more granular control over how multi-CI approvals are used, aligning the UI and behaviour with their governance model.

Tenant-Specific Risk Assessment and Change Type Visibility

Brought in the ability to hide the “GBP Risk Assessment” option from the Risk Assessment Methodology dropdown on the Change form for specific tenants that use a customized risk assessment model. For those tenants, the GBP Risk Assessment choice is removed from view so that users only see the approved methodology, while other tenants remain completely unaffected by this change.

Change Managers, Requesters, and other change users in the configured tenant will now work with a focused list of risk assessment options aligned to their governance model.​

Administrators can manage this behavior via Admin Preferences → Change module, where they can toggle a Yes/No configuration under Change Risk Methodology to control whether the GBP option is shown or hidden. Once configured, they can verify the outcome by creating a new Change and confirming that the Risk Assessment Methodology dropdown no longer displays “GBP Risk Assessment” and instead only lists the customized option.​

In addition, the enhancement adds configuration to hide the “Latent” change type from the Type dropdown when creating new Change Requests, for clients that do not use this category. Admins can control visibility under Admin Preferences → Change module by adjusting the Yes/No values in the “Default Change Type” configuration ensuring that “Latent” is excluded while all other relevant change types remain available. Change Requesters and Change Managers in the configured environment will see a simplified Type dropdown that reflects only the change types adopted by their organization.​

Create a New CI Directly while Raising a Change

This enhancement allows Change Managers and Change Users to create a new CI directly from the Create Change page, without needing separate CMDB access. While creating a change, users select the Company, go to the Impacted CI field, and either search for an existing CI or click the “+” (plus) icon to add a new one when the required CI is not available. The “+” icon is visible only on the Create Change page, ensuring CI creation is tightly controlled within the change workflow.​

Clicking the “+” icon opens a Create New CI panel on the right side of the screen, which shows only the required fields so creation is quick and guided. Users fill in Name, choose Class, keep Type (pre-set to CI), and select Category, Sub Category, Status, and Sub Status (Sub Status options appear only after a Status is selected), while the Is External flag is hidden and automatically set to No by the system.

After reviewing, users click Save and the system creates the CI with the chosen status and sub-status, returning clear messages for success (“Record has been successfully Created”), failure (“Record failed to create”) or duplicates (“Record already exists”).​

Once created, the new CI becomes immediately searchable under the Impacted CI field on the Change form, so users can select it and continue submitting the Change request without leaving the page. Key reminders include: CI creation is supported only while creating a Change, Sub Status is available only after selecting a Status, and no separate CMDB page access is required for these users, reducing friction while maintaining control over CI data.​

Enhanced "Requested For" Search on Work Item Board and Advanced Search

We have upgraded the Requested For field so it behaves like the Assignment Group search on the Work Item Board (WIB) and across Advanced Search. Previously, Requested For could only return users from the self company; it now also includes users from associated consumer companies, making it much easier to select the correct end user across multi-company environments.

The enhanced behavior is available across all applicable modules—Incident, Request, Change and Problem—and is consistent whether you’re using Advanced Search or any Work Item Board view (All, Assigned to Me, Assigned to My Groups, etc.).​

The Requested For field now supports typeahead search and multi-select, similar to Assignment Group. As you start typing a user name, the system dynamically displays matching users from both your own company and associated consumer companies, and you can select multiple users from the dropdown. Each chosen user appears as a selected item, and you can easily add or remove users, enabling more flexible filtering and targeting when analyzing work items.​

The search interface for Requested For follows the same pattern as Assignment Group for a familiar experience. The dropdown includes a search box at the top, a scrollable user list, checkbox-based multi-selection, optional Select All, and an OK button to confirm the final selection set. This consistent interaction model reduces training effort and makes it straightforward to filter by one or many requestors in a single step.​

In Advanced Search, the new behaviour means you can now search and filter results for users across both self and consumer companies and use multi-select to include multiple Requested For users at once in a single query. This significantly improves reporting, queue analysis and troubleshooting scenarios where work is performed for multiple customer organizations but needs to be viewed and filtered through a single Work Item Board or reporting view.

Sequenced Drop-Down Answers in Customized Change Risk Assessment

Sequencing is now applied to drop-down answers in the customized Risk Assessment Questionnaire in the Change module, so options appear in a predefined, logical order instead of an arbitrary list. Each answer (and question, where configured) has a sequence number, ensuring consistent presentation such as High → Medium → Low when those values are sequenced as 1, 2, and 3.​

Flash Messages for Ad-hoc Task Creation

This enhancement introduces an immediate pop-up flash message whenever a support user creates an Ad-hoc task from the Task section of any Work Item. Earlier, after clicking Save, there was no confirmation and users had to scroll down to the task list to verify if the task was created; the new behavior improves usability by giving instant feedback on success or failure

The pop-up appears when a support user creates an Ad-hoc task from the Task section on any Work Item and clicks Save. On success, a pop-up is displayed with the message “Task has been successfully created” along with an Ok button; clicking Ok closes the pop-up, and the newly created task is visible in the Task section.

If the Ad-hoc task creation fails, a pop-up appears with the message “Something went wrong”, prompting the user to retry the action. If the problem persists, the user is advised to contact the system administrator or raise a support ticket for investigation, ensuring errors are clearly surfaced instead of silently failing.

To use this capability, users simply open the required Work Item, navigate to the Task section, click Create Ad-hoc Task, enter the required details, and click Save, then wait for the pop-up confirmation. This behavior is consistent across modules accessed via the Work Item Board, so Ad-hoc task creation now always provides clear, on-screen confirmation of the outcome.

Swarming Collaboration Channels for Real-Time Incident Resolution

The new Collaboration (Swarming) feature lets incident teams create real-time communication channels (for example Technical, Business, Leadership) directly from the Incident page in BigFix Service Management, on tools such as Slack.

From the Work Item Board, authorized roles (Incident Manager, Incident User, CIM, Service Desk User) open the Incident Edit page, click the Collaboration icon, and use the Add Channel window to choose a Channel Type, Tool Type (currently Slack), add members (groups, individuals, and optional external users), and define comment sync options (Internal, External, or None) before clicking Proceed.

The system auto-generates a channel name in the format IncidentNumber–ChannelType (for example INC000009987-Technical), sends the creation request to Slack, stores the returned channel ID, auto-adds the selected members, and posts key incident details into the channel; duplicate channels of the same type for the same incident are prevented.​

Once a channel exists, users can open it in the tool to edit certain properties and work with live conversations. Channel Type and Tool Type become non-editable after the external channel ID is generated, but members can still be added or removed, comment sync rules can be adjusted (admin-controlled), the External user setting can be updated, and summarization actions are available.

The Conversation section shows messages from Slack in read-only mode with username, user ID, timestamp, and message text, and a Refresh button pulls the latest messages from the external system so the BigFix Service Management view stays up to date.​

Swarming channels support AI-powered summarization and flexible comment sync. Users can trigger summarization to see the entire channel conversation condensed into readable text, choose between different summary types (such as short or detailed), translate the summary if needed, and post it back as an incident comment.

A configurable Comment Sync section lets admins define whether Internal comments, External comments, both, or None are synced to Slack: if Internal is checked, internal comments sync; if External is checked, external comments sync; both checked syncs both; selecting None disables all sync and disables the other two options, with the rules applied both at channel creation and update time.​

BigFix Service Management supports multiple channels per incident (for example separate Technical, Business, and Leadership channels), each with its own membership, conversation history, summaries, and comment sync settings, and only channel types marked as company-specific in Foundation are offered to users. When members are added, Slack sends invitation emails automatically, and BigFix Service Management’s Notify option can send reminders via the Notification Engine to prompt users to join the channel. When the incident is closed in BigFix Service Management, D2C notifies Slack and all channels linked to that incident are archived, preventing unused channels from remaining active while preserving an end-to-end collaboration trail tied to the ticket.