We appreciate you taking the time to vote and add your suggestions to make our products awesome! Your request will be submitted to the community for review and inclusion into the backlog.
We recommend reviewing what is submitted before posting, in case your idea has already been submitted by another community member. If it has been submitted, vote for that existing feature request (by clicking the up arrow) to increase its opportunity of being added to Cireson solutions.
For more information around feature requests in the Cireson Community click here.
We recommend reviewing what is submitted before posting, in case your idea has already been submitted by another community member. If it has been submitted, vote for that existing feature request (by clicking the up arrow) to increase its opportunity of being added to Cireson solutions.
For more information around feature requests in the Cireson Community click here.
Options
(Potential) change conflict warning
Tom_Hendricks
Customer Super IT Monkey ✭✭✭✭✭
I am working on a custom solution for this, but would be absolutely thrilled if someone at Cireson suggests that I stop what I'm doing and wait for 6.0. 
We would like for the system to play more of a role in helping us determine when two (or more) changes are scheduled at the same time for the same CI, or when a prerequisite CI, will be impacted. Since that might be an acceptable scenario (e.g., we're bringing the system down anyway and users are aware), I do not want to prevent any action from being taken, but keep the requester informed. Even popping up a warning (perhaps in a different color) that a critical business service may be impacted by the change would be a worthwhile reminder to some folks.
The warning can drop from the top of the ticket, in a banner (similar to the way the save banner works, or the orange Related Articles banner) and contain links to the other CRs that open in another window.
The way I have described it, that requires relationships between CIs and services ("depends on" and "required by", for example). There may be other ways to approach this too. The core concept is that we want to provide warning to requesters when they are about to submit a conflicting change, and SCSM has enough information to be able to suggest that trying to patch servers might not work well when there is already a scheduled power outage for that building, for example. There are other ways to find this out, but this one saves a lot of time!.
We would like for the system to play more of a role in helping us determine when two (or more) changes are scheduled at the same time for the same CI, or when a prerequisite CI, will be impacted. Since that might be an acceptable scenario (e.g., we're bringing the system down anyway and users are aware), I do not want to prevent any action from being taken, but keep the requester informed. Even popping up a warning (perhaps in a different color) that a critical business service may be impacted by the change would be a worthwhile reminder to some folks.
The warning can drop from the top of the ticket, in a banner (similar to the way the save banner works, or the orange Related Articles banner) and contain links to the other CRs that open in another window.
The way I have described it, that requires relationships between CIs and services ("depends on" and "required by", for example). There may be other ways to approach this too. The core concept is that we want to provide warning to requesters when they are about to submit a conflicting change, and SCSM has enough information to be able to suggest that trying to patch servers might not work well when there is already a scheduled power outage for that building, for example. There are other ways to find this out, but this one saves a lot of time!.
5