Jump to content

Summary over 250 characters prevents summary or description from populating in the call details


AlexOnTheHill

Recommended Posts

Hello,

We have noticed some of the calls logged by users are not populating any call details and this is due to summaries over 250 characters.

I understand that the maximum length is 250 characters so have implemented a regex to prevent long summaries from causing this problem.

Given the limitations of 250 characters would it also be possible to put a character limit on the summary field?

Also, if the summary is over 250 characters why does the description also fail to populate from the progressive capture, even if the description is just one word?

I would add that this problem only happens when the summary exceeds the 250 character limit, 250 characters or less do not cause the problem.

Link to comment
Share on other sites

2 hours ago, AlexOnTheHill said:

Given the limitations of 250 characters would it also be possible to put a character limit on the summary field

Where you would need this exactly? As far as I know this can be implemented (as you also did) via REGEX restrictions.

2 hours ago, AlexOnTheHill said:

if the summary is over 250 characters why does the description also fail to populate from the progressive capture, even if the description is just one word?

Because the request data is updated/inserted in one go. If it fails (for whatever reason, one being the summary exceeding allowed size), then the whole request update/insert fails.

Link to comment
Share on other sites

Thank you for coming back to me

It feels more like the regex is working around a problem rather than the answer to it.

Nothing in the definition of the progressive capture or the business process warns that the population of the details from the progressive capture will fail under these conditions.

Would it be possible to arrange it so that rather than populating no details at all it populates with truncated details?

Link to comment
Share on other sites

1 minute ago, AlexOnTheHill said:

It feels more like the regex is working around a problem rather than the answer to it.

I understand why it can appear as such when PCF engine is looked at solely from a SM (Service Manager app) perspective. However, the PCF is a functionality that is available for any app to use as such it requires a degree a flexibility. Imposing a hard coded restriction such as the one you mention will reduce this flexibility. I am not saying nothing can be done, it certainly can be done, but not with current engine. And having a new (redesigned) one is not something that will happen quickly (if).

3 minutes ago, AlexOnTheHill said:

Would it be possible to arrange it so that rather than populating no details at all it populates with truncated details?

That's something for @James Ainsworth to consider as a change in functionality.

Link to comment
Share on other sites

  • 1 month later...

Glad to have found this - we keep having the same when users paste too much text into the summary or into a field that we are using in the summary and it stops the ticket from logging correctly.

So would be really pleased to see it truncate the text instead

Helen 

 

Link to comment
Share on other sites

@James Ainsworth

Is the fix in for Changes too - doesn't happen often but just have one (raised 26th March) where the BPM failed as the user added 279 characters into the summary. The error message states it should be under 275.

Nasim

 

Link to comment
Share on other sites

Hi Nasim,

The fix mentioned above was done for the request table which is used by all request types.  However, there has been another issue reported where this was happening during an update to the request.  This too has a fix, and this will be available in the next Service Manager update.  

Regards,

James

Link to comment
Share on other sites

Hi Jeremy,

The fix that has been already released was to truncate the summary when raising a new ticket.  Previously, if the summary was over 250 characters, the ticket would be raised, but the summary would be blank. For example if you had a custom progressive capture form for capturing the summary, and this field was mapped directly to the request summary, and someone entered more than 250 characters the issue would occur. 

The next fix is looking at updates to an existing ticket using the BPM.  If you update the summary of an existing ticket with more than 250 characters as part of a BPM Automation the issue will occur.  For example, you have a custom progressive capture form that captures the summary, and then after the ticket is raised, you use the BPM to update the summary with the progressive capture answer that contains more than 250 characters. 

I hope that helps. Let us know if what you are experiencing is different than either of these two scenarios. 

Link to comment
Share on other sites

@James Ainsworth so we are seeing this with requests raised via the self-service portal. I forgot to limit the field to 250 characters and it submits the request but then breaks down and you need to into that BPM to fix the Summary field.

I can easily add some regex, but wanted to let you know that this happens in this scenario.

Link to comment
Share on other sites

Hi @James Ainsworth

In our case the change was submitted with 279 character but it didn't get truncated, I tried to update it to reduce it to under 275 but without being able to open the active Workflow in the UI I wasn't able to restart that BPM.

I did raise a support request if you want to review the details (IN00166795).

Nasim

Link to comment
Share on other sites

Hi Jeremy and Nasim,

Thanks for your feedback.

As the default Request Details Progressive Capture form already prevents the user from entering over 250 characters, I'm assuming that you are doing one of the following as described in my previous post.

  1. Using a custom progressive capture form to get the summary information and this is mapped directly to summary field on the new request
  2. Using a custom progressive capture form to get the summary information and then using the BPM to update the summary after the request has been logged

Scenario 1 should already be fixed.  Scenario 2 the fix will be in the next update.  Can you confirm which of these two methods you are using and which one you are still seeing an issue with.

Thanks.

James

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...