Options
Retaining related RO information after the RO has been deleted
Leigh_Kilday
Member Ninja IT Monkey ✭✭✭✭
If I have raised a SR and since deleted its RO, the relationship is also removed. From here there is no way to tell which RO spawned the SR. Has anybody got a solution for this? I had thought of persisting the Title of the RO in the SR somewhere, but then name changes have to be catered for.
This is biting us when a runbook corrupts a SR template and the RO needs to be recreated. We have active SRs without related RO data.
0
Best Answers
-
Options
Tony_Collett
Cireson Support Super IT Monkey ✭✭✭✭✭
When any object in SCSM (Request Offering, Software Asset, User, you name it) is deleted, relationships are also deleted. This is simply how it is.
A suggestion could be to use a Runbook to add information about the request offering in to the description or into a custom field in the Service Request.
I would also recommend looking into the Runbooks that are 'corrupting' your SRs, this doesn't sound very healthy for the system in the long term.
Regards, Tony5 -
OptionsTony_Collett
Cireson Support Super IT Monkey ✭✭✭✭✭
If you have a development environment, you can easily avoid 'Invalid' runbooks by using the Coretech Runbook Transfer Tool. It allows you to copy a template (which has a Runbook) from one environment to another seamlessly: http://blog.coretech.dk/jgs/scsm-sco-management-pack-transfer-tool-beta-3-freeware/
One practice that I did when I was at my previous company was that when I was creating a Runbook with custom prompts (using Initiate Data implementation activity) was that I always added 1 or 2 extra 'string' fields which had the label Text1 and Text2. This would allow me to add any extra data that the Runbook might have required later on down the track.
Another idea would be to use the Initiate Data activity to only grab the SRID (or RBID) and then use that to retrieve any extra information that was added to the form.1
Answers
A suggestion could be to use a Runbook to add information about the request offering in to the description or into a custom field in the Service Request.
I would also recommend looking into the Runbooks that are 'corrupting' your SRs, this doesn't sound very healthy for the system in the long term.
Regards, Tony
One practice that I did when I was at my previous company was that when I was creating a Runbook with custom prompts (using Initiate Data implementation activity) was that I always added 1 or 2 extra 'string' fields which had the label Text1 and Text2. This would allow me to add any extra data that the Runbook might have required later on down the track.
Another idea would be to use the Initiate Data activity to only grab the SRID (or RBID) and then use that to retrieve any extra information that was added to the form.
Unfortunately we do not own Orchestrator here so another instance for QA is just another item on the other team's backlog. At present we are configuring templates, ROs and runbooks in Production because we'd effectively have to reconfigure, rendering testing in QA useless. This is causing us no end of trouble.
For anybody else reading this, take note of this lesson learnt!
I am surprised that this was not catered for OOTB. Is this also a problem with SCSM / SMA?