Resolution Text not picked up

[Steve Giller]

As you can see from the attached, I have set the resolution node to put custom text into the timeline. This part works fine, but does not affect the resolution text, and therefore we get a very unpleasant, bland email going to the customer.

Can I have the resolution node timeline text as the actual resolution text, and if so ... how do I achieve this?

[Steve Giller]

Also - I have text in Custom_B if one team resolved the issue, but in Custom_C if another team did.

The 'logical' thing to push into the final field is [Custom_B][Custom_C] - however within the BPM this comes up as undefinedCustom_C or Custom_BUndefined.

Is there, without resorting to a decision node, a way to have an empty string appear as just that, rather than the ugly "undefined" placeholder?

[Steve Giller]

The team this is affecting are about to go live - and with the resolution text showing as "The request has been resolved by the Business Process Engine" this is what appears in the call closed email, something they're not too happy about.

Has anyone got a fix or at least a workaround for this?

[Guest]

Hi @DeadMeatGF

Could you use the "Update Request -> Resolution Text" node, AFTER the request has been resolved but BEFORE the email is sent to the customer. I'm thinking this would override whatever text appears in the Resolution by default and you could simply match the text/expression in here to that of which you are including in your timeline update. 

 

Would that work for you? Let me know if I have misunderstood the issue here!

Kind Regards

Bob

[Steve Giller]

Testing! ... brb

[Steve Giller]

That appears to have worked, thanks @Bob Dickinson

[Guest]

Good news @DeadMeatGF

In regards to the other issue you mentioned on the thread, I'll ask our developers internally whether we could display a null value rather than the word "undefined" - and perhaps in the future we could have some functionality similar to that of the ESP conditions in the email templates to make a decision on what should be displayed based on a defined rule. 

In the meantime though, a decision node is the way to go. 

Kind Regards

Bob

[Steve Giller]

Thanks again - that second fix is now in place too.

[Steve Giller]

I'm fairly convinced I'm doing something wrong, as my brain is fried from building this rather large process, but I can't get the Update Resolution Text node to append.

I have a number of Automated Tasks set up in a Parallel Processing section, but whether I have selected 1, 2, or 12 actions I end up with a single line in the Resolution Text at the end of the Process.

I've tried setting "Overwrite Resolution Text" to Yes, No and leaving it on Auto - all with the same result.

[Dan Munns]

@DeadMeatGF Could you not stick all of the actions into a custom field (which has an 'Append Text' option) and then at the end of the process update your resolution text with a variable pointing at the custom field (or now at least) 

[Steve Giller]

Certainly can - was flagging this here as it doesn't look like expected behaviour based on the available options.
I'll go with the custom field unless (until?) I hear otherwise.

 

[Dan Munns]

2 hours ago, DeadMeatGF said:

I'm fairly convinced I'm doing something wrong...

Doesn't look like it though. I just wondered if you had fallen foul of the same thing I sometimes do where I get too focused on trying to make something work the way I think it should rather than looking at other ways to do it. 

At least you can work around it for now  

[Steve Giller]

Ah - crlf, that's the issue with the custom fields.
I may have seen that somewhere, but while I'm searching feel free to drop a method to add a crlf onto the end of the text I'm appending, see if you can beat me to it!

[Dan Munns]

@DeadMeatGF will this help? 

Untested by me in the custom fields though....

[Steve Giller]

Nope, sadly not.

The only potential for forcing a new line was to use headings as standard Wiki markup uses an actual new line (i.e. Enter on the keyboard) as a new line, as you would expect, but the markup comes through as typed.

I tried the \r\n version as well, to no avail.

[Dan Munns]

I think we need the same changes to the custom fields as we had to the description field....

@Steven Boardman / @Victor can this be raised as an enhancement please?  

[Steve Giller]

This may come in with the next update along with unlimited size custom text fields?

[Steve Giller]

So this is OK as a workaround - but the 255 character limit and being forced to have everything on a single line (unless using a variable that is already split over multiple lines) makes it less effective than I'd like.

[Steven Boardman]

@Dan Munns @DeadMeatGF sorry for delay getting back to this post, it may be a little late so sorry if i have missed the action here but would i be right in saying what you are looking for in the Update Request > Resolution Text option is an Append Text option like in the Update Request > Details shown below?

I'll ask the question anyway but if you could confirm or let me know what was really needed if i have misunderstood that would be great   

[Steven Boardman]

OK scrub the above i think i get this now, two things:

1. Are we saying the overwrite resolution text is not working as expected? 

2. As a workaround you were adding all the values into a custom field using the append option there, but as these are not allowing a multi-line selector input you could not format the custom field value which you then passed to the resolution text?

So in the next update there are additional custom fields and some are designated as text type so i'll ask if it is possible to see if these can expose a multi-line editor.

 

[Steve Giller]

@Steven Boardman Yes, that's correct.
1. Setting the Overwrite Resolution Text to Manual::No resulted in only one value being populated.
The actions were being done in parallel, so I can't be certain that only the last one survived, but I believe that was the case. The only other logical options is that the first one survived and nothing was appended.
2. Yes, quite correct. Compounded by the fact that although I employed a workaround of presenting the information as a semi-colon separated list, which looked fine, one of the inputs was a variable from the ProCap form that was split over multiple lines and broke the illusion that it was supposed to look like that!

The custom text fields will sort out the workaround, but if the Resolution text can be appended that would be even better.

[Dan Munns]

@DeadMeatGF maybe it is something to do with them being parallel actions. 

Are the outcomes from human tasks? If so you could do an update request resolution node after the parallel actions and use the variable picker to populate the outcomes straight into the resolution all together? 

[Steve Giller]

I probably could, but the reservation I have with that is that the process is for requesting access to additional Services after the New Starter process has completed and granted the default set.

There are quite a few services.

When this set of optional services changes, which it does regularly, the over head on maintenance and the risk of human error is much higher if the editor is looking in one node at a jumble of Task result variables (which you'll admit are quite ugly things!) compared to deleting a full chain within the PP or adding a copy of an existing one and altering the nodes to the new values, which is immediately visible in the UI.

[Steven Boardman]

@DeadMeatGF @Dan Munns

Just an update here, we are introducing additional custom fields in the next Service Manager update (due out shortly) and in that certain new custom fields have defined types (Text, Datetime, Integer) for the New Text custom fields we have enabled the multi-line editor in the update custom fields option.

This was added today so won't make the next service manager update but will be in the one after that.

I've asked my colleagues to comment on the resolution text append issue

[Dan Munns]

@DeadMeatGF I guess I would need to see your BPM to understand it fully.

I do something similar in the description of a call raised from another for our new starters.

The description text reads: 

Create the relevant accounts for the following user:

New Starter Name: &[functions.pcf("StarterDetails","StarterName")]
Start Date: &[functions.pcf("StarterDetails","startdate")]
Department: &[functions.pcf("StarterDetails","Department")]

Systems Access: &[functions.pcf("Access_Equipment","Systems_Access")]
System 2 Access (if required): &[functions.pcf("System_Access_Details","System2_Acc")]
System 3 Access (if required): &[functions.pcf("System_Access_Details","System3_Agent_Type")] / &[functions.pcf("System_Access_Details","System3_Licence_Type")] 

Looks ok in our tickets. If the field is blank then it just shows as blank rather than 'undefined' (Systems Access is a mandatory field where as the other two aren't). I suppose it will depend on what the text on the human task reads for Completed though. If you changed the text to something like 'Access to Service Manager granted' then that is what the variable would pick up. 

May be a work around until the improved custom fields?