Jump to content

Create Linked Request ignores what I put in Summary and Description when logging


Berto2002

Recommended Posts

I wasn't around when the system was implemented so not sure how the exact set-up works for the UI interface option to Create New Linked Request. My belief is that we set the SM application setting of "app.requests.defaultBPMProcess.incident" which determines the BPM used in this cases but I cannot see where the IC form is specified...

I get presented with the box to enter summary and description and it's pre-populated with the details from the original Request (yellow) so I add-in/alter the Summary and Description, in this case just adding a server name (obscured).

image.png.2cd951da47aeeaf49a31948c6c653e53.png

And yet when the Request is logged, the new information is 'lost' and all I have is exactly the same Summary and Description as the original record.

One of the first nodes in our General Incident process sets the Summary as this: &[global["flowcoderefs"]["getServiceInformation"]["customB"]] Issue: &[global["flowcoderefs"]["getReqInformation"]["summary"]]

This is designed to add the 'prefix' from the Service to the Summary.

The issue appears to be that the &[global["flowcoderefs"]["getReqInformation"]["summary"]] is putting the Summary from the originating Incident into the Summary on the new Incident rather than using the Summary from the IC form that I edited for the new Incident.

image.png.f390bc61e941700d78070dd893c883bb.png

Have I got the wrong or have I uncovered a defect?

Link to comment
Share on other sites

I had this problem, I take it you aren't using the default request details forms in your intelligent captures and are instead using custom fields, for some reason the behaviour is weird unless you use the built in form when raising a new linked request, I did this report this and I believe they accepted it as a defect

Link to comment
Share on other sites

@Jim I also thought along these lines and believe we've had similar issues when emails were coming-in but these were resolved by ensuring one uses the Form ID of "customformdefaults" if replacing the usual form; and indeed we have this in place for the "General Incident" IC form we are using. My assumption is then that this Form ID should mean the IC aspect performs as it should.

image.thumb.png.2a5a6168a32d01852bb3d8390b7af092.png

I would be interested to hear from HB about this. It's pretty important that we can create a linked Request and input a new/revised/meaningful summary and description!

Link to comment
Share on other sites

This is being progressed under defect reference KE00176985 however we are not able to provide a timescale as the fix will be in multiple stages and each of those will have its own fix/test/release cycle.

The workaround is to use the Standard Form for Summary/Description rather than mapping these fields from a Custom Form.

Link to comment
Share on other sites

@Steve Giller for any given service, how does the system select what IC form it uses? In short, how do I make sure we use the standard form; where do I specify this?

1) does it use the same form as the original incident being 'copied'?

2) does it somehow 'lookup a form from the Service? how?

3) does it use these SM app settings?

image.thumb.png.582fce7d49b562cc615fb6aecd0b7d60.png

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...