Home› Service Manager Portal Feature Requests
We appreciate you taking the time to vote and add your suggestions to make our products awesome! Your request will be submitted to the community for review and inclusion into the backlog.

We recommend reviewing what is submitted before posting, in case your idea has already been submitted by another community member. If it has been submitted, vote for that existing feature request (by clicking the up arrow) to increase its opportunity of being added to Cireson solutions.

For more information around feature requests in the Cireson Community click here.

Handle data conflicts at save by letting users pick the "correct" value on their screen and continue

Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
in Service Manager Portal Feature Requests
I was surprised not to see this FR here already.  We are running into the dreaded Data Conflict error in the portal when an analyst is trying to close their newly opened ticket (i.e. an "open/close" ticket to log a straightforward request), but the workflow has changed the status in the background, and they are about to lose everything they typed due to no fault of their own.

This condition exists primarily because they have to save the ticket (which allows the workflows to start) in order to change the status.

Aaron Croasmun seems to have solved this in the console very elegantly, already: https://gallery.technet.microsoft.com/System-Center-Service-fca7af29

Can we get something similar to this for the portal, please?
14
Up Down
16 votes

Submitted · Last Updated

Comments

  • Davin_ClouthierDavin_Clouthier Customer Adept IT Monkey ✭✭
    Yeah we run into this heavily in our environment as well, one of our users biggest annoyances. Up voted!

  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    Thanks for supporting this.  I can now also confirm that it shows up (slightly less frequently) in the 2016 version as well.  The faster workflows are still no match for our analysts.
  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    *bump*

    In all seriousness, how does this not have 50 or 60 votes already?  Is it simply not encountered by very many people?  If that is the case, how is it being avoided, and/or how are your users accepting the fact that they lost everything they typed into the ticket?
  • Brian_WiestBrian_Wiest Customer Super IT Monkey ✭✭✭✭✭
    I trained all my analyst to not use the apply button. :) 
  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    @brian_wiest, unfortunately, that has no bearing on whether or not we see the problem.  Our analysts are trying to save new tickets while the initial workflows are still running, because they move very quickly on so-called Open/Close tickets (a.k.a. first-call resolution).

    This is a classic case of the tool wanting to change the process rather than the tool supporting the process. 
  • Adrian_PaechAdrian_Paech Customer Advanced IT Monkey ✭✭✭

    Hey Tom,

    We got around this issue "some what", by creating a "Resolved On First Contact" task which only appears when initially logging the call. This allows the analyst to resolve the incident / request as soon as they log it before they click apply. It also sets an extended Boolean value on the class called "isResolvedOnFirstContact" to true. Which we then use for reporting purposes.

    Agreed, this does not address the bigger issue though..


  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    Adrian, we ended up finding a workaround as well, but it has only reduced the problem (significantly), not eliminated it.  The majority of issues occurred when our phone switch integration app generated a ticket for an analyst, opened it for them, and let them fill out the rest of the fields.  To help reduce conflicts we altered our app so that it did not save/open the ticket but instead opened a new (unsaved) ticket and manipulated the fields in the other browser window.

    This has done nothing to solve when one analyst is on the phone about a ticket and another analyst is responding to an email about it, and both are trying to update it, for example.

    Some of my users have even asked if we can come up with a mechanism to lock the tickets while someone is working on them.  Many other systems do this, but of course it causes some problems of its own.  My users prefer those problems to this data conflict error that nukes their changes.

    I see this feature as the best solution, but locking the tickets as a close second. 
  • Brian_WiestBrian_Wiest Customer Super IT Monkey ✭✭✭✭✭
    @Tom_Hendricks What are you using for phone switch app? We have broadsoft and management would love this feature but I have had no luck setting it up.
  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    @Brian_Wiest the part I am actually referring to is a lightweight internally-developed web app, but the component that triggers it is a vended product.  I can PM the name.

    Our app presents the callers info and lets the analyst jot down key details like alternate contact info and Description, then lets them choose whether the ticket will be an Incident or Request, and they pick a template before creating the ticket.  All the other product does is open a URL and pass a limited selection of variables (caller display name, ANI#, etc.) into the querystrings.  We gave it the URL of this "middle" app of ours.
Sign In or Register to comment.