QEHNick

Fantastic! Just what I need. Thank you @will.good & @Steve Giller

Is there any way to show change requests in the "My Requests" widget of the portal? Several customers have asked to be able to see the progress of their changes in this way.

I've got a lot of team members who have a strange mentality regarding call ownership. They feel if they assign the call to themselves, they have to do the job. Strangely, they'll update it, send the customer messages, lots of interaction with it but never assign it to themselves until they are ready to close it. Essentially "owning it"; I know, right? What I'd like to do is force the call to be assigned to the person who initially updates it. It can be reassigned thereafter, but that initial touch would make them the owner. Or, not allow the call to be updated unless an owner was assigned. Any thoughts on that?

Very odd this @James Ainsworth . I haven't done anything except put it back to how it was (added variables) and it is now both updating the timeline and resolution correctly. I'll put it down to hot weather.

@Victor Cheers m'dear.

Thanks @James Ainsworth. I am performing the usual "gets" so It's hard for me to understand why this does work in a standard BMP and not in an auto task. I enclose the definition file for reference. quick-resolve-for-ad-account-incidents.version-3.bpm.txt

@James Ainsworth, yes, you were right, removing the variables was successful. Does this mean there's a bug preventing the desired result or is this a limitation of Auto Tasks?

Thanks for the input @James Ainsworth. It's a small, linear process; get information, update resolution text, resolve, close. I'll take the variables out and see if it works then.

I have an auto task, of which, a component is set to update the resolution with some variables from the request and customer. Despite the update settings below, neither the resolution text or timeline get updated. Has anyone else experienced this?

@Steve Giller \o/ || \ \ ______ Cheers!

Here's our definition file if you want to try it out. faq-views.report.txt

Yes, all but the missing Service ID fields.

That sounds a reasonable theory, however, in practice the report is generated in a second or two.

I'm running a report on FAQs and I'm keen to view the service they are allocated to (as you know, it's very hard to track them down). However, the report refuses to produce the value in the Service ID field; niether "h_itsm_faqs.h_service_name" nor "h_itsm_faqs_h_service_id" will produce any value. Indeed, even attempting a "Data Preview" will have it's wheels spinning. Outputting the report to a file simply does not include the Services data, everything else is there though. is this a known issue?

Thanks Nanette. We use single sign-on so how could that be the case here? Is there a log file which records this sort of activity?

On a few occasions we have had (basic) user accounts go into a "suspended" state. Is there any way I can determine why this is happening as there doesn't seem to be any external reason as to why this happens.

Ah, that's a shame @Sam P. In my scenario, I'd like to be able to grab any call regardless of what team it lies with. I can see it has some merit though. I'll whip up something and see if it works for me.

Wouldn't this be better achieved using a custom view?

This doesn't appear to work, the variable is not selectable and when typed in manually, results in this error.

+1

Ok, one of the tech teams discovered the what was required here. A permission was required to be set on the Azure platform for the account we are sending from in order for it to be able to authenticate the connection. Is this something you can put in your documentation for future?

I've been creating a process to send a MS teams message to the customer upon resolution of a request. I've had some issues, most of which I've overcome through trial and error, however, there is one glaring issue which I cannot get my head around. When the Teams message is sent, instead of it going from the account it should, it is sent from the colleague who authorised the connector in KeySafe. Oddly I don't recall there being a part to say which account the message should originate from. Is this a known issue or am I doing something wrong? The description for the connector reads... "This operation will create a private Teams chat between the authenticated user and another Teams user. If a one to one chat already exists, the Chat ID of the existing chat will be returned." So, what is the "authenticated user" at this stage? In testing it would appear that this is the account used to establish the Keysafe credentials when authenticating with Microsoft. It's impractical to assign administrative permissions to an account which (otherwise) does not need them, so am I missing something or do I have to suck it up?

OK, it now works (after changing it to use the Primary email address instead of the User ID - oddly they are both the same, but the BP refused to read the User ID) - the only problem is, instead of sending the chat to the User ID, it sends it to the team member who set up the connector.

Ok, so now it's all set up, however, testing produces the following. When creating the chat session: ID = Status = failedError = BadGateway: Failed to execute backend request. When attempting to send the message: ID = Status = failedError = BadRequest: UnknownError Is there anywhere I can dig further to analyse these Timeline outputs?