IR Resolved - Action Log Entry Different

[ghost]

I'm not sure how the OOB exchange connector handles this; but I noticed that when the SMLets Exchange Connector resolves an incident it doesn't set the resolution category and description. It also creates an (Analyst Comment) entry in the action log rather than a (Record Resolved) entry in the action log.

My suggestion/request is to:

1. Use a variable to define a default resolution category and set the resolution category of the IR accordingly
2. Copy the comment text to the resolution description
3. Make the action log entry a (Record Resolved) entry

[AdhocAdam]

The OOB connector just sets the values as null, but in regards to the Analyst Comment over Record Resolved is something I'll have to look into. Genuinely did not think of/notice this behavior.

I do like the sound of all of this though as it would further increase the email based control of SCSM and help close some potential reporting holes.

[AdhocAdam]

In regards to leaving the Analyst Comment - the processing logic at play here are two switch statements. The first is a Comment based switch to determine what type of comment is left (End User/Analyst). The second is the one that actually does the Action based work (Take, Acknowledge, Resolve, etc.)

I'm still working this out, but I'm thinking the nature of this change will be nesting these switch statements thereby enabling an Action such as [take] and an appropriate Comment being Record Assigned in a single go. For example:

switch ($message.From)
{
    $affectedUserSMTP.TargetAddress {
        switch -Regex ($commentToAdd)
        {
            #actions go here
            default {}
        }
    }
    $assignedToSMTP.TargetAddress {
        switch -Regex ($commentToAdd)
        {
            #actions go here
            default {}
        }
    }
}

Once I can confirm this process flow with the new Action Log function from #62 I'll move onto the remainder of this request which is the picking of a Default Resolution Category and push to the current in development 1.4.4 branch.

[AdhocAdam]

The current in progress 1.4.4 branch now features the aforementioned switch logic and am continuing to test. Lot of analyst/end user actions to verify!

I've also decided to extend your request a bit as within the same vein as I thought it worth to address:

• Service Requests and their Implementation Results
• Problems and their Resolution Descriptions

If left blank, the connector continues to work as the stock one does in that it leaves null values for the Resolution Enums. If configured with an enum value, that will be used. In either case the final comment will be left on the Action Log as a Comment and in the respective Work Item's resolution/implementation description.

[AdhocAdam]

Forgot to add - this new approach with nested switches opens up an interesting possibility for limiting the actions that Analysts, End User, and a user who is neither could ultimately take against a Work Item.

I do not have have any plans to act on this, just throwing this out there as a possiblity.