Victor

@samwoo I think I can draft an SQL statement if you send me some requirements, e.g. some examples on how conversion should work and what info (fields) should be in the report....

@chrisnutt Since this functionality is not yet there, I can't say how this will work, something our product managers have to consider. But I am certain they will discuss your requirement (i.e. team to not be visible on "Assign" action)

@chrisnutt hmm... I could have sworn you can do this... ... but it seems you can't, apologies ... I'll give a nudge to our devs and product managers to review this functionality...

Yes, the members of that (or those) team(s) won't be able to get requests assigned to them. Let us know if this is not the case...

@chrisnutt you can do this with current functionality: https://wiki.hornbill.com/index.php/Service_Desk_Administration

@Martyn Houghton something that needs to be considered by our dev team... I was thinking as a workaround, since you are using the actual value in the display value, to use the "LIKE" operator in the expression? This way you can rename the display value and not need to have the BP amended (this as long as the display value contains the actual value). So your expression would be: <variable> CONTAINS <value> or <variable> STARTS WITH <value> (e.g. Custom PCF->Variable contains "High" or Custom PCF->Variable starts with "High")

@Gary@ADL the issue was fixed in Service Manager build 1063 which was deployed in live instances last week. I see your instance is now on SM build 1064 which means the issue is fixed. If by any chance you still encounter the error and you are unable to access the service please let us know.

@carlt can you PM the process definition file and I'll have a look if and how you can achieve the assignment notification. On top of my head, we might be able to do it with two parallel suspend processes, but we need to establish what would be the trigger to end the parallel processing. So, for example: - on the first parallel thread, we would have a suspend "wait for resolution". This will be the main driver; - on the second thread, we would have a suspend "wait for reassignment". This will be responsible for the email notification and it will loop until the main driver (wait for resolution) is no longer suspended. So how it works, the BP reached the parallel section and it will have a double suspend... each suspends will behave individually however when both threads are resumed the parallel process ends. Translated into English, it means you can have the email notification on reassignment as long as the "wait for resolution" thread is in a suspended state. Just some quick thoughts there could be challenges on the way that I can't see right now... but we'll have a look...

@Michael Sharp apologies for the service disruption. We are currently investigating what caused it and we will update you as soon as possible.

@m.vandun apologies for the delays, we had to postpone the patch deployment for today. SM 1064 is now available for update on live instances and contains the fix for this issue.

@m.vandun we will deploy a patch a bit later today

@Michael Sharp besides the application setting you also need this outbound routing rule: Make sure is configured as per screenshot (i.e. mode = Use Direct Outbound)

@Michael Sharp

@m.vandun what is the request reference where you have seen this? EDIT: nvm, we found there is a defect in that node. We'll have it fixed asap.

@Claire Holtham @nasimg this was introduced to cater for these type of scenarios: multiple analysts action on the same request at the same time; an analyst and BP action on a request at the same time (i.e. a BP resume). For example, you have analyst A in the middle of typing an email. Analyst B opens the same request and sends an email (let's say is typing faster). Now analyst A might want to know that something happened to the request. he now has this visual indication and he can choose to continue or refresh the request to see how it was updated. It might be the case that the email analyst A was typing is now obsolete or redundant. An even better example is when analyst A is typing an update or email. The request has a BP with a task that is configured to expire or analyst B does an action (e.g. assign)... both examples would resume the BP with, let's say, switch focus to "Resolution" or "Escalate". Let's say the task expires in the middle of analyst update/email. Before this prompt was introduced, the BP will automatically shift action focus away from the update or email to the "Resolution" or "Escalate" action, the analyst effectively losing whatever he was doing/typing up to that point.

Well, I see something new every day ... I don't think this is used ... at least anymore... same as app.email.template.request.sendMessage (but this might be used on requests with no service)... I'll ask devs... Then maybe some possible workaround would be: #close the request with a specific category (instead of cancel); #have a specific task in the beginning which a line manage approves the request (sort of)... if the task is completed with a specific outcome, have the BP cancel the request (you can then do the emailing bit before the actual cancel). Just some ideas...

@Dan Munns may I ask why the request is canceled in the first place? What creates the need for a request to be canceled? If we have a simple answer to this then perhaps we can design the BP to cancel the request rather than via request actions (you can then disable this action on requests). This would allow you to have that email... but to answer your question No, not with current functionality. All emailing is done by the BP (except the email action itself from requests).

@William Weiszbrod what about your Chinese colleagues then? If a user with Chinese creates a custom field, with a custom label, any user with Chinese as language will see that custom label, the English version will be "Field X" (e.g. "Field 1 (en-GB)", "Field 2 (en-GB)", etc.). This is true for any other languages. When creating custom fields in ProCap, when you have users with different languages you would always make sure you create separate custom labels for each language in the field configuration. During configuration, even if you set the default field language to English (bypassing user default language) you would encounter the same issue for non-English users... I don't think there is a quick win here I'm afraid

@DeadMeatGF apologies for the lack of replies... I think I understand the flickering issue (I think.. )... but first I wanted to understand the BP configuration: A. where you assign the "incoming" priority and update service level, followed by timers start... Why are you using the first two nodes (assign priority and update service level)? B. the priority changed decision loop... I don't see how would work as I think you want it to work (based on configuration). The wait for priority will only waits (suspend) if you don't have a priority (no value).. but you do... you set it in the first node... so it will sort of continuous loop ( which might explain the flickering and you having to quickly select that correct priority)... I hope I'm understanding this correctly.. (the BP and what you are trying to achieve)

@SJEaton and anyone following this: The issue with field labels not being unique per service is actually a display issue in Internet Explorer. The configuration and underlying data are correct, so the functionality is correct (i.e. a custom field having unique field labels in different services). We are now working to identify the display issue occurring in IE and having it fixed.

Currently, no... but I can see the benefit... for sanity sake... Thinking of this, not sure why you want to keep your sanity, I feel so much better since I lost mine a while back...

@carlt @nasimg no, is not possible I'm afraid with current functionality. We'll ask internally if such functionality can be implemented in a future update.

Although the thread suggests the build has been deployed, the deployment was actually postponed for today (20/09). FYI for anyone interested.

@Prathmesh Patel These requests have now been fixed. Apologies for the inconveniences caused.

@SJEaton looking at my previous posts in this thread I mentioned the integration node is (currently) designed to work only for Custom G field... ...if you are trying to convert a date stored in other custom field (i.e. Custom A), then the integration node won't work... it will have to be amended to cater for other custom fields...