I have done something very similar. I have a web site that accepts firewall requests. It sends an e-mail to LPM and LPM creates an incident AND a firewall form within the incident and populates all attributes for me. I now have an incident that goes between network, security, network etc etc until everyone is happy. Then I have an action called "Transform to Change" (I thought the process sounded more interesting using the work transform). Below is my process:
Selecting the action causes a "Create Change" but a "Create Incident" should also work. I then auto resolve the incident and move on. Double clicking the "Create Change" opens a Change Window or in your case an Incident Window and you can fill in the values using attributes from the Problem. I then resolve my incident (Problem in your case) with some nicely worded text describes what happened. In both the Incident and change (Problem/Incident) you will see a collection of the other object. So for me, my Incident shows the Change and in the Change I see the Incident. You don't have to resolve the incident (Problem for you) but I like things clean. I end up with an Incident and a Change and their linked.
In my incident's "Open" control in process designer I had to add "Create Change" and in my Change I had to add "Create Incident". I can't see it now but I thought somewhere I had to add a Create Change Child and Create Incident Child. It's been about 2 years and I just don't remember that detail, maybe it's not required. Overall, it wasn't nearly as bad as I would have expected and ended up being pretty easy. I am assuming that this is possible between any two objects, never tested it so no guarantees.
Is there a way of auto-populating some of the fields in the Incident being created, then displaying the Window so the Analsyst can review, amend and add further details as required?
I'm also struggling to work out how the Incident is linked to the Problem via the IncidentProblem object. Can this be done automatically?
I'd appreciate any thoughts folks have.
"Is there a way of auto-populating some of the fields in the Incident being created"
Yes, you can populate anything you see in the screen. Double click on the "Create Incident" control and the incident Window comes up. At that point you can type in values or right click and use values from the Problem. It's very much like a template. In my case I selected some values from the incident to put in the Change and in the description I used a calculated to strings a bunch of values together. It's really easy.
"then displaying the Window so the Analsyst can review, amend and add further details as required?"
I don't know how to do that. The incident is linked and can be opened and reviewed but I don't know how to automatically open it for review.
"I'm also struggling to work out how the Incident is linked to the Problem via the IncidentProblem object. Can this be done automatically?"
You should have an Incident and a Problem object. In my Change object, I see a collection of Incidents so I would guess your Incident needs a collection of Problems.
@csimpson thanks for your help. I'll give it another go and if I get the auto-open for review sorted I'll post it on this thread.
I appreciate the time you spent on this.
Martyn originally helped me get this to work. If I remember right the secret and only hard part was knowing to add the actions to the open controls in your process. By adding "Create Incident" in the "Open" control of Problem (in your case), it seems to open the ability to create an incident anywhere in the process.
I'm looking for a way to do this too. The critical part is allowing the analyst to edit the copied content before saving the new incident. Ideally the analyst clicks 'Create Incident'; the Problem title/desc are copied to the new incident window; the analyst has a chance to edit the raise user, category, and anything else they want; then finally they save the incident. Since it seems like there is a limitation with the product that does not allow placeholders being used with a manual action, this ultimately fails to work. I've tried copy rules and those also fail.
You can create a new collection on Problem. 'Incident Creation'
Use the Object Creation wizard and it will already have a Title and Description.
Then add the attributes required for Incident to the new collection object. including a relationship from User for Raise User, Incident Category, Incident Impact/Urgency Etc.
On the Collection window, add all the attributes, including the Problem attribute (this can be hidden using Show on Window = False)
Create CopyRules to copy Problem Title and Description to the collection title and description. Make them Always Execute = True and Do Not Overwrite.
make Raise User the first thing they select and set Copy Related = True.
When they select Raise User, it will trigger the 'Always Execute' copy rules for Title and Description from Problem.
You could also use a dynamic window calculation that only shows title and description once Raise User is selected. So people are not tempted to populate them before copying from Problem.
Put the action for the collection into your process followed by automatic Create Incident (the standard Create Incident action on the Problem domain)
In the window, set values using value types from the Problem Collection object.
And what if we have literally hundreds of custom fields for Incident that are managed by dynamic window calcs? The person creating the Incident will not see that they need to fill in this information unless we duplicate hundreds of hours of work by adding it all to this new object window (not to mention constantly maintain that every time we update the incident windows and fields). I appreciate the reply but the way this product is designed makes that so impractical that it's essentially impossible to use.
Ok. I wasn't aware that in your case the Incident window was so complicated.
So what you can do here is create a new relationship dragging from Problem to Incident. Select Yes to create a collection. Then you will have a new 'Incident Collection' on Problem. Give this a new action name.
Add this action as an optional action to your Problem process.
Without making any more changes, when you choose the action, the Incident window will appear and work as expected. However you need a few more things to get it working the way you want.
Your Incident object will now have a 'Problem' attribute. Like any other collection.
Add this attribute to the Incident window (again Show on Window = False) and create the copy rules from Problem.Title into Title and Problem.Description into Description as Always Execute = True. As described above.
Now when they click the action to create the Incident and select Raise User for example it will copy the Problem data into the Incident window.
You don't have to use Raise User as the trigger for the copying of Problem data. You can use any drop down list.
The rest of the incident window should behave exactly as it does now. The incident is created.
The only draw back of this method is that the Incident is in the new 'Incident' collection rather than the standard IncidentProblems collection created by the OOTB Add Incident or Create Incident actions.
Interesting. If I have time I will give it a shot and see how it works. I don't quite like the idea of it being added to a separate collection because this creates an inconsistency with where the related incidents are displayed since we're still going to have the ability to 'attach existing problem' from the incident. I'm not sure it's worth the hassle and issues with reporting that will result from it.
Not a perfect solution but I appreciate the attempt
Yes I understand your uncertainty over how it will affect reporting etc. I guess its a case of weighing up what is more important. The ease of creating Incidents from Problems or reporting what incidents are attached to which problems.
You could I guess, modify your Incident process so that when there is an Add Problem action taken (place this is process) you follow it with an automatic action which sets the new 'Problem' attribute created by the new collection described above. Then you can use just one collection for your reporting. The action will then be invoked when you add Incident or Create Incident from Problem.
I just realised that I missed a bit from the instructions. This is required in order to get the data copied form Problem into the Collection or Incident.
You still set up the copy rules as explained above.
However, you do need to do one more thing to get the data to copy.
Whichever drop down you are using (in my example it was Raise User), you have to create another Copy Rule (into a hidden string attribute) to copy something from the drop down object.
So I have done RaiseUser/Title into a hidden string field for this.
If you don't copy data from the drop down, it will not copy data from the Problem.