At a basic level, Collision detection is actually enabled by associating your affected CIs with your Change Requests. Collision detection compares Change Requests with common CIs to see if there are multiple CRs changing the same CI at the same time. Look at the documentation about the Association types to see which fits what you want to do.
If you want to go deeper and include it as part of your approval process, here are three basic things you can do: 1) Set up your CIs to have unavailability segments, so that outage periods requested can be vetted by the approvers. This isn't technically required to allow collisions to be detected, but it makes it easier to determine which should be allowed as being part of a pre-defined outage period for that CI, and to also see dependencies of other affected CIs. 2) Define groups as owners of the CIs. I would not define this down to individual users, because of the overhead of maintaining the CI/people relationships. Instead, use groups, and move people in and out as necessary. This helps define responsible owners of a CI, and can help you further define business level approvers. 3) Using the data defined in step 2, set up the Approval Mappings on one of your approval gates (probably a Business level one) to be CI based. This can take some work, depending on whether you go by CI class or (not recommended) CI-level Approvals. Rick On Mon, Dec 10, 2012 at 12:42 PM, Mancinelli, Rossella < [email protected]> wrote: > ** > > I was wondering if someone could steer me in the right direction to get a > little background**** > > info. on how/where to configure the collision detection tool for Change > Mgt. We’re using ARS 7.6 **** > > Remedy on Demand.**** > > ** ** > > Thanks in advance.**** > > ** ** > > Regards,**** > > * * > > *Rose Mancinelli*,* *ITIL* **|** *IT Service Governance (ITSG) - Change > Management *|* 3200 Highland Avenue, Downers Grove, IL 60515 *|** *W: > 630-737-3421 *|** *[email protected] *|***** > > ** ** > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Roger J > *Sent:* Monday, December 10, 2012 11:50 AM > *To:* [email protected] > *Subject:* Re: NOT merging a new record into BMC.Asset**** > > ** ** > > ** **** > > Do not allow Auto Identification on the dataset to be merged.**** > > ---- Original Message ---- > From: Joe <[email protected]> > To: arslist <[email protected]> > Sent: Mon, Dec 10, 2012 12:47 pm > Subject: NOT merging a new record into BMC.Asset**** > > Hi all,**** > > ** ** > > Our scenario:**** > > ** ** > > Bringing in an external spreadsheet of 5 fields. Once brought into the > staged **** > > dataset via AIE the records are normalized and reconciled into the BMC.Asset > **** > > Dataset. We are utilizing Name to identify on in ComputerSystem. **** > > ** ** > > Issue: Because this spreadsheet is completely human entered and not an > export **** > > from any system there is a chance of human error. We would like to ensure > that **** > > if a Name is incorrectly input into the spreadsheet it is not reconciled into > **** > > the CMDB.**** > > ** ** > > Question: How to I exclude a record from reconciliation into BMC.ASSET if it > **** > > DOES NOT currently exist (from the staged dataset). **** > > ** ** > > Thank you, have a great day.**** > > ** ** > > _______________________________________________________________________________**** > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org**** > > "Where the Answers Are, and have been for 20 years"**** > > _ARSlist: "Where the Answers Are" and have been for 20 years_**** > > Email Confidentiality Notice: The information contained in this > transmission is confidential, proprietary or privileged and may be subject > to protection under the law, including the Health Insurance Portability and > Accountability Act (HIPAA). The message is intended for the sole use of the > individual or entity to whom it is addressed. If you are not the intended > recipient, you are notified that any use, distribution or copying of the > message is strictly prohibited and may subject you to criminal or civil > penalties. If you received this transmission in error, please contact the > sender immediately by replying to this email and delete the material from > any computer. _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
