Berto2002

We have a use case where we want Sdesk to validate the choice made by a user on requested software, else choose another In the absence of being able to have a variable in the default choice of a human task we present the choice made by the user in bold text to the analyst in the human task and then give buttons to "Confirm Requested" (in which case workflow uses h_custom_m) or "Select Alternate" which gives the same drop-down and workflow ignores what the user requested and uses this new value instead. Achieves the same as you need above I think.

We just renewed the token again and the service was restored. So the issue appears to be that the Teams iBridge token is dropping-out a short while after a token refresh.

I have just logged a Premier Success Urgent Support ticket since our Teams tokens are not working again. This is what happened earlier in the week.

I would like to bring this item back to the table. There was some agreement among the customers at the HUG23 that we should have some way for customers to be told about and instantly state they are affected by an existing Incident rather than us have to publish Problems or Known Errors for them to use the "me too" option. I can see how Hornbill use the current feature in an application support environment where incidents get assessed and may or may not appear as defects weeks later for people to vote-up. But many of us work in Infra and Ops and we need to go from IN logged to announcing it to our customers within minutes. This is also unrelated to whether or not there is a Known Error (which may follow). This is a here-and-now immediate service availability notification with some additional functions. I request something like: Two-click feature or workflow node to present notification of the IN to the Subscribed users in the portal; perhaps this is a fast-path access to an Announcement on the Service by adding a new Action Icon. Feature can be activated by permitted person which we'd want calibrated to include senior analysts at Service Desk First click to activate a capture box in which we can enter the exact text to be presented; typically like "Users seeing error xxxxx when logging in" and a default, "Click if you are Impacted" Second click to publish it All Subscribed users can see it if they go to the portal. Users have two options: "I am Impacted" "I am Impacted and keep me updated" "I am affected" adds the user as an "Impacted" connection "I am affected and keep me updated" adds as a connection as above with a flag to receive notifications flagged for "Customer" One click removal of the portal text whenever required and by default on Resolution Does NOT give access to see the Request itself or provide a link; this is announcements only Reasons to have this feature: Reduce the number of logged tickets, saving customers and analysts time Better gathering of the true extent of the impact of an incident; users are far more likely to click a button than log a ticket Fast notifications to users of major incidents/outages My main requirement is that I have been asked for find the 'true' rather than 'assumed' impact of incidents. That is derived from the people directly affected at that time by that service. It is always only a subset of the known users; most people don't use all apps all the time and another group can go and do something else if one is down. We need to have a way of giving the business a very easy way to report how bad an outage is for them and reporting the result so they can encourage their people to use it. "It's two clicks (one to the portal URL and one to click impacted) for any user to declare they were impacted and this is how many people clicked the button to say it hurt them: X" @Estie @Smurfy @samwoo @HGrigsby @Sam P @BobbyB. Comments?

We have been able to successfully renew the MS Teams token.

+1

+1 Perhaps saving your own entity explorer prefs (last used setting) here would be just a good? Agreed, we rarely want to see all the Requests as there are thousands; but all the servers and services and the rest.

Reminded to bring this up again as I believe there may be some roadmap improvements for assets in 2024. The main ask here is to be able to enable filtering on asset status to avoid users and analysts selecting archived and retired assets for use in ICF, workflow and UI.

Looks like something went wrong on Tuesday afternoon or evening. That's when it looks like we last had a successful Teams update; in case that helps you find a change that has caused this from earlier in the week. Text of the last update I can see what just before 5pm Tuesday

@Keith Stevenson it still gives the same error when we create a new token in keysafe:

I don't think this is fixed @Keith Stevenson. Colleague should confirm soon.

After fixing this, if you get issues with the iBridge KeySafe Token for Teams not working, go here:

Or run a report like this one and filter by your leaver in Task Assigned to (using "urn:sys:user:" prefix) . You'll need to review the other filters as I have some on custom fields that won't help you. tasks-linked-to-active-requests.report.txt

Did anyone do anything fun or clever for hitting a milestone like a number of tickets? We've been going nearly 3 years and our 'ticket' rate has climbed to about 200 per working day with 100,000 coming over Christmas! Any parties, Easter Eggs, clever Workflows, User comms etc?

Impact: none of our iBridge integrations with Teams are working; which includes creating and updating private messages, starting and updating conversations in channels. Error received from Cloud node when attempting to create a new Teams conversation in a channel: Error: Error from Teams API: InvalidAuthenticationToken: Teams API Error: CompactToken parsing failed with error code: 80049217 Error received from Cloud node when attempting to create a new private message to an individual: Create chat error (no error if blank after colon): Session Error from Teams API: Refresh Token Generation Error: AADSTS901002: The 'resource' request parameter is not supported. Trace ID: 1b86d243-630e-40a9-a965-0402d92b4c00 Correlation ID: 89602aa4-8dad-4293-85da-ba9fa3d52c73 Timestamp: 2023-12-14 08:29:40Z From our side we see this as traffic between Hornbill and Microsoft, and we don't have a point at either end where we can capture it and diagnose.

We're about to enter a change freeze and no doubt many Hornbill Customers are. Some people call it a stability period. Can you confirm what Hornbill will or will not do over Christmas and New Year in terms of releases/code drops? Thanks,

+1 for that

@chrisnutt does this still work? Does &[parseInt(global["flowcoderefs"]["task"]["customField30"])+1] numerically increment the integer value from 1 to 2 to 3 to 4 etc?

Am I right in thinking you have this setting already? If I were you I would raise this as a defect. The text in the setting clearly states it should be a read-only view; but a view that allows commenting on existing timeline entries is not a read-only view. I'd class this as a defect because it exposes all Hornbill customers to having their users commenting on closed tickets and never getting a response; a real risk to customer sat.

From what I understand, there may be the possibility to create your own Asset classes coming in future; although I cannot yet see it on the roadmap.

That sounds like an excellent option.

Regardless of what it was before with regards the defaults, we've got side-tracked: my original point was that by introducing the collapsible search feature, the new UI asks every user (that needs to alter the default search type on any given screen; which is most times) for one additional click (to expand the box). Used to be 4 steps: Click on drop-down Select Requests (or required type) Enter search term Press enter or click search Now 5 steps (25% increase in required clicks): Click to expand collapsed search feature - additional step Click on drop-down Select Requests (or other) Enter search term Press enter or click search However, I'll leave it there with feedback given. The UI over-haul as a whole is an excellent improvement and Hornbill have been very responsive to concerns and suggestions. I should finish with a thanks for all that good work!

Yes, if I navigate within the app, the "Requests" remain persistent. But as soon as I use any links (like Favourites) or anything in the Hornbill waffle menu (which opens another tab) to get to any locations, it reverts to the ones mentioned above with CoWorkers being the default choice

Requests, yes, defaults to Requests: Contacts yes, defaults to Contacts: Organisations, es, defaults to Organisations: Boards no, defaults to Co-workers (Expect Requests): Suppliers, no, defaults to Co-workers (expect Suppliers): Assets, no, defaults to Coworkers (expect assets): So something in our instance has a defect by the sounds of it?

Sorry, not really. If I go to Boards I open the search, it has Coworkers every time, regardless of whether I have searched form a Board or not. So from any screen other than Request List it seems, I have two clicks to search for Requests now; this is exactly the point I made in my first post about the UI now having one additional click and slowing everyone down for the sake of looking pretty. I request again you revert to a permanently visible (uncollapsed) search box which was working just fine.