locked
Exchange Connector 3.0 RTM - Wrong action log type (user comments are sometimes analyst comments) RRS feed

  • Question

  • Hi,

    We started using Service Manager a few days ago and I'm noticing some strange behavior from the Exchange connector. Sometimes when a user replies to an e-mail, it get's added as an "Analyst comment", also the private checkbox has a dot in it (not blank or checked, but a dot..)

    In this screenshot user "Marwan" is a regular user, replying to us via email...

    Any ideas?

    Wednesday, June 26, 2013 7:37 AM

Answers

  • I believe this is a known issue, the Exchange Connector will continue to process comments as "IsPrivate" with the Null value until fixed. This will hopefully be a configurable feature in future updates.

    • Proposed as answer by Alexey G Friday, August 23, 2013 11:29 AM
    • Marked as answer by Kenneth Sundby Friday, August 23, 2013 11:37 AM
    Wednesday, June 26, 2013 1:14 PM

All replies

  • I believe this is a known issue, the Exchange Connector will continue to process comments as "IsPrivate" with the Null value until fixed. This will hopefully be a configurable feature in future updates.

    • Proposed as answer by Alexey G Friday, August 23, 2013 11:29 AM
    • Marked as answer by Kenneth Sundby Friday, August 23, 2013 11:37 AM
    Wednesday, June 26, 2013 1:14 PM
  • I believe this is a known issue, the Exchange Connector will continue to process comments as "IsPrivate" with the Null value until fixed. This will hopefully be a configurable feature in future updates.


    OK, but the private-mark is more of an oddity rather than a concern. Marking them as "Analyst comments" breaks many workflows (subscriptions, reopening resolved cases etc.)...
    Wednesday, June 26, 2013 1:20 PM
  • OK, but the private-mark is more of an oddity rather than a concern. Marking them as "Analyst comments" breaks many workflows (subscriptions, reopening resolved cases etc.)...


    It's a large annoyance and a problem that must be fixed, but I don't believe there is a known solution or work-around for this yet.
    Wednesday, June 26, 2013 1:32 PM
  • Just wanted to bump this old post. Has anyone found a workaround to this? Or figured out the exact pattern.

    It seems that all updates to an Incident is treated as an Analyst comment UNLESS it's from the Affected User. That's pretty bad, because it implies that people on cc replying to the [IRxxx] mail, will come in as an analyst comment, which means it could be lost as the incident does not change status to Active again! (or a custom 'Updated by User' status). 

    It should be: all updates will default be set to a user comment, unless it's from the assigned to user (or something more clever that looks on the user roles).  

    My idea for a workaround, that could get ugly performancewise, is to make a custom workflow that deletes the analyst relationshipobject and add's it again as a user comment if the WrittenBy and AssignedTo does not match... but not that's a workaround with a capital W :)

    Friday, February 28, 2014 3:59 PM
  • I'm having the same issue.  The comments work fine for Analyst or End-User however the Private box always contains a box.  This does not allow the action log to appear on the Server Manager Self-Service Portal.

    Any help would be greatly appreciated.

    Thanks


    Brandon Hines

    Friday, April 11, 2014 4:59 PM
  • in regards to the null check-box, set up a workflow that triggers on the creation of an analyst comment that sets the flag to false. You can do this with a console workflow and a template. consider http://blogs.technet.com/b/antoni/archive/2013/03/22/sending-out-the-most-recent-analyst-comment-from-the-action-log-in-service-manager-2012.aspx for examples on how to create these objects.  

    as for the other thing: I hate to be "that guy", but i'm going to throw this out here anyways:

    How would you suggest the exchange connector determine if a third party is an analyst or a user?

    that's not a flippant question, i'm actually asking you to develop a deterministic algorithm that can decide if a given user who is neither the assigned analyst nor the affected user, is an analyst or is a user in the context of that incident so the comments can be marked correctly. I suspect you'll find it FAR harder to determine then it seems. the exchange connector simply didn't address it, marking everything as an analyst comment in the absence of better intelligence. 

    Friday, April 11, 2014 5:48 PM
  • Today there already is intelligence that checks if the recipient == affected user. I am merely suggesting to rewise and/or extend this logic

    As I wrote, I see two possible ways here. The easy and the hard (optimal) way. The easy way would be to turn it around, meaning all comments = End-User comments unless it's coming from the Assigned User. So the check would be on the Assigned User instead of the Affected User as it is today. I understand that some people might complain about this, and might have adapted to the current solution, so it should be optional. In my experience I just see this as more suitable for the customers needs. Well if the source code could be released it would make it easier to make custom adjustments, e.g. change the Private boolean value to false etc. ;)

    The hard optimal way would be to add more options for deciding when it's an Analyst and when it's an End-User. Of course the Exchange connector can't figure that out, but if it did comparison to preselected groups or perhaps User Roles (e.g. if recipient is Incident Resolver and not affected user => analyst comment). 

    In any case it's an interesting discussion with many aspects, but one thing is for certain: the exchange connector is unfinished. Not broken, just lacking options. Today people are making alot of custom workflows and even their own connectors to accommodate for these issues. 

    Friday, April 11, 2014 10:11 PM
  • There are a lot of good solutions to that problem, but none of them are the clear correct solution suitable for all corporations in all use cases.

    I give Microsoft a LOT of flak for poor defaults and incomplete solutions, but i think this is a case where they are better off allowing people who really care about it to do orchestrator/workflow/custom code things (reference: contributors on this message board) and creating a minimal solution that fits the remaining use cases most of the time. 

    I have not yet had to change the behavior of the exchange connector for any of my implementations, so that right there suggest that this solution is good enough for most people most of the time, and the implementers who are passionate about alternatives will create them. 

    The exchange connector isn't incomplete; it's certainly minimal, but it's Microsoft. in other news: water wet, sky blue.  

    Monday, April 14, 2014 5:31 PM
  • Has anyone found a resolution for this?
    Friday, June 10, 2016 11:16 AM
  • Hi Karl

    It's a been a while since your comment but I'm actually investigating a issue like this one now and came over this Forum posting. In my case I did conclude that the issue is inconsequential in the sense that I could not reproduce the Issue with my own account (End User account). My own emails turned into End User Comments as they should. I focused on a particular example that the customer gave me and It turned out that the Affected User object (config item) was duplicated. One object was already marked as "Pending delete" and one was Active. I am deleting both of them and syncing the AD Connector again. Hoping that fixes the issue but remains to see. Will try to post again when I have the answer.

    Wednesday, November 9, 2016 8:27 PM
  • Any updates on what might have been causing this issue and possible fixes?
    Saturday, March 23, 2019 6:12 PM